Re: cause of reboot

2013-09-30 Thread Michael Powell
kpn...@pobox.com wrote: [snip] While we're throwing ideas onto the table let me mention power supplies. Power supplies and hard drives are in a race to see which one will fail first. It may be that the power supply is marginal and added load from the drives being hit hard may send it over the

Re: NAT: Handbook vs mailing list

2013-10-08 Thread Michael Powell
Olivier Nicole wrote: [snip] The mailing list message linked above suggests that the handbook information is the old way and that the correct way is to set ipfw_enable and natd_enable in rc.conf. Then /etc/rc.d/ipfw will load ipfw.ko, and if natd_enable is set, will invoke /etc/rc.d/natd,

Re: failed to create gmirror with the handbook instructions

2013-10-08 Thread Michael Powell
Andy Zammy wrote: # gpart show ada0s1 gpart: No such geom: ada0s1 By the way, this is after a restart of the machine. There's nothing to back up, I'm installing a fresh os, so I just install on one drive, plug the other in, and start following the handbook instructions for this method.

Re: SU+J Lost files after a power failure

2013-10-14 Thread Michael Powell
David Demelier wrote: Hello there, I'm writing because after a power failure I was unable to log in on my FreeBSD 9.2-RELEASE. The SU+J journal were executed correctly but some files disappeared, including /etc/pwd.db. Thus I was unable to log in. I've been able to regenerate the

Re: SU+J Lost files after a power failure

2013-10-14 Thread Michael Powell
Michael Powell wrote: [snip] The other box is my first foray into the land of GPT, along with SU+J. It was sitting at the 'couldn't mount... Press return for /bin/sh' line. There was an error indicating that replaying one or more journals had failed. I was able to successfully fsck all

Re: SU+J Lost files after a power failure

2013-10-14 Thread Michael Powell
Charles Swiger wrote: [snip] Yes. Without journalling, you'd normally perform the full timeconsuming fsck in the foreground. With journalling, it should be able to do a journal replay to restore the filesystem to an OK state, but sometimes that doesn't restore consistency, in which case

<    1   2   3   4   5   6