Bug 1116159 - Encrypted filesystem in UEFI mode on VirtualBox or VMware Workstation does not display the passphrase prompt
Summary: Encrypted filesystem in UEFI mode on VirtualBox or VMware Workstation does no...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: plymouth
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ray Strode [halfline]
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-03 22:50 UTC by Anssi Johansson
Modified: 2015-11-19 12:49 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-19 12:49:35 UTC
Target Upstream Version:


Attachments (Terms of Use)
Screenshot of a plymouthd crash with some debug output enabled (125.17 KB, image/png)
2014-07-16 10:34 UTC, Anssi Johansson
no flags Details
patches from other bug (22.77 KB, patch)
2015-07-03 18:50 UTC, Ray Strode [halfline]
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
CentOS 7293 0 None None None Never
Red Hat Product Errata RHBA-2015:2405 0 normal SHIPPED_LIVE plymouth bug fix and enhancement update 2015-11-19 11:13:25 UTC

Description Anssi 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.

Comment 2 Anssi Johansson 2014-07-14 10:06:28 UTC
There are now reports that this is occurring on VMware Workstation (versions 8 and 10) as well, also in BIOS mode.

Comment 3 Alasdair Kergon 2014-07-16 00:59:07 UTC
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.

Comment 4 Alasdair Kergon 2014-07-16 01:00:14 UTC
(I think it's unlikely to be the cryptsetup component by the way.)

Comment 5 Alasdair Kergon 2014-07-16 01:05:12 UTC
Transferring to systemd, where there are probably more people with a better idea of what to look for and how to obtain diagnostics.

Comment 6 Anssi Johansson 2014-07-16 10:34:10 UTC
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.

Comment 7 Anssi Johansson 2015-03-26 19:10:58 UTC
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.

Comment 9 Robert 2015-04-17 07:22:18 UTC
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.

Comment 10 Robert 2015-04-17 10:24:46 UTC
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".

Comment 12 Lukáš Nykrýn 2015-04-20 15:30:07 UTC
(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 13 Ladislav 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 14 Ray Strode [halfline] 2015-07-03 17:21:36 UTC
I believe the fixes from bug 1097174 should fix this too.

Comment 15 Akemi Yagi 2015-07-03 17:49:28 UTC
bug 1097174 is not open to the publix. Can someone copy the fixes?

Comment 16 Ray Strode [halfline] 2015-07-03 18:50:52 UTC
Created attachment 1045903 [details]
patches from other bug

Comment 18 Tomas Pelka 2015-09-14 12:39:29 UTC
I can get plymouth password prompt in vmware machine.

Comment 19 errata-xmlrpc 2015-11-19 12:49:35 UTC
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


Note You need to log in before you can comment on or make changes to this bug.