upgrade to 2.4.4 hangs at booting...
-
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.) -
@rbrtpfsense said in upgrade to 2.4.4 hangs at booting...:
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 . . .
-
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?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172
-
@tomtheone said in upgrade to 2.4.4 hangs at booting...:
What about this?
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230172
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.
-
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.)
-
Good article, thank you
-
You should put that value in /boot/loader.conf.local as we describe here:
https://www.netgate.com/docs/pfsense/install/upgrade-guide.html#upgrading-from-versions-older-than-pfsense-2-4-4Putting it in loader.conf it will be removed at the next update and you'll have to do it again.
Steve
-
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?
Steve
-
Hi Stephen
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?
Best regards
Tom -
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.
Steve
-
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!
-
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 thekern.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.
Steve
-
Is the line entry attached correct or should it be placed elsewhere??
-
The entry should be:
kern.vty=sc
It should be in the file /boot/loader.conf.local. We can't see what file that is you're using.For exmple:
[2.4.4-RELEASE][admin@home.stevew.lan]/root: cat /boot/loader.conf.local kern.cam.boot_delay=10000 kern.vty=scSteve
