Mount error 19 with upgrade to 2.4.0
-
The disk name probably changed
At the prompt, enter:
ufs:/dev/ada0s1aAnd once it's booted the rest of the way, fix your /etc/fstab for the new names, then go to a shell prompt and run
/usr/local/sbin/ufslabels.sh -
ok, the 1st step worked
mountroot> ufs:/dev/ada0s1a
Trying to mount root from ufs:/dev/ada0s1a []…
Configuring crash dumps...
No suitable dump device was found.
usage: ddb capture [-M core] [-N system] print
ddb capture [-M core] [-N system] status
ddb script scriptname
ddb script scriptname=script
ddb scripts
ddb unscript scriptname
ddb pathname
/dev/ada0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
/dev/ada0s1a: clean, 2180864 free (3856 frags, 272126 blocks, 0.1% fragmentatio)
Filesystems are clean, continuing…
Mounting filesystems...
/etc/pfSense-rc: /etc/rc.restore_ramdisk_store: not found
...login: admin
pw: <>re0: link state changed to DOWN
re1: link state changed to UP
re2: link state changed to DOWNWarning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/2013120
- Logout (SSH only) 9) pfTop
- Assign Interfaces 10) Filter Logs
- Set interface(s) IP address 11) Restart webConfigurator
- Reset webConfigurator password 12) PHP shell +
Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/2013120
pfSense tools - Reset to factory defaults 13) Update from console
- Reboot system 14) Enable Secure Shell (sshd)
- Halt system 15) Restore recent configuration
- Ping host 16) Restart PHP-FPM
- Shell
Enter an option: 8
[2.4.0-RELEASE][admin@]/root:
[2.4.0-RELEASE][admin@]/usr/local: ufslabels.sh
dumpfs: /dev/ad4s1a: could not find special device
Invalid ufsid on ad4s1a (), cannot continue
exit: Illegal number: -12nd step is not working.
-
Edit /etc/fstab, change ad4 to ada0 on each line
Then you should be able to run it.
-
Ok, now I am able to boot.
Next problem
Warning: PHP Startup: Unable to load dynamic library '/usr/local/lib/php/2013120I will start a new post
-
Thanks
Looks a bit like my problem: https://forum.pfsense.org/index.php?topic=137939.0
-
Experienced the same problem with 2.4.0 upgrade after doing it through GUI. Not sure why the renaming had to happen like that.
-
@ssp:
Experienced the same problem with 2.4.0 upgrade after doing it through GUI. Not sure why the renaming had to happen like that.
Something apparently changed in the FreeBSD disk controller drivers. The "adX" naming hasn't been used in quite some time, but it used to provide legacy aliases so that the old disk names could still be used. If your OS was installed before the switch to "adaX" disk names then /etc/fstab was pointed to the out-of-date alias name instead. Looks like the knob for "kern.cam.ada.legacy_aliases" which controlled the behavior is gone as well in FreeBSD 11.x
Apparently your disk device name changed long ago, but it was propped up by the legacy code which is now gone, so it wasn't exactly sudden, but it also wasn't made obvious that it was outdated either.
We should be able to add some code to work around that, I opened a ticket: https://redmine.pfsense.org/issues/7937
-
Had the same issue on a Netgate FW-7541.
The disk name probably changed
At the prompt, enter:
Code:
ufs:/dev/ada0s1aThis allowed pfSense to boot and finish the upgrade, I did see warning about PHP and dynamic libraries but I believe it rebooted as I was once again at the mountroot> prompt. When I issued the ufs:/dev/ada0s1a it told me unsupported file system. I turned the unit off and back on and was able to mount using the previous code.
/usr/local/sbin/ufslabels.shDidn't work for me, gave an error.
I edited the fstab and everything seems to be working fine now, no errors in bootup :D
FYI: I remember how much I hate VI :-\ I installed nano since this unit is a LAB for testing, wish it was installed by default.
-
FYI: I remember how much I hate VI :-\ I installed nano since this unit is a LAB for testing, wish it was installed by default.
Use ee, it's built in.
Also: https://redmine.pfsense.org/issues/7937
-
Use ee, it's built in.
Also: https://redmine.pfsense.org/issues/7937
Thanks for the tip Jim. Accustomed to linux and don't spend enough time with BSD.
After reading issue 7937 I have a quick question. Do I need to run /usr/local/sbin/ufslabels.sh after editing the fstab? Several reboots and so far no issues booting.
-
If you have drive names in fstab (e.g. /dev/ada0s1a) then you can still run ufslabels.sh to prevent it from being a problem in the future.
-
If you have drive names in fstab (e.g. /dev/ada0s1a) then you can still run ufslabels.sh to prevent it from being a problem in the future.
====================
Current fstab:Device Mountpoint FStype Options Dump Pass#
/dev/ada0s1a / ufs rw 1 1
/dev/ad4s1b none swap sw 0 0New fstab:
Device Mountpoint FStype Options Dump Pass#
/dev/ufsid/52845261029b2318 / ufs rw 1 1
/dev/label/swap0 none swap sw 0 0
Commit changes? (y/n):Reboot and everything is working as expected! :D
I have a LAB environment and several boxes of models we use at productions sites. Generally, before I push an upgrade to a production site I test each of these units here to make sure I don't see any issues. Would it be a good idea to also install an old copy of pfsense (eg. 2.1, 2.2) and then preform the upgrade to current to see if any obsolete setting cause issues in the future?
-
I have a LAB environment and several boxes of models we use at productions sites. Generally, before I push an upgrade to a production site I test each of these units here to make sure I don't see any issues. Would it be a good idea to also install an old copy of pfsense (eg. 2.1, 2.2) and then preform the upgrade to current to see if any obsolete setting cause issues in the future?
You can't go straight from 2.2 to 2.4, you have to stop at 2.3 in between. So you can do that if you want, but at the moment we're only testing 2.3 to 2.4.
