FreeBSD 11.1 - File system has an unexpected consistency

R

roscoe

Hi,

I just upgraded from 10.3-RELEASE to 11.1-RELEASE and noticed an odd issue at boot with my external USB drive (UFS).

I get the following kernel boot messages when the drives are being detected:

Code: 
Jul 31 22:56:26 S-JUPITER kernel: Can't stat /dev/gpt/backup: No such file or directory
Jul 31 22:56:26 S-JUPITER kernel: Can't stat /dev/gpt/backup: No such file or directory
Jul 31 22:56:26 S-JUPITER kernel: THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
Jul 31 22:56:26 S-JUPITER kernel: ufs: /dev/gpt/backup (/Backup)
Jul 31 22:56:26 S-JUPITER kernel: Unknown error; help!
Jul 31 22:56:26 S-JUPITER kernel: ERROR: ABORTING BOOT (sending SIGTERM to parent)!
Jul 31 22:56:26 S-JUPITER kernel: Jul 31 16:51:14 init: /bin/sh on /etc/rc terminated abnormally, going to single user mode
Jul 31 22:56:26 S-JUPITER kernel: Enter full pathname of shell or RETURN for /bin/sh:

I was then in single user mode, at which point I ran

fsck /dev/gpt/backup

...and the operation seems to complete fine. However I continue to get the same error on the next boot. Is the volume not marked 'clean' at this point?

In order to get things to work I had to comment out this volume from /etc/fstab for the boot to succeed:

Code: 
#/dev/gpt/backup                /Backup         ufs     rw      2       2

I would like this to be auto-mounted on startup though.
Any idea what step I am missing here or any checks I can try?

Thanks,
Rob
 
You can run the fsck(8) when the system has been booted. You only need to make sure it's unmounted or else fsck(8) can't fix errors. Try running it again, fsck -y /dev/gpt/backup and let it fix the errors. It's also possible it's so corrupt even fsck(8) can't fix things any more. In that case there's really nothing else to do but format and restore from backups. A bit ironic though, you'd need backups to restore your backups.
 
Hi, If you can run fsck in single-user mode on the partition's label, then in this case you're partition should be being correctly recognized by its label, which is something that doesn't appear to happen when you boot in multi-user.
One possibility I can think of, is that the 'backup' label of your ufs partition, albeit existing in single user mode, is hidden in multi-user. This can happen if you mount the partition otherwise (by its 'true' name, like /dev/da*p*). Perhaps you modified /etc/fstab when the file was trying to be merged during the upgrade? Or added a scheduled mount task to the crontab?
You could try to check the output of
- ls -l /dev/gpt, to see if all of you're labelled partitions are still there and 'backup' is not hidden.
- gpart show -l
Moreover, if I'm not wrong, geom_label.ko kernel module needs to be loaded at boot for the partition label to be recognized. Is it possible you disabled it in /boot/loader.conf or edited your kernel configuration?

If you backup and rewrite fstab, mounting every partition without labels, does it work?

If anything helps, despite I know that this won't sound like a great suggestion, you could just try to avoid mounting that /dev/gpt/backup (It isn't your root partition, is it?), In order to keep using your system, and then recover your data afterwards.

Regarding fsck, it usually returns 'file system marked clean' upon ending if that's the case, otherwise it will tell you it's still dirty and suggest you to start fsck over. So what was the output after you ran of fsck? Did you use journal, or you skipped into full fsck? Is it possible you accidentally ran it in preen mode or with -C option?
You could also use -f option to force check even if it's marked clean
 
Thanks for the quick responses SirDice and Sensucht94. Will try the suggestions and report back on the results!
 
I had a chance to complete the rest of the 10.3 -> 11.1 upgrade last night. The issue reported above was when I booted into the new kernel, but had not yet updated the userland components. After doing so, I still notice the message at boot but now, unlike before, the system comes up as expected.

Oddly it complains about the Backup volume the first time in the boot sequence and then immediately after it seems to have no issue:

Code: 
Aug  2 09:10:06 S-JUPITER kernel: Starting file system checks:
Aug  2 09:10:06 S-JUPITER kernel: /dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS
Aug  2 09:10:06 S-JUPITER kernel: /dev/ada0p2: clean, 233117367 free (35311 frags, 29135257 blocks, 0.0% fragmentation)
Aug  2 09:10:06 S-JUPITER kernel: Can't stat /dev/gpt/backup: No such file or directory
Aug  2 09:10:06 S-JUPITER kernel: Can't stat /dev/gpt/backup: No such file or directory
Aug  2 09:10:06 S-JUPITER kernel: /dev/mirror/data: FILE SYSTEM CLEAN; SKIPPING CHECKS
Aug  2 09:10:06 S-JUPITER kernel: /dev/mirror/data: clean, 249634965 free (4845 frags, 31203765 blocks, 0.0% fragmentation)
Aug  2 09:10:06 S-JUPITER kernel: THE FOLLOWING FILE SYSTEM HAD AN UNEXPECTED INCONSISTENCY:
Aug  2 09:10:06 S-JUPITER kernel: ufs: /dev/gpt/backup (/Backup)
Aug  2 09:10:06 S-JUPITER kernel: Warning! Some of the devices might not be available; retrying
Aug  2 09:10:06 S-JUPITER kernel: Waiting 30s for the root mount holders: usbus8 usbus3.
Aug  2 09:10:06 S-JUPITER kernel: .
Aug  2 09:10:06 S-JUPITER kernel: Restarting file system checks:
Aug  2 09:10:06 S-JUPITER kernel: /dev/ada0p2: FILE SYSTEM CLEAN; SKIPPING CHECKS
Aug  2 09:10:06 S-JUPITER kernel: /dev/ada0p2: clean, 233117367 free (35311 frags, 29135257 blocks, 0.0% fragmentation)
Aug  2 09:10:06 S-JUPITER kernel: /dev/mirror/data: FILE SYSTEM CLEAN; SKIPPING CHECKS
Aug  2 09:10:06 S-JUPITER kernel: /dev/mirror/data: clean, 249634965 free (4845 frags, 31203765 blocks, 0.0% fragmentation)
Aug  2 09:10:06 S-JUPITER kernel: /dev/gpt/backup: FILE SYSTEM CLEAN; SKIPPING CHECKS
Aug  2 09:10:06 S-JUPITER kernel: /dev/gpt/backup: clean, 257297335 free (6575 frags, 32161345 blocks, 0.0% fragmentation)
 
Code:
According to what SirDice stated sometimes even fsck fails to recover a ufs filesystem when severely injured.
Now:
1)if you are sure that it is by no means mounted elsewhere,and therefore:
-
Code: 
umount /dev/gpt/backup
doesn't give 'device busy'; [in the latter case naturally " umount() -f " would do the job]

2) and you ran fsck while it was surely unmounted, or from a live CD

...Then I guess there's no other option than attempting a data recover and deleting the partition afterwards. If your system works well than you can work this out just by performing a new backup. Otherwise you could perform a
Code: 
freebsd-update rollback

I'm sorry for not being able to provided further help

Ps: if you have a dedicated partition for /var you might like sysutils/backuppc, whereas by default it stores any backed data inside /var/db/BackupPC; It can prove really useful ;)
 
You must log in or register to reply here.
Back
Top