Avoid Update - Version 2.4.5.r.20200203.1429 issue

IsaacFL

@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.

chpalmer

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.

artooro

@Decobus can you fix the spelling of the path so people can easily find it when searching. (it should be .sh not .ah)

Decobus

@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

Decobus

@artooro My bad, fixed.

imaged

@Decobus Is 2.5 fixed.... I just reinstalled upgraded and am getting the same thing...

Grapeape22

Decobus

@imaged Doubtful. I am not running a 2.5 box..I don't have a spare WAN connection to use as a test :(

Grapeape22

How do I fix this error ?

Decobus

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

chpalmer

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

chpalmer

There was movement on the "ramdisk" earlier..

https://redmine.pfsense.org/projects/pfsense/repository/revisions/29aef439c91c5e76e59c1b82b69ec156973caac1

skogs

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

Decobus

@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

Eberhard Huebner

@skogs
Same error

Confirm 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 file

Waiting for Solution
Eberhard

Isildur

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
reboot

it 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.

Eberhard Huebner

@Isildur
Online again. Well done.
Thanks for quick and dirty Solution!

jimp

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 to gitsync to 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

@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.

skogs

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