4.0.2-rc2 ISO hangs before graphical installer starts
54 views
Skip to first unread message
Claudia
Nov 8, 2019, 3:08:08 PM11/8/19
to qubes-users
The last message on the console is always "[OK] Started Monitoring of
LVM2 mirrors, snapshots, etc. using dmeventd or progress polling" at
which point it just hangs. The cursor doesn't blink, and pressing enter
doesn't do anything. Some keys cause it to beep, though, and it does
respond to ctrl-alt-delete by rebooting after a few seconds, but the
screen remains completely frozen during that time. So it feels like it's
running normally except the screen is frozen. 4.0.1 installer worked
fine on the same machine.
Any ideas on how to debug something like this?
-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
LVM2 mirrors, snapshots, etc. using dmeventd or progress polling" at
which point it just hangs. The cursor doesn't blink, and pressing enter
doesn't do anything. Some keys cause it to beep, though, and it does
respond to ctrl-alt-delete by rebooting after a few seconds, but the
screen remains completely frozen during that time. So it feels like it's
running normally except the screen is frozen. 4.0.1 installer worked
fine on the same machine.
Any ideas on how to debug something like this?
-------------------------------------------------
This free account was provided by VFEmail.net - report spam to ab...@vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!
Claudia
Nov 9, 2019, 9:32:55 AM11/9/19
to qubes-users
Claudia:
ctrl-alt-f1 repeatedly during dom0 init (systemd), **before** it
freezes. At that point I could see the anaconda shell, followed by the
graphical installer.
The installation went fine, but now I'm experiencing the same problem
when booting the installed OS. It hangs at "Starting Show Plymouth Boot
Screen... Starting dracut initqueue hook...", just before it should
prompt for the disk password. I was able to get to the console-based
(not graphical) disk password prompt a few times by pressing random
keys, but I can't make it work reliably (or I don't know what I did
exactly). Once again, it responds to ctrl-alt-delete but the screen is
frozen.
In both cases (installer and installed), it seems to freeze within a few
lines of "Starting Show Plymouth Boot Screen". So I have a feeling it's
being caused when Plymouth tries to switch into graphical mode.
Any ideas would be helpful. Is there any way to make it boot in text
mode up until lightdm?
Note, I'm using AMD Vega graphics, there is no dGPU, and neither of
these problems were present on 4.0.1, even under kernel 4.19.
> The last message on the console is always "[OK] Started Monitoring of
> LVM2 mirrors, snapshots, etc. using dmeventd or progress polling" at
> which point it just hangs. The cursor doesn't blink, and pressing enter
> doesn't do anything. Some keys cause it to beep, though, and it does
> respond to ctrl-alt-delete by rebooting after a few seconds, but the
> screen remains completely frozen during that time. So it feels like it's
> running normally except the screen is frozen. 4.0.1 installer worked
> fine on the same machine.
>
> Any ideas on how to debug something like this?
Okay, so oddly enough I was able to get past this by pressing
> LVM2 mirrors, snapshots, etc. using dmeventd or progress polling" at
> which point it just hangs. The cursor doesn't blink, and pressing enter
> doesn't do anything. Some keys cause it to beep, though, and it does
> respond to ctrl-alt-delete by rebooting after a few seconds, but the
> screen remains completely frozen during that time. So it feels like it's
> running normally except the screen is frozen. 4.0.1 installer worked
> fine on the same machine.
>
> Any ideas on how to debug something like this?
ctrl-alt-f1 repeatedly during dom0 init (systemd), **before** it
freezes. At that point I could see the anaconda shell, followed by the
graphical installer.
The installation went fine, but now I'm experiencing the same problem
when booting the installed OS. It hangs at "Starting Show Plymouth Boot
Screen... Starting dracut initqueue hook...", just before it should
prompt for the disk password. I was able to get to the console-based
(not graphical) disk password prompt a few times by pressing random
keys, but I can't make it work reliably (or I don't know what I did
exactly). Once again, it responds to ctrl-alt-delete but the screen is
frozen.
In both cases (installer and installed), it seems to freeze within a few
lines of "Starting Show Plymouth Boot Screen". So I have a feeling it's
being caused when Plymouth tries to switch into graphical mode.
Any ideas would be helpful. Is there any way to make it boot in text
mode up until lightdm?
Note, I'm using AMD Vega graphics, there is no dGPU, and neither of
these problems were present on 4.0.1, even under kernel 4.19.
Claudia
Nov 11, 2019, 7:42:53 AM11/11/19
to qubes-users
Claudia:
Okay, so I was able to disable plymouth by removing "rhgb quiet" from
the kernel command line. Now, the last thing on the console before it
freezes is "fb: switching to amdgpudrmfb from EFI VGA".
I looked it up, and this message has something to do with amdgpu. Adding
"nomodeset" to the kernel command line fixed it. It gives me the
text-based disk passphrase prompt, and eventually lightdm starts. It
seems to run fine after that, but I don't know if running with nomodeset
is really a good solution or not.
I still consider it a bug, because 1) amdgpu should work properly and
not have to be disabled, and it worked in previous releases, and 2) AMD
users should not have to debug the boot process and modify kernel
parameters right out of the box.
Thoughts?
the kernel command line. Now, the last thing on the console before it
freezes is "fb: switching to amdgpudrmfb from EFI VGA".
I looked it up, and this message has something to do with amdgpu. Adding
"nomodeset" to the kernel command line fixed it. It gives me the
text-based disk passphrase prompt, and eventually lightdm starts. It
seems to run fine after that, but I don't know if running with nomodeset
is really a good solution or not.
I still consider it a bug, because 1) amdgpu should work properly and
not have to be disabled, and it worked in previous releases, and 2) AMD
users should not have to debug the boot process and modify kernel
parameters right out of the box.
Thoughts?
Claudia
Nov 24, 2019, 9:30:47 AM11/24/19
to qubes-users
Claudia:
Apparently this is a known issue on my machine and many others. Many
people have found that iommu=soft corrects the problem without disabling
graphics drivers (amdgpu). I don't know if the Linux iommu parameter is
effective when running under Xen. For me, changing nomodeset to
iommu=soft just caused Qubes to boot loop, whereas before the screen
would freeze.
I noticed that Qubes uses the Xen option iommu=no-igfx, which "controls
whether the IOMMU in front of an Intel Graphics Device is enabled or
not" and is "specific to Intel VT-d hardware". Could this have anything
to do with it? It seems there is no AMD equivalent, and no way to
specify arbitrary devices as exceptions to IOMMU. So any changes would
affect all devices.
https://www.qubes-os.org/doc/intel-igfx-troubleshooting/
https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#iommu
I still don't understand why it worked fine out of the box in R4.0.1
though. Same for R4.1 pre-release (the installer, at least).
Anyone know anything about this?
people have found that iommu=soft corrects the problem without disabling
graphics drivers (amdgpu). I don't know if the Linux iommu parameter is
effective when running under Xen. For me, changing nomodeset to
iommu=soft just caused Qubes to boot loop, whereas before the screen
would freeze.
I noticed that Qubes uses the Xen option iommu=no-igfx, which "controls
whether the IOMMU in front of an Intel Graphics Device is enabled or
not" and is "specific to Intel VT-d hardware". Could this have anything
to do with it? It seems there is no AMD equivalent, and no way to
specify arbitrary devices as exceptions to IOMMU. So any changes would
affect all devices.
https://www.qubes-os.org/doc/intel-igfx-troubleshooting/
https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#iommu
I still don't understand why it worked fine out of the box in R4.0.1
though. Same for R4.1 pre-release (the installer, at least).
Anyone know anything about this?
Reply all
Reply to author
Forward
0 new messages