Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem:I updated my virtual machine (guest host) which has an encrypted volume group. After the update, the widget which prompts for the encryption password accepts only eight characters, and apparently the software does not process them properly. Version-Release number of selected component (if applicable): (I don't know which component is causing the problem) How reproducible: always Steps to Reproduce: 1.Install Fedora 26 Workstation on a virtual machine managed by virt-manager. Use auto-partitioning, and encrypt the disk during the installation. 2.Reboot. When prompted, type the disk encryption passphrase. (This works.) 3.Run "sudo dnf -y update" 4)Reboot. When prompted, try to type the disk encryption passphrase. The widget will only accept eight characters. However, when I repeated the installation/test with a seven character passphrase, it did not work either. Actual results: VM is apparently unbootable. Expected results; Expected the VM to boot when the correct passphrase is supplied. Additional info: When I tried an eight character disk encryption passphrase, it acts as though it doesn't see the carriage return. I tried a seven character passphrase, it displays the Fedora "teardrop" in grey, but does not progress any further. Using qemu-nbd, cryptsetup, and various lvm tools, I was able to mount the virtual machine's encrypted logical volume, so apparently the installation is encrypting the disk image correctly. I also performed an installation without encrypting the volume group. Under MATE, if you change the display resolution on the VM, it is almost impossible to use due to visual artifacts, so the problem may lie with whatever replaced X11. (I was a RHCE and RedHat admin for ~13 years at NASA/JSC and at a hospital, but I retired in 2011, and haven't kept up.)
I'm sorry for such a disjointed bug report. I was/am in a hurry to pay my September bills. I use the VM with encrypted disk image only for bill paying and investment management. By only connecting with those two websites from the VM, and keeping all my important financial information on the VM (which only runs a few hours per month, the rest of the time it's just an opaque encrypted file), I believe that I increase the security of my data and those transactions. I've been doing things this way for several years, and this is the first time I've seen these issues. I discovered the bug after powering up after Hurricane Harvey a few days ago. I originally thought that I must've screwed something up, perhaps by updating the host machine's OS (also Fedora 26 Workstation) while the VM was running, or updating one of them but not the other. Since I couldn't figure out how to boot the VM, I decided to replace it. I used qemu-nbd, cryptsetup, and the lvm tools to mount the VM's root filesystem on the host system and created a tar file of my home directory (where all the financial records are kept) putting the tar file on the host system. (I wanted the tar file to ensure that I had the latest transactions backed up.) The tar file is readable and makes sense. This indicates that the installer and cryptsetup are using equivalent cryptography and that I know the proper passphrase. I created a second VM and installed Fedora 26. I updated that VM's OS and rebooted. The boot failed, and that's when I realized that it must be a bug. Because I need to pay my bills in the next few days, I re-installed the VM using an eight character passphrase, updated, and rebooted it. As I said above, it looks like the widget does not see the carriage return (signifying the end of the passphrase). I then re-installed the VM using a seven character passphrase, updated, and rebooted it. The widget took the passphrase, the outline of the Fedora "teardrop" progress indicator appeared, but light-grey filled. After many minutes, the boot process did not seem to make any progress. I didn't mean to "strut my stuff" by mentioning that I'm a former RedHat server admin, I know that I'm fallible, this could be something that I've done wrong. If so, I'm doing it consistently wrong. One point that I didn't make clearly though is that as a _server_ admin, I never spent much time on X, window managers, GUIs, and etc. After installing the MATE Desktop on an updated Fedora 26 VM, dragging windows around, resizing them, closing them, and etc. leaves pieces of window border on the desktop. While installing MATE, I was using GNOME 3, and didn't have the visual artifact issue. (I'm sorry. I just don't like the GNOME 3 user interface.) Another point to make is that I'm running Fedora 26 Workstation with an encrypted volume group and the MATE Desktop on the host (as opposed to guest, or VM) system. It boots reliably and does not have the problems with visual artifacts. So the bug seems to be virtual machine and possibly X, window manager, GUI, or etc. related.
Thanks for the report, I can reproduce. Workarounds are to either set 'nomodeset' on the kernel commandline, or just switch to a new VM graphics device like 'VGA' which doesn't seem to do modesetting, same effect. My guess is this is either a regression in kernel qxl video handling, or more generally in plymouth, which is what displays the password UI
Is this related to: https://bugzilla.redhat.com/show_bug.cgi?id=1462381
(In reply to Dr. David Alan Gilbert from comment #3) > Is this related to: > https://bugzilla.redhat.com/show_bug.cgi?id=1462381 Indeed it likely is a dupe of that, thanks. So latest kernels should have the plymouth hang fixed, but unfortunately there's still lingering qxl graphical issues: https://bugzilla.redhat.com/show_bug.cgi?id=1491320 Duping this to the plymouth hang *** This bug has been marked as a duplicate of bug 1462381 ***