Description of problem:
It was found during CentOS 7 QA testing that when one installed CentOS 7 on a VirtualBox VM in UEFI mode and with an encrypted filesystem, the startup process got stuck after "tsc: Fast TSC calibration failed" message and prior to the system asking for the passphrase for the volume.
The following combinations do work:
- CentOS 7 in BIOS mode on VirtualBox using an encrypted fs
- CentOS 7 in UEFI mode on VirtualBox not using an encrypted fs
- CentOS 7 in UEFI mode on real hardware using an encrypted fs
It is only the combination of all these three components that causes problems.
This was also tested on RHEL7 rc1, and it had the same problem. I do not have access to RHEL7 GA, but I find it likely that it will exhibit similar problems.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a new virtual machine in VirtualBox
2. Check the "Enable EFI support" checkbox from the Settings > System > Motherboard page
3. Install CentOS7/RHEL7 with the "Encrypt my data" option selected
After selecting the appropriate kernel version from grub, the system gets stuck prior to asking the volume password.
THe system should ask for the volume password.
It is unclear at this time if this is a bug in RHEL/CentOS or VirtualBox. This bug has been reproduced with VirtualBox 4.3.10 and 4.3.12. If this is a RHEL issue, I'm not sure if cryptsetup is the correct component. Feel free to change. A workaround to this problem is to remove the "rhgb quiet" options from the kernel command line.
There are now reports that this is occurring on VMware Workstation (versions 8 and 10) as well, also in BIOS mode.
Obtain a full log of boot messages from a system that works and one that fails and attach them to this bugzilla. Look at where they diverge. Then presumably anything that happens between those points might be the culprit. Try to use sysrq to obtain information about what the processes and kernel are doing and what they are waiting for.
(I think it's unlikely to be the cryptsetup component by the way.)
Transferring to systemd, where there are probably more people with a better idea of what to look for and how to obtain diagnostics.
Created attachment 918383 [details]
Screenshot of a plymouthd crash with some debug output enabled
Preliminary testing with some debug output enabled shows that it's plymouthd that is crashing for some reason, and the bootup process can't recover from the crash.
This is still happening on CentOS 7.1.1503, and presumably on RHEL 7.1 as well.
Best regards, avij from the CentOS QA team.
Happens on ESXi 5.5 with CentOS 7.1.1503 as well. Only message you get is
"sd 0:0:0:0 [sda] Assuming drive cache: write through"
and a blinking cursor.
Disabling plymouthd works here as a workaround. Remove "rhgb" from the boot line and from /etc/default/grub after booting. Then perform" grub2-mkconfig -o /boot/grub2/grub.cfg".
(In reply to Anssi Johansson from comment #6)
> Created attachment 918383 [details]
> Screenshot of a plymouthd crash with some debug output enabled
> Preliminary testing with some debug output enabled shows that it's plymouthd
> that is crashing for some reason, and the bootup process can't recover from
> the crash.
Looks like plymouth issue, it should not end with segmentation fault.
Problem still persists in RHEL 7.1. I tried to install RHEL-7.1-20150219.1-Workstation-x86_64 on virtualbox (version 4.3.26).
Adding versions of components:
I believe the fixes from bug 1097174 should fix this too.
bug 1097174 is not open to the publix. Can someone copy the fixes?
Created attachment 1045903 [details]
patches from other bug
I can get plymouth password prompt in vmware machine.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.