SG1100 to 24.11 issues
-
Mmm, 5.6GB should be easily enough but I would still remove any old BEs you might have there.
-
-
After deleting the non default BE and running the upgrade process again i receive the following message
-
I would try removing those large pkgs and retrying. Especially if pfBlocker has any large lists. I suspect it's exhausting the RAM.
-
Just for the records: had a similar issue when upgrading from the RC to the release (only 7 packages upgraded).
Solved by removing one BE with ~1.4GB.now on 24.11: thanks all for your work!
-
Removed pfblocker and frr but still the upgrade is failing
Not sure what pkg-static is but that seems problematic
-
@michmoor pkg relies on dynamic libraries provided by the system whereas pkg-static does not. Usually that message indicates the system is running out of memory. There are some situations where 2GB is required for the upgrade to succeed. My suggestion in this case would be to create a BE with everything working, uninstall all packages, update, reinstall packages. then create a new BE.
-
Yes, looks like it's still exhausting the RAM. How much free RAM is shown before the upgrade starts?
-
@stephenw10
Im in the process of removing packages.
How do I check the amount of memory prior to an upgrade? -
The dashboard will give you a rough value. Otherwise check the output of
topr in Diag > System Activity. -
-
Should be fine from there.
-
So close. Prior it kep stalling on the python install. It got pass that and now its failing here.
-
Ok, reboot to free up RAM then try upgrading from the CLI without the webgui open.
pfSense-upgrade -dThat will show you more error output if it fails again.
-
@stephenw10 That last error pointed to bsnmpd. I disabled it and ran through the upgrade process.
That is successful and the system reboot into 24.11Thanks @stephenw10 and @marcosm for the assist here. Appreciate yah.
One last question, help me understand the requirements for the SG1100 regarding packages. When purchasing the unit, I knew it would be limited in usage with heavier packages like Suricata. The thinking is that this location has a 300Mbps line and didn't need much in hardware.
I didn't feel that pfblocker or frr were heavy. Is there concern about running extra packages? Is FRR suitable for running on the unit? -
It depends!
FRR could use a lot if you tried to load a bgp full routing table for example. Equally pfBlocker can use a lot of RAM if you load all the huge lists. But both will run on an 1100 given some limits.
But bsnmpd is interesting. It could have just been the last thing that tried to allocate RAM.
-
@michmoor It ultimately depends on the usage. I run FRR on a lab with all devices at 1GB and haven't had issues with it. I don't think I'd run pfBlockerNG, Suricata/Snort, and FRR all on the same 1GB device, but that's not to say it can't work.
-
@marcosm
FRR its for bgp and only for advertising less than 2 prefixes and receiving 10. Def not meant for edge routing in that way.The unit was also up for over 100 days so could it be possible there was some memory not properly released?
In either case, successful upgrade and re-adding the packages is a snap. I will be thinking a bit more carefully about what packages will get installed at a future point.
-
FWIW, ran into this with a client's 1100 tonight. Got the "137" error and it also logged, "pid 56451 (pkg-static), jid 0, uid 0, was killed: failed to reclaim memory" to get it into this thread.
The first time the update page showed the 137 error, the second time it didn't "stop" updating, just hung.
System Activity showed this before restart:
Mem: 11M Active, 37M Inact, 231M Wired, 520M Free
ARC: 57M Total, 25M MFU, 29M MRU, 181K Anon, 357K Header, 2701K Other
37M Compressed, 96M Uncompressed, 2.60:1 Ratioafter restart, when the upgrade succeeded (from the command line):
Mem: 125M Active, 73M Inact, 262M Wired, 472M Free
ARC: 82M Total, 25M MFU, 55M MRU, 114K Anon, 554K Header, 2330K Other
61M Compressed, 145M Uncompressed, 2.36:1 RatioAnother 1100 with a similar config updated fine from the web GUI.
-
Going forward this should be less of an issue. We reduced the memory requirement for pkg by using a different compression.
