upgrade to 2.4.4 hangs at booting...
Tried to perform a console update and on rerstart v2.4.4 hangs at "booting..." and the character in the next line below hangs at a 'dash' mark. (Suppose to roll thru 'dash', 'backslash', 'vertical mark', 'forward slash' etc. to give illusion of activity.)
Last three lines of screen shows:
/boot/kernel/kernel text=0x17....(long text string)
- <<< a dash mark that should be rotating and is not
HELP, the site is "down."
viragomann last edited by
Tried to restart the machine?
Does the firewall boot if you leave it alone? Try to reach it from the web interface.
If so, you probably need the video console change described near the end of https://www.netgate.com/docs/pfsense/install/upgrade-guide.html#upgrading-from-versions-older-than-pfsense-2-4-4
If it doesn't boot, you can still make that change, but you have to stop at the loader prompt or press a key at the kernel spinner and then enter
set kern.vty=scand then
It may also be faster to reinstall 2.4.4 directly and recover the configuration.
If none of that helps, post as much detail as possible about your hardware.
As suggested by jimp, I restarted, selected "boot prompt" and entered "set kern.vty=sc" and then "boot". IT began to boot but is now repeating ". . . [date time] init: can't exec getty '/usr/libexec/getty' for port /dev/ttyv0:" and the next line says: "Exec format error". These messages keep repeating with time changes only (every 30 seconds or so.)
Exec format errorimplies that the binaries are either in the wrong format (e.g. wrong architecture) or corrupted. Time to reinstall.
Most liking corrupted.
Before I say this, I want everyone to understand that I am sorry. In the past, upgrades have been flawless. I only started using PfSense at v2.4.2 or so, I still in my infancy as a PfSense user.
Now, I realize I'm upset and will re-install but, why would anyone post an upgrade to any piece of software that can break user space! I am sorry, as soon as there became problem, the upgrade should have been pulled back.
I am running a Protectli FW4A that has an Intel E3845 AES-NI cpu. Is this situation happening on Netgate hardware? If so, I wish I had spent the extra $$'s on Netgate but . . . $$'s too short.
Again, sorry for my "vent".
Because it doesn't break anything we've tested it on, only a handful of others have had issues, and most of those were on questionable hardware. Breaking in the way you describe is highly unlikely to have been caused only by the upgrade. There might be a disk issue at work there as well.
Reinstalling only takes a few moments, and if you use the "recover config.xml" trick in my link above, you don't even have to go out of your way to restore the old config.
rbrtpfsense last edited by rbrtpfsense
So, thanks. (Again, sorry for my vent.) And yes, I understand that I am part of "only a hand full". Like I said wish I'd spent the extra $$'s for Netgate. Got a feeling they (Netgate users) are not have issues like this.
Your saying that the re-install will find this "recover config.xml" file that exists on the current hard drive or do I need to have saved it somewhere?
My edit . . . sent reply, then read "Backup and Restore" page of docs. It says "The installer in 2.4 has a “Recover config.xml” option which will read a configuration off an existing installation being overwritten." Should have read first and then replied.
(Doing this re-install, this way is NEW unexplored user area for me. So, it's very much a newbie question.)
Grimson last edited by
As suggested by jimp, I restarted, selected "boot prompt" and entered "set kern.vty=sc" and then "boot".
How did you restart, did you issue a reboot via SSH or the WebUI? Or did you simply cut the power?
If you cut the power you likely corrupted the disk yourself.
Working in monitor connected to device with keyboard but, I suspect you are correct because at one point I unplugged the device to restart. So, did it to myself. My bad.
More soon . . .
anh last edited by
I had this problem upgrading from 2.4.3_1 to 2.4.4 release on an AsrockD1800M. A bios upgrade from 1.50 to 1.90 fixed all issues.
What about this?
What about this?
There is a bug report open for that, https://redmine.pfsense.org/issues/9021, but there isn't any resolution for it from FreeBSD yet.
TomTheOne last edited by TomTheOne
I'm affected as well, but did not try the workaround posted here yet. If i reinstall with UEFI (as suggested here), then i do not have the issue. Have to perform a coulple of updates, so i will give the option kern.vty=sc a try. An other option for me is to skip the whole 2.4.4 / 2.4.5 version for my installed base, because I need another fix as well that has been raised here.
Sorry everyone, I had forgotten about this thread.
Protectcli has discovered a work around that satisfies their devices. Go to their website the solution is bannered across the top of the first page.
(It is a video only problem. Users just cannot see that PfSense is running.)
TomTheOne last edited by stephenw10
Good article, thank you
You should put that value in /boot/loader.conf.local as we describe here:
Putting it in loader.conf it will be removed at the next update and you'll have to do it again.
It seems that this suggested workaround does not work for me. The system will display a console and does not stuck at " | Booting..." anymore, but short before the pfSense menu should appear, the box is rebooting out of nowhere. This keeps endless repeating.
There is no issue in case the BIOS was changed to UEFI boot and in case the pfSense 2.4.4 was installed from scratch.
Does it actually crash? Show a kernel panic?
Can you capture the last thing it shows before rebooting?
TomTheOne last edited by TomTheOne
No sorry, false alert. It had another root cause why the box rebooted at this stage - has nothing to do with pfsense itself.
Last question: Is it possible for the next installer, that this option "kern.vty=sc" could be added to the installer image as well (if it's still required then)? So we become able to install the pfSens to non UEFI systems from scratch?
Well, we have no way of knowing which systems will require it. But you can still enter it as a boot loader variable at the prompt when the installer boots. Same procedure as booting the installed image.
If FreeBSD fixes the original bug causing the problem then we wouldn't need any workarounds on the installer anyhow.
Got it - thank you a lot!
scottt732 last edited by
I ran into the first part of the same issue on a SuperMicro box where pfSense started up but the console was stuck at
Booting... /(I'm not running into the getty/ttyv0 issue).
I was able to ssh in and edit
/boot/loader.confto add the
kern.vty=scflag & reboot and it's good to go now. Thanks!
You should put it in /boot/loader.conf.local to avoid it being overwritten at update. Create that file if you don't have one.