Crashes while upgrading to 24.03 from the last stable
-
It could depending on where it was. But I still wouldn't expect it to reach the debugger like that.
-
@stephenw10 Would a hardware issue be able to cause a problem like this one? I built this server years ago and it is using an ancient OCZ SSD that could be about to fail at any time. I did move all logging to a remote syslog server to preserve it as much as possible.
-
I would expect a drive failure to be far more obvious then this. It looks more like a hardware interrupt has been triggered somehow.
Have you seen any further issues since the upgrade completed?
-
@stephenw10 I have not. It's been running just fine since yesterday.
-
Hmm, well it's odd but I wouldn't be too concerned since it did complete the upgrade and there was seemingly no panic.
If you see anything further we look at any crash reports. -
S stephenw10 forked this topic on
-
Hi @stephenw10, the problem can't be completely ignored... any time my router reboots, it has a decent chance of freezing on reboot (my guess is it freezes about 2/3rds of the time). Fortunately it's a VM so I don't need physical access, but still, a reliable reboot is pretty core to a reliable system, especially for remote access situations.
Mike
-
I agree but what you're seeing is a completely different problem. Which is why I forked it to a new thread.
-
After consulting with our devs here it seems this could in fact be caused by a bad or failing SSD. It's hitting whilst trying to run a checksum on the downloaded Snort ruleset.
So I would suggest that SSD has reached the end of it;s useful life!
-
@stephenw10 I'll have to bring the thing down and swap drives then, thanks!
-
@stephenw10 Just swapped the ancient OCZ drive with a much better one today. I just used dd to 1:1 copy data across and it's booting fine, but do I need to care about the "The backup GPT table is not on the end of the device" message? Obviously it's because the new drive is larger than the old one, but will this have any impact on pfSense?
-
No, not unless you have some boot issue that requires the use of the secondary table.
However you can try to use growfs to fill the disk if you wish. Run:
touch /root/force_growfsthen reboot and it should fill it during the next boot.
