Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionAnssi Johansson
2014-07-03 22:50:04 UTC
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):
RHEL7rc1 (Server)
How reproducible:
Always
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
Actual results:
After selecting the appropriate kernel version from grub, the system gets stuck prior to asking the volume password.
Expected results:
THe system should ask for the volume password.
Additional info:
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.
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.
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.
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.
Comment 13Ladislav Kolacek
2015-05-11 08:07:40 UTC
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:
kernel-3.10.0-229.el7.x86_64
plymouth-0.8.9-0.13.20140113.el7.x86_64
gnome-shell-3.14.2-3.el7.x86_64
Comment 14Ray Strode [halfline]
2015-07-03 17:21:36 UTC
I believe the fixes from bug 1097174 should fix this too.
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.
https://rhn.redhat.com/errata/RHBA-2015-2405.html