Issue: pfSense appears to hang at boot after upgrading to version 2.4.4

For our router and firewall needs we utilize a robust device for pfSense, the Protectli FW1. You can find more information on how we build and configure these devices on our MIT Recommendations page.

 

The Problem:

Recently we began upgrading these devices to pfSense 2.4.4 and noticed that during the post-upgrade reboot, the device appeared to hang or freeze at the ‘Booting…’  portion of the text printed to the console, when looking at the video (VGA) output for the device. Where this portion would typically show a rotating icon of slashes and dashes, it would freeze showing only one of  \ | / -.

This would’ve been an even bigger cause for concern if the device was not still accessible via its console and network ports, letting us know that the device was in fact booting, it only stopped displaying video output beyond this screen of the bootup process.

But why were our pfSense devices behaving this way after upgrading from pfSense version 2.4.3 to 2.4.4?

After a cursory search on Google, it quickly became apparent that this issue was not limited to our environment or our ProtectLi devices. The issue had already occured for a number of users on NetGate support forums:

These posts lead us to review the release notes for pfSense 2.4.4 where this was already added as a known issue. ProtectLi, the manufacturer of the pfSense devices we use also posted a solution to this issue.

Like many other pfSense users, our pfSense devices fit the case described:

  1. Upgrading from pfSense version older than 2.4.4
  2. Intel-based system using Intel HD Graphics GPU (it should be noted that the NetGate release notes here describe this issue as only affecting Intel Atom systems, though our ProtectLi FW1’s use an Intel Celeron J1900 and exhibited the exact behavior described).
  3. pfSense installed in a legacy boot mode (non-UEFI).

It’s easy to see how the three conditions above are bound to create this problem for a wide variety of users (until the issue is resolved in a subsequent version) for a few good reasons:

  • Intel systems with these GPUs are widespread and the onboard graphics output would almost always be used for video out.
  • Small-form factor, barebones systems or devices built for purposes of running firewall and router software are more likely to ship with Legacy boot mode enabled than UEFI as on consumer PCs.
  • System administrators, IT professionals and other users running pfSense are likely to install it in a legacy mode given that it runs on FreeBSD — an OS which lends itself to simplicity and reliability, much like a Legacy boot mode lends itself to.

The Solution:

The solutions offered by NetGate here all worked in resolving the issue:

  • Add the following line to /boot/loader.conf.local to enable the syscons console type:
    kern.vty="sc"

    (Note: NetGate’s instructions on this are slightly incorrect – the quotes around “sc” are needed when editing /boot/loader.conf)

    -or-

  • Add the following lines to /boot/loader.conf.local to use the i915 driver with the standard console type:
    i915kms_load="YES"
    drm.i915.enable_unsupported=1

    -or-

  • Simply backup your configuration from the webGUI or Secure Shell, reinstall the latest release of pfSense on your device in UEFI mode and then restore your configuration.

After trying all three solutions, we determined the best solution was simply reinstalling pfSense in UEFI mode and restoring our configuration.

Our reasoning behind this is relatively simple:

  1. Changing the console type to a legacy type designed for virtual terminals might negate improvements to the console appearance and functionality in future releases.
  2. Enabling a different kind of video driver could have unintended consequences in the current or future release. NetGate pointed this out in their release notes as something that could specifically cause issues with resource hungry systems with multiple NICs. Why risk an unpredictable failure in the future for video output?
  3. Despite our feelings and opinions, UEFI is here to stay. If something like a major PHP version upgrade or major pfSense version upgrade is enough to cause issues in non-UEFI installations now, what could the future hold for non-UEFI installations? pfSense installs and restores so quickly and seamlessly, the minor downtime here far outweighs the potential for future headaches.