Blog

Understanding the Boot Failure: Two Failed Services

When I tried to spin up my CentOS 7 guest—running on kernel 3.10 within VirtualBox 6.0.10—the boot process didn’t behave as expected. Instead of reaching a stable login prompt, the system stalled mid-way through the startup sequence.

Upon inspecting the console logs, I noticed two critical error messages that pointed to exactly where things were breaking down: [FAILED] Failed to start Virtual Machine and Container Registration Service and [FAILED] Failed to start Login Service.

At this stage, I wasn’t entirely certain of the smoking gun. It looked like a potential issue with the SELinux configuration—specifically how it was interacting with the system’s boot state—but I also had to consider that this might be a known bug within VirtualBox 6 itself. Regardless of the exact culprit, these two service failures were preventing me from accessing my environment.

Prerequisites for Troubleshooting

Before diving into the fix, I made sure I had a few things in place—this approach means editing system files during boot, so a little preparation goes a long way:

• Access to the VirtualBox console. You need to be at the keyboard when the VM first powers on, ready to catch the GRUB menu before it hands off to the kernel. (My environment was a CentOS 7 guest on VirtualBox 6.0.10.)
• A snapshot or backup first. Since we’ll be remounting the filesystem and editing /etc/selinux/config, take a VirtualBox snapshot beforehand. If anything goes sideways, you can roll straight back.
• Comfort with a terminal editor. The fix happens in vi inside a minimal rescue shell, so basic vi navigation (insert, save, quit) is all you need.
• Knowing your boot entry. If GRUB lists multiple kernels, be ready to identify your primary CentOS entry—that’s the one we’ll edit.

Step 1: Revealing the Hidden Boot Errors (Exit Quiet Boot)

When I first encountered the boot failure, I was met with nothing but a static progress bar. By default, CentOS 7 uses a “quiet boot” setting that hides the technical minutiae of the startup process behind a clean splash screen. While this looks professional, it is incredibly unhelpful when you are troubleshooting a system that refuses to start.

To see what was actually happening under the hood, I needed to reveal the full system logs. As soon as the boot sequence begins, pressing the Esc key interrupts the quiet mode and displays the detailed text-based output. By doing this, I was finally able to see the specific [FAILED] messages—such as those regarding the Virtual Machine and Container Registration Service—that provided the first real clue into the system’s instability.

Step 2: Booting CentOS into Rescue Mode via GRUB

Once I realized the standard boot process was hitting a wall, my next move was to use the GRUB menu to bypass the failing services and drop straight into a command-line environment. It’s important to note that GRUB itself isn’t corrupt—it is still functioning perfectly as our entry point—we just need to change how it hands off control to the kernel.

Here is exactly how I navigated through the bootloader to enter rescue mode:

1. Select the Entry: When the VirtualBox window displays the GRUB boot menu, use your arrow keys to highlight your primary CentOS boot entry.
2. Edit the Boot Parameters: Press the e key on your keyboard. This opens an editor that allows you to modify the boot instructions before they are actually executed by the system.
3. Modify the Linux Line: Scroll down through the text until you find the line starting with linux16. This line contains the kernel-specific arguments and parameters. Navigate to the very end of this line, add a space, and append: systemd.unit=rescue.target
4. Execute the Boot: Once the parameter is added, press Ctrl+X (or F10) to boot with these new settings.

This process forces CentOS to skip the standard multi-user startup sequence—where the failing services are triggered—and instead boots you directly into a minimal, single-user rescue environment where we can address the SELinux configuration issues manually.

Step 3: Fixing the SELinux Configuration (the Root Cause)

Once I was settled into the rescue shell, my first task wasn’t editing files—it was making sure I could actually save them. Depending on how the system lands in rescue mode, the root filesystem can come up read-only, so to be safe I remounted it writable before touching anything:

mount -o remount,rw /

With write access secured, I turned my attention to the primary suspect: the SELinux configuration. SELinux sits deep in the boot path, and when its policy gets tangled up with the system’s state—as it can in a quirky VirtualBox guest—it’s capable of quietly stalling the very services CentOS needs to finish starting.

I opened the configuration file using vi:

vi /etc/selinux/config

Inside the file, I located the line starting with SELINUX=. Here is the detail that made this issue so hard to pin down: it wasn’t set to enforcing, as you might assume. It was already on permissive—a mode that is only supposed to log policy violations, not block anything. That’s precisely why SELinux is such an easy culprit to overlook here; on paper it shouldn’t have been able to stop those services at all. Yet they still refused to start. So rather than half-measures, I turned SELinux off completely:

SELINUX=disabled

Setting the mode to disabled takes SELinux fully out of the boot path on the next startup, which is what finally cleared the conflict stalling the Registration and Login services. I saved the file and exited the editor. (If you’d prefer to keep SELinux active for security, you can switch it back to enforcing once you’ve confirmed the VM boots reliably—but for getting a stuck machine running again, disabling it is the fastest, most decisive fix.)

Step 4: Verifying the Fix and Ruling Out the VirtualBox 6 Bug

After saving my changes in rescue mode, I performed a standard reboot to see if the system would finally reach the login prompt. This time, the boot sequence progressed smoothly; those alarming [FAILED] messages that had been stalling the startup process were nowhere to be seen.

To double-check my work, I ran getenforce once the system was up. The output came back Disabled, confirming SELinux was fully switched off and no longer interfering with the services that had been failing to initialize.

While the VM is now stable, I kept one caveat in mind: the environment involves VirtualBox 6.0.10. There have been documented instances of specific service failures linked to bugs within this particular version of the hypervisor. While correcting the SELinux configuration solved my immediate problem, if you encounter similar boot issues on a different machine even after following these steps, it is worth considering that the issue might reside in the VirtualBox software itself rather than your CentOS configuration.