2.4RC installation boot failure
-
I upgraded one of my machines from 2.3.4-1 to 2.4RC the other day, and it failed to boot post-upgrade without user intervention. I attached a console and found the message "mounting from ufs:/dev/ad4s1a failed with error 19." I queried for the available devices, found the disk, input "ufs:diskid/DISK-50026B7233033A26s1a" and boot proceeded normally. A reboot after this had the same result - I had to specify the root partition/slice manually in order for the machine to boot properly.
I'm wondering how to correct this permanently - I have other machines in the same boat as this one. I also want to make sure I don't mess with something that the upgrade installers will revert/overwrite/trip over in the future. This machine has been upgraded regularly since pfSense 2.0.1 - there could be some holdover information somewhere that the 2.4 upgrader script maybe missed?
-
The drive numbering probably changed. You can run ufslabels.sh from a shell prompt before upgrading to make it mount by label instead of by disk name.
-
The drive numbering probably changed. You can run ufslabels.sh from a shell prompt before upgrading to make it mount by label instead of by disk name.
Is that possible to do post-upgrade? I've tried running it after the upgrade on this affected machine and it throws an error. I'll be by the machine soon and can get the exact error message it puts out.
-
It probably won't work post-upgrade because it won't be able to find the device based on its fstab entry.
You could edit the reference in /etc/fstab by hand though. At least correct it to the proper disk and then reboot and then you can run that script.
-
So right now it looks like:
# Device Mountpoint FStype Options Dump Pass# /dev/ad4s1a / ufs rw 1 1but when it's done it should look like:
# Device Mountpoint FStype Options Dump Pass# /dev/ufsid/some-long-serial-number / ufs rw 1 1I'm only asking because FreeBSD's man page for fstab doesn't seem to make any mention of these device IDs so I can't check my facts there…
-
Yeah, or you could just look at dmesg or "ls -l /dev/ad*" and find the new name of the disk, the "4" in ad4 probably changed to something else, or it may also be ada0 for example.
The man page doesn't mention device names because there are dozens of them from various disk drivers.
-
That did it. I had tried specifying "ufs:/dev/ada0s1a" instead of "ufs:ada0s1a" when I was initially troubleshooting, and it didn't work. I added the device node to /etc/fstab, which worked, and I ran ufslabels.sh successfully, and reboots worked once again. I figured I'd run the ufslabels.sh just to futureproof the machine a bit.
Thanks so much for your help - this was quite an educational experience! :D
-
For reference:
-
You could use glabel but you'd have to do that from single user mode without remounting the root slice. The advantage of using the ufsid is that it's already there and you don't have to umount the disk to do it.
-
The glabel thing is great info though, I can imagine there are people in instances who use other disks for storing things like IDS logs or squid caches where it'd make things simpler to make references to /dev/label/thisiswherethelogsgo instead of /dev/ufsid/893674278ad1398. I don't mind the ufsid in this case because there's literally only one slice on these disks - there isn't even swap set up. Long ID numbers aren't too bad as long as you only have one to deal with :)
-
You don't want to use the actual glabel labels because they use metadata storage that can be problematic on some installations. GPT labels would be preferred if possible over anything but not everything works with GPT partitioned disks.
