2.4.4 Install failed



  • Hi,
    I updated my community edition from 2.4.3 to 2.4.4 but found the box "dead" after reboot. Only after choosing to boot the kernel.old the system came back online. Otherwise the system was stuck immediately after "Booting..."
    Since the system should automatically boot correctly and the current kernel did not work, I went for a fresh install from the USB stick but the USB stick boot was stuck at the same "Booting..." point.
    Then I tried booting the USB stick in UEFI mode from the BIOS boot menu, which worked through the complete installation process.
    Just as the system tried its first boot from the hard drive, regardless on whether I chose MBR or GPT, it only starts in BIOS mode and stays stuck at "Booting..."

    I tried a new BIOS version, as well as BIOS only settings, UEFI only setting or mixed settings, either with UFS install or ZFS install. In all scenarios the USB install boots only in UEFI mode but installs a non-working system. I even tried the latest development build from today with the same result.

    The system worked fine for months, just today after the update to 2.4.4 it suddenly does no longer boot even a fresh install. Does any of you have any further ideas on what else I may try to get the pfsense in a current working state?

    Thanks!

    So long,
    Marc



  • Read the release notes and upgrade guide, the solution is in there.



  • Sorry, but what are you referring to? The only issue I found (in https://www.netgate.com/docs/pfsense/install/upgrade-guide.html#upgrading-from-versions-older-than-pfsense-2-4-4) was the passage with "Intel Atom systems containing HD Graphics chipsets..." but unfortunately "... Affected systems will boot successfully..." does not apply as the system hangs completely and it is not just the console issue.
    Do you have another link or some more specific information?

    To follow up, I have now installed a fresh 2.3.5 release (which worked fine) and went to upgrade from there. After the Upgrade to 2.4.4 the system hangs just the same as with the 2.4.4 fresh install.

    So long,
    Marc


  • Global Moderator

    Hello, Marc
    What device is it? If 2.3.5 works, but 2.4.4 doesn't - maybe it's old 32bit platform.



  • @Asamat - He had 2.4.3 running, so it's not 32 bit hardware.
    @Marc1701 Are you sure the system is hung? Have you tried installing via serial? You tried the webgui/ssh? Grimson is suggesting that perhaps the screen is not displaying anything, so it appears to be hung, but isn't actually hung.



  • Hi,
    the system runs on an older Celeron J1900 but it is 64bit capable. Output is VGA (intel onboard graphics).

    I suspect there is a problem with the UEFI/BIOS boot here, since I tried the AMD64 64bit USB memstick VGA installer in both versions 2.3.5 and 2.4.4. The 2.3.5 has just one type of boot option and boots and installs just fine and the system then starts from hard disk.

    If I try to install from the same sort of 2.4.4 memstick, I have 2 boot options for the stick, either BIOS or UEFI.

    If I start the 2.4.4 installer from the stick using the BIOS option I see the same behavior I see with the installed 2.4.4 booting from hard disk, just after the boot menu it starts "Booting..." and nothing happens then, and the system is not accessible via network (no webinterface, not even ping).

    If I start the memstick with the UEFI boot option, the booting continues past this point, all the install works just fine, I can chose to either install UFS or ZFS, etc. After the install process is done, the boot from hard disk is still BIOS only and does not work correctly. Since the UEFI boot from the stick works fine, and the BIOS boot doe not, maybe the "easy" way would be to get the UEFI boot from the HD installation to work just like the memstick installer? What changed in the booting process using BIOS boot from 2.4.3 to 2.4.4, so maybe fixing this might actually be the better solution?

    So long,
    Marc



  • Hi,
    just to make sure, this issue is not fixed, I just tried installing 2.3.5, made no changes at all to the config, plain vanilla auto install and boot from HD. Then I chose from the System->Update->Update Setting the latest Development build path and updated the system from 2.3.5 to 2.4.5.a.20181031.0820. The effect stays the same, the system still fails to boot. Even after about 20 minutes wait (in case the system actually did boot but just the VGA display was not working), the 192.168.1.1 is unresponsive and the display is stuck at "Booting..."

    As I was looking further, my guess would be this issue to have its roots in the FreeBSD 11.2, as there seem to be others who have very similar issues on FreeBSD 11.2 with Celeron and UEFI boot. Should this be a bug that needs to be addressed and reported? Where would be the correct place to do so?

    So long,
    Marc



  • So did you add

    kern.vty=sc
    

    to "/boot/loader.conf.local"?



  • @Grimson: Thank you, just until now I was unable to get there on the system.

    Now this is what I did: After the update I got into the boot menu and selected the menu 5 (booting kernel 2) to start the kernel.old completing the update which finished and rebooted again. Just, since it started the default kernel, the system was stuck again.
    So I selected the kernel.old again and the system finally started as a "2.4.5-DEVELOPMENT (amd64) built on Wed Oct 31 08:21:34 EDT 2018 FreeBSD 10.3-RELEASE-p22".

    Since now I had a running system with a console again, I was able to edit the /boot.loader.conf.local and add the missing line. And finally on the next reboot the system actually boots the default kernel on its own and reports as "2.4.5-DEVELOPMENT (amd64) built on Wed Oct 31 08:21:34 EDT 2018 FreeBSD 11.2-RELEASE-p4".

    So thanks again, the system is working at last. Nevertheless maybe the update/installer might be fixed to add this line on its own?

    So long,
    Marc


  • Netgate Administrator

    There's no way to know what systems might require that workaround AFAIK. Most do not.

    However usually when you hit that it boots normally after the upgrade just without a console. That means you can add that loader variable via SSH or in the GUI to correct it.

    Steve



  • @marc1701 hey marc, I am so happy to find you as I have the same exact J1900 celeron I just wanted to chime in, I was also experiencing the same issue as you, it would get stuck at boot when going from 2.3x to 2.4x, I followed your instructions and chose kernel.old (option 5) twice, the second time it booted in to 2.4.4-RELEASE , I cannot express my gratitude for your words on this forum you don't understand how much headache you have saved me, thank you so much!