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?
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?
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).
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.
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?