Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    2.4RC installation boot failure

    Scheduled Pinned Locked Moved 2.4 Development Snapshots
    11 Posts 3 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      beatvjiking
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • jimpJ
        jimp Rebel Alliance Developer Netgate
        last edited by

        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.

        Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

        Need help fast? Netgate Global Support!

        Do not Chat/PM for help!

        1 Reply Last reply Reply Quote 0
        • B
          beatvjiking
          last edited by

          @jimp:

          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.

          1 Reply Last reply Reply Quote 0
          • jimpJ
            jimp Rebel Alliance Developer Netgate
            last edited by

            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.

            Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

            Need help fast? Netgate Global Support!

            Do not Chat/PM for help!

            1 Reply Last reply Reply Quote 0
            • B
              beatvjiking
              last edited by

              So right now it looks like:

              # Device		Mountpoint	FStype	Options		Dump	Pass#
              /dev/ad4s1a		/		ufs	rw		1	1
              
              

              but when it's done it should look like:

              # Device		Mountpoint	FStype	Options		Dump	Pass#
              /dev/ufsid/some-long-serial-number		/		ufs	rw		1	1
              

              I'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โ€ฆ

              1 Reply Last reply Reply Quote 0
              • jimpJ
                jimp Rebel Alliance Developer Netgate
                last edited by

                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.

                Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

                Need help fast? Netgate Global Support!

                Do not Chat/PM for help!

                1 Reply Last reply Reply Quote 0
                • B
                  beatvjiking
                  last edited by

                  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

                  1 Reply Last reply Reply Quote 0
                  • K
                    kpa
                    last edited by

                    For reference:

                    https://www.freebsd.org/cgi/man.cgi?query=glabel&apropos=0&sektion=0&manpath=FreeBSD+11.1-RELEASE+and+Ports&arch=default&format=html

                    1 Reply Last reply Reply Quote 0
                    • jimpJ
                      jimp Rebel Alliance Developer Netgate
                      last edited by

                      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.

                      Remember: Upvote with the ๐Ÿ‘ button for any user/post you find to be helpful, informative, or deserving of recognition!

                      Need help fast? Netgate Global Support!

                      Do not Chat/PM for help!

                      1 Reply Last reply Reply Quote 0
                      • B
                        beatvjiking
                        last edited by

                        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 :)

                        1 Reply Last reply Reply Quote 0
                        • K
                          kpa
                          last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.