Mountroot issues after 2.2 upgrade
-
Understood.
One was the BandwidthD c annot be found, please specify path.
The other states something like this.
Loader Variables.
vfs.root.mountfrom=ufs:/dev/ad6s1a
vfs.root.mountfrom.options=rwmanual root
then a ton of variables and gibberish. I had to restore the units so I dont know how to grab logs when these things happen, sorry.
-
From another post on here I get exactly tjhis:
Loader variables:
vfs.root.mountfrom=ufs:/dev/ad0s1a
vfs.root.mountfrom.options=rwManual root filesystem specification:
<fstype>: <device>[options]
Mount <device>using filesystem <fstype>and with the specified (optional) option listeg. ufs:/dev/da0s1a
zfs:tank
cd9660:/dev/acd0 ro
(which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /)? List valid disk boot devices
. Yield 1 second (for background tasts)
<empty lines=""> Abort manual inputmountroot></empty></fstype></device></device></fstype>
-
Ok, so as I wrote in that other post it could be a device naming issue which is covered in the upgrade guide. If you type ? at that prompt and you see some devices specifically ada6 then you just need to reset the mount point.
Don't know about Bandwidthd. I know it works under 2.2. Did that prevent the box booting?
Steve
-
Ok, what about the bad ISO images? I can't get any to work on two machines for 2.2
-
Not seen that but I haven't personally been looking because all my machines run Nano.
Did you check the MD5 sums? https://files.pfsense.org/hashes/Steve
-
You sure you got the correct files? I seriously doubt they are all corrupt or there would be alot more people screaming.
-
Can somebody change this title ? promotes negative vibes … everybody knows that if you install a product that was released YESTERDAY even if it is in "RELEASE" status issues can occur because an internal "test" cannot beat hundreds of users installing and breaking things :)
How about renaming title to "mountroot issues after 2.2 upgrade"
But just for the record ... what were the model / hardware configuration of your other systems that bricked ? were they installed on SD cards, CF cards, SSD ?? ... what storage ? I have seen mountroot issues unless you added a "delay" in the booting process, especially for usb connected media.
-
Looks like xen vm but it's on release note. "run this before update"…
And you should never update anything without testing or backup first.
-
Okay … this line here: vfs.root.mountfrom=ufs:/dev/ad6s1a
As far as i remember, the newer versions of FreeBSD use ada0, ada1, etc for SATA and da0, da1, etc for USB or SAS HBA cards, etc.
-
-
same issue here: https://forum.pfsense.org/index.php?topic=87330.0
It's either naming or you need to introduce a delay … i'm assuming...
-
I upgraded two systems today, both via the autoupgrade. One is a little nanoBSD box at home and the other is the main firewall at work - running on a Dell. Both upgrades were flawless with no problems - both boxes support a pair of WAN interfaces with LAN, Wi-Fi, SIP, and a VPN and custom rules.
I read through the upgrade notes before performing the upgrades - and uninstalled all packages prior to running the autoupgrade and made backups of the configurations. Uninstalling the packages is something that I have not done in the past and it definitely made the whole process much quicker than past upgrades.
-
Uninstalling the packages is something that I have not done in the past and it definitely made the whole process much quicker than past upgrades.
+1. This is the way I do upgrades since a while.
-
4 servers updated so far and all switched to unbound - 0 problems so far. 2 in ESXi and 2 physical.
-
I upgraded two systems today, both via the autoupgrade. One is a little nanoBSD box at home and the other is the main firewall at work - running on a Dell. Both upgrades were flawless with no problems - both boxes support a pair of WAN interfaces with LAN, Wi-Fi, SIP, and a VPN and custom rules.
I read through the upgrade notes before performing the upgrades - and uninstalled all packages prior to running the autoupgrade and made backups of the configurations. Uninstalling the packages is something that I have not done in the past and it definitely made the whole process much quicker than past upgrades.
so uninstall the package first and then use autoupgrade and import the package backup config after?
-
Thats what I did with the VMs running on GB connection with lots of packages.
-
Thats what I did with the VMs running on GB connection with lots of packages.
how did you backup the package? or just import the anything after autoupgraded?
-
4 servers updated so far and all switched to unbound - 0 problems so far. 2 in ESXi and 2 physical.
Upgraded with no issues as well. Is the switch to unbound automatic?
Cheers!
-
What are you using for web filtering, squidguard not able to install
-
Nope - I sort of wish it was. Its no big deal to switch though. 1 minute? Maybe 2?
