Avoid Update - Version 2.4.5.r.20200203.1429 issue

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)

chpalmer

Isildur provided a workaround above if you want to just do that..

It is how I got my 2.5 box back working.

Grapeape22

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

skogs

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

Grapeape22

@skogs I did not mean that in rude way. I was staying the obvious.

chpalmer

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

manit

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

https://snapshots.pfsense.org/amd64/pfSense_RELENG_2_4_5/installer/pfSense-CE-2.4.5-RC-amd64-20200204-1736.iso.gz

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

jimp

The -latest files are a link to whatever the most recent timestamp is. It's a convenience link to get the most recent at that time. I would not use those, as you won't necessarily know from looking at the name if what you downloaded before is the most recent at a later date.

So while it may be true that the ones you asked about were the same when you looked at that moment, that would not necessarily be true by the time someone else looked.