Booting F36 works normally; but when booting a 37 Live iso on a usb, after the initial boot-test media- troubleshoot screen, if I boot the media, I get a blank screen. for the record, this is now an issue with the latest from Alma and Rocky.
QUESTION: Apparently a Nvidia issue, is there a workaround? What is the expectations for a fix from Fedora or Nvidia?
Does the computer you boot with have a encrypted hard-drive in the system?
If yes try to …
Workaround:
… enter the password blindly and hit enter while the screen is black.
I remember a bug with Nvidia drivers until Kernel 6.1.6 where the resolution on the moment where you need to enter the PW for encryption is wrong, this makes the login field invisible.
Should be solved with Kernel 6.1.7, so we will need a new boot ISO with this kernel as a definitive solution. I do not know when this will happen.
The live iso does not mount drives on boot.
Can you switch to a text tty with CTRL+ALT+F5 when you have the blank screen? Or does it remain blank when you try that?
For any nvidia issue, please attach the output of the file generated from nvdia-bug-report.sh
There are many reason why one could experience a black screen.
One of them is in some optimus setup, you will need to add the PrimaryGPU options (when using Xorg which I still recommends for nvidia).
It remains blank.
Well, the initial challenge is to get some information from a live system that cannot write persistent logs while having no screen to get information.
Let’s try this to find out a little more:
When you have the live system’s boot screen, you can choose “Start Fedora-Workstation-Live 37”, “Test this media & start Fedora-Workstation-Live 37” and “Troubleshooting”.
Navigate to “Start Fedora-Workstation-Live 37” and press “e”. Now you are in an editor. There is a line that ends with “rhgb”. At the end of this line, add a space and then “3” so that the line ends now with “rhgb 3”. Then, do CTRL + X.
Now it should boot into a terminal and not up to the GUI. If that works, you should be able to login with the username “liveuser” without a password. Then, you can do sudo -s. Does this work out that way?
Did “rhgb 3” and then CTRL + X. Still followed by blank screen.
Note with “Troublshooting,” with nomodeset, it will launch an 800x600 screen. And again note, all works perfectly with the Live USB for F36.
without nvidia-bug-report archive we are shooting in the dark.
I do not know how to do that. Please advise.
Do you have the possibility to install a F37 on a USB drive with another machine? Then, update the kernel of this F37 to the current kernel, and then try to boot the affected machine with this USB drive that now contains an up-to-date F37. I suggest to only update the kernel (to 6.1.7 or soon 6.1.8), and then try this first. If this does work, let us know. If not, try a full update of the USB-drive-F37 and try again.
If a kernel update of the F37 solves the issue, we might inform the Workstation WG to update the current live image with a newer kernel. Otherwise, it might end up in filing a bug report and hoping the information that is available is sufficient to make something out of it (this might be complemented with precise hardware information, which you can get also with your F36).
Sorry. No other machine.
In that case, I see no alternative: file a bug report with all information you can get. Since we have no further indication, file against the kernel:
Add all information you have: the exact live image you are using (exact file name of the image you downloaded), all possibilities you tried that ended up in a blank screen, such as that it is still blank at runlevel 3 and with ctrl+alt+f5 and such, but also the possibility that enabled a 800x600 screen. And so on. Also add the information that both up-to-date F36 and F36 live work properly.
Also, add all information from your hardware (you may use your F36 to get precise hardware information). E.g., with inxi -Fz
If you choose the component “kernel” in bugzilla, it will give you a template you have to fill. Unfortunately, the dmesg they ask for cannot be provided. Make clear why.
Keep watching the bug report. Maybe someone has questions and potential solutions you have to test.
SUPPLEMENT: You may use a virtual machine to install a F37 on a USB drive. I suggest to try this at first and then elaborate the outcome when filing the bug, additionally to the points mentioned above.
So, pass (=add) the USB drive to the virtual machine (e.g., virt-manager with kvm/qemu), use the live image to install Fedora in the virtual machine on the USB drive, boot the USB drive within the virtual machine, update it, and then boot your host with that USB drive.
Will do. PS the Supplement is WAY over my expertise.
Unfortunate. The problem is that, given the many reports that are filed, reports with abstract information have to be often ignored since it is not possible to precisely evaluate the issue.
However, if the kernel of the live image creates such results on several machines / different hardware, this might lead the developers to just update the live image’s kernel. So it makes sense to at least inform them. I will post an information to the workstation WG, maybe they can keep an eye on if that happens to others as well. In the end, it is on them to do update the related image.
I suggest to at least add hardware information, as suggested above. Without that, the report has not much value and is unlikely to be considered. Maybe you could review the previous points and adjust the report.
Also, I do not think that you have tested it with the rawhide kernel?
I did. It’s an attachment.
PS I did also test a Rawhide version. It too failed.
A suggestion from the workstation WG:
You may try this: Index of /pub/alt/live-respins (respins are generated regularly with new kernels)
More information at Respins-SIG - Fedora Project Wiki
Assuming that you are using the normal Workstation with GNOME, the image for you would be F37-WORK-x86_64-LIVE-*.iso
F37-WORK-x86_64-LIVE-20230116.iso also results in blank screen.