Solved system keeps rebooting with error.

Code:
savecore880 - - reboot after panic: ufs_dirbad: /: bad dir ino 14285568 at offset 1176: mangled entry.

I can't boot into single user mode.

Edit: Thanks for all your help. I ended up reinstalling my system as I didn't think I could fix it as I don't have that much experience. I didn't have anything on the system so it wasn't a big deal. I couldn't figure out how to mount my harddrive from my install usb as I didn't know the device name.
 
Last edited by a moderator:
Perhaps, boot from a USB stick and do fsck from there? I've had those ufs_dirbad errors on a UFS system with frequent power outages. UFS is quite susceptible to breaking if improperly shutdown. If this is your case, ZFS is a much better option.
 
Perhaps, boot from a USB stick and do fsck from there? I've had those ufs_dirbad errors on a UFS system with frequent power outages. UFS is quite susceptible to breaking if improperly shutdown. If this is your case, ZFS is a much better option.
Can I do it from the shell of my install usb?
 
Last edited by a moderator:
UFS is quite susceptible to breaking if improperly shutdown. If this is your case, ZFS is a much better option.
The first sentence is wrong. The second sentence is bad advice. UFS with soft updates is very resilient against hard stops, as long as the hardware doesn't do crazy stuff (like out of order writes). ZFS is also very resilient, but probably not significantly more or less than UFS. In the presence of sufficiently byzantine hardware, all bets are off, but that does not occur commonly.

Obviously, running fsck from other media is the correct starting point.
 
ralphbsz, I speak from practice deploying over a hundred of FreeBSD-based firewalls/servers/routers in different parts of the world - from developed countries to African and South American jungle, on different motherboards, SD cards, CF cards, consumer- and enterprise-grade SSDs with capacitors and without, etc. You should probably say that UFS is very resilient in theory. In practice, it's as resilient as a house of cards.
 
does that bring me right to my harddrive? im confused on how i get to my harddrive to run the fsck.
Yes when you run 'Shell' option from the FreeBSD memstick it is meant for an 'install shell'.
For instance if you needed to start up a module before running the installer you would use that option.
For example you want to install onto a gmirror you can run kldload gmirror from 'Shell' and than exit and this setting will stick for the install.
For repair work you want to use LiveCD.
Seeing how fsck needs an unmounted disk to work on, the LiveCD mode is a good choice.
Simply run fsck -y /dev/ada0 and it will work if your drive is ada0. Infact you don't even need to specify a drive. It will check all unmounted drives if none is specified.
**Edited for correctness**
 
fsck -y would work if you booted in single user mode from your harddisk.
fsck uses the local fstab to determine what to work on if you do not specify a drive.
So in your case, booting from a memstick, fsck would use the memsticks fstab to determine what to check if no drive is specified.
That would not work for your problem as the local fstab on the memstick would not have a mountpoint for your harddisk.

I learned something tonight!

blackhaz I think your method will work too but I consider that 'Shell' for the installer use. It works from a chroot env if I am not mistaken.
If you specify a device node I suppose it doesn't matter from where fsck is launched.
 
I just did a check of the 'Shell' offered by the bsdinstaller menu.
When you choose the Memstick 'Shell' option the following text is displayed:
Code:
When finished, type 'exit' to return to the installer.
#
So I think my assumption was correct. The 'Shell' in this case is meant for the installer.
I also noticed it does launch into a chroot env and exiting the shell does not delete the chroot env.

But back to ralphbsz comment. "UFS SU is very resilent against hard stops".
I wholeheartedly agree. Not just in theory but in practice.
 
Back
Top