Bug 1487879

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 ***