Four Days of Chasing First-Boot Ghosts

20Oct 2026Posted by: mstauberCategory: Development

27 commits, 45 new pages, 268 edited ones and a small mountain of rebuilt RPMs - all for the first five minutes after installation.

Every server product is judged in its first five minutes. Not during the months it runs happily in production, not during the upgrade that goes smoothly - but in that narrow window between "installation finished" and "I can actually work with this thing". If that initial impression window is ugly, nothing that comes later makes up for it.

So we spent the last four days doing nothing but improving that first impression window.

What started as "let's fix a couple of post-install annoyances" turned into a full sweep across 5210R, 5211R and 5212R: 27 SVN revisions, 45 added and 268 edited pages, plus a pile of rebuilt RPMs across all three trees. Same changes in all three products, wherever the code allowed it. The work was done by Michael Stauber together with Greg Kuhnert, who kept installing, testing and poking at cold boxes until the last edge case gave up.

The headline: DHCP should not send you to the shell

The old ritual went something like this: Install BlueOnyx, watch it pick up a DHCP address, then log in on the console and run network_settings.sh before you could do anything useful. The GUI was there, but getting to it was needlessly awkward.

That is gone. On a fresh install with DHCP you now browse to the box, get the wizard's wait page while the constructors do their thing, and then the wizard itself - fill it in, hit save, and you land in the GUI. No shell, no manual step, no "log in as root first".

The shell path still exists, and it still works. It is now what it should always have been: The tool you reach for when you want to configure the network by hand, not a mandatory detour.

What else was lurking

Getting there meant removing a surprising number of edge cases, most of which only ever appear on a cold install - the kind of bug you never see on a running system, and therefore never fix:

  • The wizard could send you in circles. With the constructors still running, /wizard bounced through /user/personalAccount and back, or greeted you with "your login session has expired" before you had ever logged in. Now an unfinished box gets a proper wait page, and a finished one gets the wizard.
  • The capability cache could poison itself. A GUI hit during that same window cached an incomplete permission set - and then kept believing it. The cache is now versioned, validated against what CCE actually has, refuses to store partial results, and heals itself.
  • A CCEd restart mid-setup threw you out. The daemon gets restarted right after the constructors finish - precisely when the wizard hands over to the GUI. Sessions died, and the next page load landed on the login form. The GUI now rebuilds the connection, revalidates the session and, if needed, logs you back in transparently.
  • The console banner showed no address. Five different scripts wrote /etc/issue in two different formats, and the one that ran first had no IP in it. There is now a single writer, the address is there from the start, and the banner no longer redraws on every boot.
  • Dovecot and php-fpm refused to start before the constructors had run, filling the console with red text on a perfectly healthy install. Both ship what they need now.
  • EFI boot records were written slightly off on /dev/sda - on real hardware that is neither the right directory nor the right disk, and it failed silently every single time, because UEFI, Grub and/or the BIOS usually silently corrected it for you.
  • An empty /etc/fstab could survive an install, because a quota script moved the file before it had written the replacement.
  • PEAR modules were being pulled from pear.php.net during boot. Nobody needs that on a fresh box; it is gone from the boot path.
  • kdump and GoAccess were fighting the boot sequence. A one-character typo in a service loop re-enabled the crash kernel right after the installer had switched it off, and GoAccess was ordered into the middle of the constructor phase. Both now behave.
  • The license tab became the finalize tab. Small thing, but it removes a step that made no sense in the order it was presented.
  • The ISO installer inherited a submenu from which you can install the usual BlueOnyx flavors with enabled serial console access, too.

And because "while we're in there" is a dangerous sentence: The old Network statistics page was rebuilt on nftables and now lives under Usage Information → Network, with live counters and a 24-hour history. The old iptables-based accounting is gone - it had been quietly fighting with firewalld for years.

The point of all this

Not a feature release. Not a new module. Just the honest attempt to make a fresh BlueOnyx installation as close to flawless as we can technically get it - no console archaeology, no red text on a healthy system, no wizard that argues with you.

It is also the kind of work that is almost invisible when it succeeds: Nobody writes a forum or social media post about an install that simply worked. Which is exactly why we did it.

All of it has been tested on real hardware, on cold installs, with and without DHCP - and there is more polish in the pipeline. If you hit something on a fresh install that we missed, tell us: First-boot bugs are the ones we can only find by installing.

Oct 20, 2026 Category: Development Posted by: mstauber
← Return