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.

The post How to Fix CentOS VM Client Boot Failure: A Step-by-Step Troubleshooting Guide appeared first on LarryLai.

“The selected virtual machine is inaccessible. Please inspect the error message shown below and press the Refresh button if you want to repeat the accessibility check.” After saving states of all virtual machines of VirtualBox running on Mac, rebooting the Mac host without any issue. Then it was a big surprised that all virtual machines are inaccessible. Not only the virtual hard disks, but all the virtual machines files.

Solution:

This case was caused by previously renaming the external SSD storing the virtual machine files. After renaming back to original disk name, still have to

• Remove the virtual machines and Add them back to VirtualBox by going to the VirtualBox application top bar
• Choose Machine -> Add
• Select the file with .vbox (that’s the virtual machine file, not the .vdi or .vmdk). In case, the there’s unexpected quit of VirtualBox, the .vbox may be corrupted, then it is necessary to rename the .vbox-prev to .vbox

Tricks:

• It is not easy to recognise that the issue was caused by renaming the path (in this case, the SSD disk) of the virtual machine as not until restarting VirtualBox, it is not observed there is any error on the virtual machines.
• Even after renaming back the path to the original one, VirtualBox still shows inaccessible virtual machine. The suggested solution of clicking the Refresh button located at bottom left cannot fix the problem. (Don’t know why Oracle is so stupid to suggest this!)
• The Machine -> Add appears only at the top bar of VirtualBox application, but not appear at the top bar of Oracle VM VirtualBox Manager
• It is easy to misinterpret the error message that it was due to inaccessible storage and it would be tempted to create new VM and access the same original storage, but it is not good in the sense that the virtual hard disk is located under the old VM’s directory.
• Mac users always have TimeMachine backup for the virtual machines, in such case restoring the VM directory is wasting time.

Config:

OS X           10.12.1

VirtualBox   5.0.28

The post VirtualBox VM Inaccessible on Mac appeared first on LarryLai.

Deleting the oldest snapshot of virtual machine in VirtualBox is often difficult, sometimes there is error with detail “more than one child hard disk”.

Solution:

Open VirtualBox control panel, select:

File->Virtual Media Manager

click on the Virtual child hard disk within the appropriate virtual machine (don’t check for other non-appropriate virtual machines) one by one, at the lower part of the panel, there are some information about the hard disk, “Type”, … “Attached to:”, etc., normally all child hard disk of the same virtual machine should be “attached to” the name of the Virtual machine, but at the problem child hard disk, the info. about the “Attached to” is Not Attached, then you can select “Remove” to take it out, if ask whether to “Keep” or “Remove”, for safety, you can keep the file, then go back to Snapshots to remove again the snapshot, the error should be gone.

Tricks:

• Similar error occur only on deleting the oldest snapshot but not recent snapshots.
• It is dangerous to just remove the hard disk file stored in the Snapshot directory of the virtual machine, and indeed remove snapshot process of Virtualbox is not just removal of virtual disk file, but some kind of merging the appropriate snapshot content with the current virtual hard disk. Inappropriate removing any snapshot files would be a nightmare to restart the virtual machine.
• In many forums, it is known that the error of deleting the first snapshot is a bug of VirtualBox for quite some years since ver. 3.x, but it still exists till this version 5. A shame to the technology giant, Oracle!

Config:

VirtualBox  5.0.10r104061

The post VirtualBox Delete Oldest Snapshot appeared first on LarryLai.

Starting Chrome in Windows 7 guest from Virtualbox happens to see only flicking windows with flashing rate around 2-4 rounds per sec.

Solution:

Turn off hardware acceleration in Chrome setting or uncheck 3D acceleration in Virtualbox.

Tricks:

When flicking occurs, you cannot start Chrome, thus no way to turn off hardware acceleration at setting. Either start Windows in safe mode, then start Chrome and change setting or shutdown windows then uncheck 3D acceleration setting in Virtualbox, and start windows again.

Config:

• Chrome 47.0.2526.80 m (64-bit) for Windows
• Windows 7 Service Pack 1
• Virtualbox  5.0.10

The post Google Chrome Not Start Only Flicking appeared first on LarryLai.

Trying to set up another Drupal site on free tier of Amazon cloud, the feeling and setup are all good! After setting up LAMP stack, suddenly received an email from Amazon that I recently reached a limit on the volume of email I was able to send out of SMTP port 25 on my instance. I was shocked on the one hand worrying about if my webserver was compromised and on the other hand questioned why the Security Group pre-set by Amazon EC2 did not work according to my expectation. It led me to enable the firewall of my linux, i.e. CentOS 6.

Issue:

Although open the specific port for webmin on the linux firewall, I forgot to open the SSH port 22, it caused a tragic connection lost to the virtual machine. That is, it could neither be connected through SSH login nor webmin. That may be caused by incorrect set up of the firewall rules such that the specific port for webmin was unexpectedly blocked.

Solution:

• Terminate the virtual machine and set up a new instance.
• Use webmin’s standard linux firewall rules and add some ports, but not other rules.

Configuration:

• EC2 micro-tier
• CentOS 6.4
• Webmin 1.620

The post Amazon EC2 Total Connection Lost appeared first on LarryLai.

As more depending on iPad (now iPad mini), few tasks are to be done on my current notebook PC, Acer Aspire 1810Z running Windows 7 Home Premium.

Rebuild desktop PC, HP from previous CentOS 5 to OpenSuse, I want to have a virtual Windows for some special situations, e.g. web applications need to run on MS Internet Explorer. Actually, still most payment gateways connected to the Hong Kong Government’s agencies need IE to proceed the payment transactions even though some of them allow you to make booking reservation online with other browsers.

Choosing Oracle VirtualBox as the virtualization platform rather than OpenSuse’s preferred Xen and KVM tools because I used to running my virtualized guest OS’ on VirtualBox for quite some years. My CentOS guest has been running the main webserver Apache on VirtualBox deployed in my Mac Mini for 2 years.

Methodology for the migration is using Windows 7 built-in backup system utilities to backup the whole system to external disk, and made a ISO bootable file to be used as the virtual boot CD in VirtualBox.

Issues:

1. Making VirtualBox to operating properly in OpenSuse was the 1st issue. After installation, only the root user could start it, but not other normal users. I run my desktop as normal user instead of root just for security reasons.
2. Could not restore the Windows backup image to a new virtual disk with error stating that no valid disk is connected to the system. Actually, by inputing Windows command “DISKPART” followed by “LIST DISK”, the newly created disk was shown. Even though using Gparted utility to make partition table on the disk and format the disk to ntfs file system. All these did not work.
3. After recovering from the backup image, still could not kick of the Windows VM. After seeing the Windows 7 logo, total black screen and nothing happened.

Solutions:

1. Run VirtualBox as non-root user.
   1. Install VirtualBox from Oracle site rather than from OpenSuse software repository. Also install Oracle VirtualBox extension Pack.
   2. Change permission of /dev/vboxdrv to allow other users to access this driver.
2. Select SATA controller to configure the virtual system disk to run Windows though transferring of files is fine using other types of storage controllers, say IDE. Configure a larger disk, say 160GB. Using a disk with small capacity say 40GB would cause the error mentioned above.
3. Configure VM with 2 processors instead of 1.

Tricks:

1. After installing VirtualBox from Oracle site, still some minor errors occur. Need to install/update some software in OpenSuse to clear the errors.
2. Even though the windows image is small, say 30GB, but I guess the original disk being backup was 120GB, then the target disk should not be less than 120GB. In case no physical capacity for disk is available. Thin provisioning of disk by selecting dynamic disk space allocation in VirtualBox is good.
3. I focused on changing the video RAM allocation for the VM and unchecking 3D, 2D acceleration. All these changes suggested on the web could NOT help for this scenario.

Config:

• CPU E8400 dual-core 3GHz, with 4GB memory
• OpenSuse 12.2 (x86_64)
• VirtualBox 4.2.8 r83876, and VM configuration below:
  • Processor No =2
  • Memory = 1.5GB
  • 3D and 2D acceleration checked
• Windows 7 Home Premium

The post Migrating Windows Physical Machine to VirtualBox appeared first on LarryLai.