Avoid Update - Version 2.4.5.r.20200203.1429 issue
-
On reboot, cannot open /etc/rc.ramdisk_functions.sh: no such file or directory.
Have no idea how to recover that
-
I should have gone here before updating. I'm in the same boat..
Receiving the same error.
looks like we need the full path name to that shell.
-
Unfortunately I hadn't made a snapshot..but had a backup from before the first RC that worked. Leaving my VM in that broken state though in case devs need it
-
Is this 2.4.5 or 2.5?
Im on
2.5.0-DEVELOPMENT (amd64)
built on Mon Feb 03 01:00:03 EST 2020
FreeBSD 12.0-RELEASE-p10
and
2.4.5-RC (amd64)
built on Sun Feb 02 19:51:43 EST 2020
FreeBSD 11.3-STABLEon a couple units here in the lab..
no issues.
-
@chpalmer Sorry, 2.4.5. How did you get to that build? Update via webui? I did not follow the recommend and remove all packages, so maybe that could have caused an interaction?
I believe I was coming from the 20200131 build (not sure if I missed one on the 1st)
-
I did not pull packages off either. Usually never do. I know- bad practice but it helps me test. Updated via GUI.
-
@chpalmer said in Version 20200202 issue:
Is this 2.4.5 or 2.5?
Im on
2.5.0-DEVELOPMENT (amd64)
built on Mon Feb 03 01:00:03 EST 2020
FreeBSD 12.0-RELEASE-p10
and
2.4.5-RC (amd64)
built on Sun Feb 02 19:51:43 EST 2020
FreeBSD 11.3-STABLEon a couple units here in the lab..
no issues.
you have not tried the update from today.
your running a day old release
2.4.5 is what i am talking about. for what its worth i didn't have any packages loaded.... nothing
-
-
That would be 20200203..
Version 2.4.5.r.20200203.1429 is available.
So your saying to avoid pushing the update button right now..?? Note to self.. do not update my 2.4.5 box UFN.
-
@chpalmer to be fair I didn't super note the version; I can only firmly remember 2020020...
Is there anything I can pull off the other box in rescue more or something that would help?
-
If you would you might change the title of this thread to something that includes the version above. And maybe says "Avoid Update.."
-
I would not do the update from three hours ago.. I posted my screenshot in another thread
I won’t get my main router up until tomorrow I’m running on my backup sg 2220
2nd time I’ve been bitten no more development for me again
-
Thanks Decobus.. Hopefully will catch others in time if the issue still persists. Usually the developers know pretty quick themselves.
-
I've posted on reddit too to try and warn users there
-
@Decobus said in Maybe Avoid Update - Version 2.4.5.r.20200203.1429 issue:
I've posted on reddit too to try and warn users there
Thanks, I should have looked here before I hit the update. I have the same problem.
Fortunately I had a VM checkpoint and was able to revert.
-
It appears this is affecting the 2.5 branch as well.. I went ahead and tried to verify and be able to post a warning for it as well.
Thats what test routers here are for though.. :)
Avoid updating either platform.
-
@Decobus can you fix the spelling of the path so people can easily find it when searching. (it should be .sh not .ah)
-
@chpalmer I would run more test VMs but I am sure how to effectively test WAN, since I only have 1 residential connection and don't know what ESXi would do
-
@artooro My bad, fixed.
-
@Decobus Is 2.5 fixed.... I just reinstalled upgraded and am getting the same thing...
-
-
@imaged Doubtful. I am not running a 2.5 box..I don't have a spare WAN connection to use as a test :(
-
How do I fix this error ?
-
I don't know, brought it up over here too: https://forum.netgate.com/topic/150214/avoid-update-version-2-4-5-r-20200203-1429-issue/21
-
Decobus
If you have a spare VM or box you can always plug your WAN of the test box into the LAN of your primary box. Just make sure the WAN and LAN of the test box are in different subnets.
I have to pull my 2.5 box out of the rack and plug a monitor into it to reload or fix. So will do so after one of the devs comes along and says all safe. :)
-
There was movement on the "ramdisk" earlier..
-
Confirm tried 2.4.4_3 > 2.4.5.4.20200203.1429.
In case it matters this one is running zfs.Trying to mount root from zfs:zroot/ROOT/default ...
configuring crash dumps
cannot open /etc/rc.ramdisk_functionslsh no such file
-
@chpalmer oh man I see my biggest concerns as a former release manager: "(cherry picked from commit 82bf21fc37ef436f0d8439a84a97d61a7d5979b6)"
@skogs Saved me some time there :) , I was just about to retry that myself since earlier it had been an RC to RC update
-
@skogs
Same errorConfirm tried 2.5.0 > 2.5.0.20200203.1429.
Trying to mount root from zfs:zroot/ROOT/default ...
configuring crash dumps
cannot open /etc/rc.ramdisk_functionslsh no such fileWaiting for Solution
Eberhard
-
Here is quick and dirty solution if you have direct access:
As soon as you see "... or RETURN for /bin/sh" hit that enter button and write this:touch /etc/rc.ramdisk_functions.sh rebootit will continue with booting and upgrading.
After that you might want to turn off ram disks in configuration, reboot and turn them on again and do a reboot again to re-enable them.
-
@Isildur
Online again. Well done.
Thanks for quick and dirty Solution!
-
Next snapshot should have this fixed. The file was in the repo with the right permissions but it wasn't being unpacked early enough to be seen by that script, so we moved it to the rc pkg. A new set of updates is building now.
If you worked around it, you can update afterward and still be OK.
Alternately, if you can get it online (For example, by running
dhclient <wan interface>at a shell prompt) you may be able togitsyncto the appropriate branch for your install if it's CE, which would also bring in current copies of all the files.Or if you can get it online, run something like
fetch -o /etc/ https://raw.githubusercontent.com/pfsense/pfsense/master/src/etc/rc.ramdisk_functions.sh(you could run this before updating if you really wanted to update, but you are better off waiting for the next new snapshot...)New installs of those snapshot images would be OK since the file would be in place already.
-
@Grapeape22 said in Avoid Update - Version 2.4.5.r.20200203.1429 issue:
How do I fix this error ?
I got it fix by reload the pfsenss This is the only solution I can come with. Because nobody reply back in time.
-
@Grapeape22 yeah I think we all had to reload and then import the backup configs. Thankfully that only takes about 10 minutes.
In other news seems the new build gets beyond the ramdisk issue just fine. Just did a 2.4.4_3 > 2.4.5.r.20200203.2111 and reboot and load seemed to be functional. Snort even seems to have survived the migration despite my best efforts to not follow instructions. Oops.
Good work team.
(edited to fix @ linky; didn't know it actually linked names directly)
-
Isildur provided a workaround above if you want to just do that..
It is how I got my 2.5 box back working.
-
@chpalmer There is no point of a workaround. Most people reload firewall. People cannot live without internet and no one responded back almost 2 hours. So the workaround is pointless.
-
@Grapeape22 No need to flame friend. These are development test releases and we're probably not paying for support tickets to be worked in 2 hours or less. Please be kind.
-
@skogs I did not mean that in rude way. I was staying the obvious.
-
@Grapeape22 said in Avoid Update - Version 2.4.5.r.20200203.1429 issue:
@skogs I did not mean that in rude way. I was staying the obvious.
I was not directing my comment to you as you had already reloaded as you explained earlier. Im directing that comment at anyone that comes along looking for an easy way to fix their issue.
You should not be using snapshots for your firewall being used as a primary internet connection. But that is just common sense.
-
@chpalmer Hi, newby here, in fact relatively new to pfSense, so please bear with my questions.
Thank GOD I checked this forum, I would have been in all sorts of trouble if I upgraded my firewall to this RC (Not live just a DEV box).
Could someone tell me if the snapshot image named pfSense-CE-2.4.5-RC-amd64-latest.iso.gz is the same as:
The file sizes are identical and I am guessing it is.
Also aren't the snapshot images meant to be bootable (if I extract the ISO and burn to disk).
I received error when i was trying to create a bootable USB which said, "This image is either non-bootable, or it uses a boot or compression method that is not supported by RUFUS"I have used Rufus before on pfSense ISO files and had not encountered this before.
BTW have you or anyone tested 20200204-1736 yet?
Thank you in advance for your comments
