Created attachment 1872063 [details] X.Log Description of problem: See bug https://bugzilla.redhat.com/show_bug.cgi?id=2067151 it seems that the problem only exists on Nvidia graphics cards https://bugzilla.redhat.com/show_bug.cgi?id=2067151 Tested with Fedora-Everything-netinst-x86_64-36-20220412.n.0.iso
Proposing as a Final blocker. This is a conditional violation of: https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#.27Basic_graphics_mode.27_boot_mode_behavior that only applies to Nvidia GPUs (certain or all, unclear). Stefan, does this happen only on UEFI, or also when booted in the Legacy BIOS mode? Can you please specify which Nvidia GPU you have? Please attach output of `lspci -nn | grep VGA`. Does Fedora 35 (netinst, Workstation) work for you OK both under UEFI and Legacy BIOS modes? Thanks.
GPU stefan@fedora ~]$ lspci -nn | grep VGA 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF110 [GeForce GTX 570] [10de:1081] (rev a1) in legacy BIOS modes, the Fedora-Everything-netinst-x86_64-36-20220412.n.0.iso has no problems. In UEFi it does not work Fedora 35: under UEFI and Legacy BIOS mode, runs f35 without problems as well as netinst, workstation, spins
https://bugzilla.redhat.com/show_bug.cgi?id=2074167 could this be relevant as well?
I have tested on an old laptop with a Nvidia Quadro K3100M, and it works as expected, I can't reproduce this issue. The main difference in my Xorg.0.log is that the vesa driver probe failed: [ 97.783] (II) VESA(1): initializing int10 [ 97.783] (EE) VESA(1): Cannot read int vect What would be helpful is to have your Xorg.log of the same machine with your AMD card, to see what is the difference. If it's using vesa or not.
Created attachment 1872240 [details] Xorg.log on laptop with Nvidia quadro k3100M uefi/nomodeset I've attached the Xorg.log when it's working on my laptop.
(In reply to Harish Pillay from comment #3) > https://bugzilla.redhat.com/show_bug.cgi?id=2074167 could this be relevant > as well? This bug is when booting with the nomodeset kernel parameter (called basic graphics in F36 installer). so probably a different problem I think.
Created attachment 1872385 [details] X.log from a non-working Nvidia computer On my computer NVidia computer, the basic graphic mode does not work. When Anaconda starts it brings up an error message saying that "X could not start" and I am offered to continue via text mode, either with VNC or text installation. The X.log is attached here and the card is: 03:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204GL [Quadro M4000] [10de:13f1] (rev a1)
(In reply to stefan from comment #0) > Created attachment 1872063 [details] > X.Log > > Description of problem: > > See bug https://bugzilla.redhat.com/show_bug.cgi?id=2067151 it seems that > the problem only exists on Nvidia graphics cards > > https://bugzilla.redhat.com/show_bug.cgi?id=2067151 > As others said, I believe this is a different problem. > > Tested with Fedora-Everything-netinst-x86_64-36-20220412.n.0.iso Are you using Nouveau or the Nvidia binary driver ?
(In reply to Javier Martinez Canillas from comment #8) [snip] > > > > Tested with Fedora-Everything-netinst-x86_64-36-20220412.n.0.iso > > Are you using Nouveau or the Nvidia binary driver ? Sorry, silly question since you are booting with "nomodeset"
I think I've an explanation. The vesa driver checks for the presence of /sys/devices/platform/efi-framebuffer.0 to not run when booted from uefi. https://gitlab.freedesktop.org/xorg/driver/xf86-video-vesa/-/commit/2645e0aa9c17c2c966a0533e52ad00510311483e with Fedora 36, the efi driver has changed to simpledrm, and the directory name is now /sys/devices/platform/simple-framebuffer.0 I will try to provide a patch to check if that solve this issue.
I've created a MR upstream: https://gitlab.freedesktop.org/xorg/driver/xf86-video-vesa/-/merge_requests/5 And I've done a koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=85665946 If someone can test it, and report if it works, that would be really helpful because I can't reproduce it.
This will be tricky, because one would have to build a new netinst with the koji build included. I don't think I can do it today, and the next working day is Tuesday. However, we could: 1. Verify that the same problem occurs when booting the latest KDE Live on UEFI using nomodeset 2. Install that KDE Live on UEFI *without* nomodeset 3. Boot once to make sure the installed KDE works 4. Verify that booting the installed KDE with nomodeset fails (if you see a login screen, try logging in using X11 session) 5. Install that koji build from comment 11 6. Boot the installed KDE with nomodeset and see if it works (if you see a login screen, try logging in using X11 session) Stefan, Lukas, could you do that? ^^
(In reply to Kamil Páral from comment #12) > This will be tricky, because one would have to build a new netinst with the > koji build included. I don't think I can do it today, and the next working > day is Tuesday. However, we could: > 1. Verify that the same problem occurs when booting the latest KDE Live on > UEFI using nomodeset > 2. Install that KDE Live on UEFI *without* nomodeset > 3. Boot once to make sure the installed KDE works > 4. Verify that booting the installed KDE with nomodeset fails (if you see a > login screen, try logging in using X11 session) > 5. Install that koji build from comment 11 > 6. Boot the installed KDE with nomodeset and see if it works (if you see a > login screen, try logging in using X11 session) > > Stefan, Lukas, could you do that? ^^ Make it only tonight or tomorrow
Created attachment 1872595 [details] KDE.Xorg0.log
the latest iso from today Fedora-KDE-Live-x86_64-36-20220414.n.0.iso does not work here again the X.org from the KDE iso see https://bugzilla.redhat.com/show_bug.cgi?id=2074789#c14
Comment on attachment 1872595 [details] KDE.Xorg0.log (From stefan's attached Xorg.0.log...) [ 38.407] (II) VESA(1): Bad V_BIOS checksum [ 38.437] (II) VESA(1): VESA VBE OEM Product Rev: GW-CLK@lÜÐ ˜„ Well, those are both disturbing to see! Some sort of corrupted read when accessing GPU memory, perhaps?
Stefan, have you followed the steps in comment 12 or have you just booted the compose ISO? (The nightly composes will not get the fix until it is pushed stable, so just booting the ISO is not enough to test it).
(In reply to stefan from comment #13) > (In reply to Kamil Páral from comment #12) > > This will be tricky, because one would have to build a new netinst with the > > koji build included. I don't think I can do it today, and the next working > > day is Tuesday. However, we could: > > 1. Verify that the same problem occurs when booting the latest KDE Live on > > UEFI using nomodeset > > 2. Install that KDE Live on UEFI *without* nomodeset > > 3. Boot once to make sure the installed KDE works > > 4. Verify that booting the installed KDE with nomodeset fails (if you see a > > login screen, try logging in using X11 session) > > 5. Install that koji build from comment 11 > > 6. Boot the installed KDE with nomodeset and see if it works (if you see a > > login screen, try logging in using X11 session) > > > > Stefan, Lukas, could you do that? ^^ > > Make it only tonight or tomorrow 2. Install that KDE Live on UEFI *without* nomodeset the step already does not work
Ah, well, that changes the situation quite a bit! That means that install media are completely broken on certain nvidia cards, and not just when using basic graphics mode. Is the log from comment 14 from booting with or without nomodeset? If with nomodeset, can you also attach the log without nomodeset? Lukas (from comment 7), can you please confirm whether your nvidia-based system can boot KDE Live/netinst on UEFI in the default configuration (without nomodeset), or whether you're affected just with nomodeset?
> That means that install media are completely broken on certain nvidia cards Yup, GTX 1070 (desktop, no igpu) - locks up completely upon boot (earlier betas got stuck on plasma splash screen, latest compose gets stuck when plasma panel loads - freezes mid animation). Can't provide any logs, since machine is completely unresponsive. Weirdly, basic graphics mode (nomodeset) works just fine on that machine. Tested on Fedora-36-20220418.n.0 KDE live compose. To add to that i think only wayland session is affected (live is wayland, right?) - i've installed beta with KDE desktop through everything netinstall some time ago, and anticipating the issue i logged straight to X11 session and it worked fine on nouveau.
As requested by Kamil, here's a boot.iso with the xorg-x11-drv-vesa build from comment #11 included: https://fedorapeople.org/groups/qa/2074789.iso
Stefan, Lukas, please test the ISO from comment 21 on UEFI using both a standard boot and a basic graphics boot, and report results (and logs, if failing). Thanks!
With the https://fedorapeople.org/groups/qa/2074789.iso basic graphics boo seems to work the standard boot mode does not work, also can not go with f2 or so to the root login.
(In reply to stefan from comment #23) > With the https://fedorapeople.org/groups/qa/2074789.iso > > basic graphics boo seems to work OK, this is a clear improvement over the original state, which means the fix works. Jocelyn, can you please make a proper build (the same as in comment 11), and also create a Bodhi update for it? Thanks! > the standard boot mode does not work, also can not go with f2 or so to the > root login. Stefan, please create a separate bug for it once more and report it here. That will be a bug in nouveau, probably, so separate from the vesa X11 driver.
(In reply to Kamil Páral from comment #24) > (In reply to stefan from comment #23) > > With the https://fedorapeople.org/groups/qa/2074789.iso > > > > basic graphics boo seems to work > > OK, this is a clear improvement over the original state, which means the fix > works. > > Jocelyn, can you please make a proper build (the same as in comment 11), and > also create a Bodhi update for it? Thanks! > > > the standard boot mode does not work, also can not go with f2 or so to the > > root login. > > Stefan, please create a separate bug for it once more and report it here. > That will be a bug in nouveau, probably, so separate from the vesa X11 > driver. Name for the next bug?
Name can be changed any time, so pick something :-) I'd go for e.g. "Nouveau is broken for certain cards on UEFI". Please include some basic details, like your lspci -nn output, which latest ISO failed to boot, and logs from that attempt if possible.
One thing that worries me slightly about the patch is that it's conceivable it fixes *this* case but breaks *another* case. The executive summary of the patch is that it makes the vesa driver not load if /dev/fb* or /dev/dri/card* exist. The idea is that if anything matching those globs exists, it means another driver is being or will be used, and folks reviewing the PR (Javier and Ajax) think that's the case; but with any patch of this general type, it's *possible* there's a case they haven't considered, where a file matching one of those glob exists but we *do* want to use the vesa driver. It's a risk that's difficult to quantify. So, it might be a good idea to test out the ISO I linked on all our other test systems and make sure it doesn't break on any of those. I'll try it on mine later today.
Adam, that's a good point. I tested the ISO from comment 21 on my Thinkpad T480s with Intel GPU, and everything works as expected. Which means all 4 cases of normal boot and basic graphics mode on both BIOS and UEFI. In all cases, the system boots into graphical Anaconda without issues.
(In reply to Adam Williamson from comment #27) > One thing that worries me slightly about the patch is that it's conceivable > it fixes *this* case but breaks *another* case. The executive summary of the > patch is that it makes the vesa driver not load if /dev/fb* or > /dev/dri/card* exist. The idea is that if anything matching those globs > exists, it means another driver is being or will be used, and folks > reviewing the PR (Javier and Ajax) think that's the case; but with any patch > of this general type, it's *possible* there's a case they haven't > considered, where a file matching one of those glob exists but we *do* want > to use the vesa driver. It's a risk that's difficult to quantify. > > So, it might be a good idea to test out the ISO I linked on all our other > test systems and make sure it doesn't break on any of those. I'll try it on > mine later today. The patch I used in koji build in comment #11, was with my first version of the patch (ie checking for /sys/devices/platform/simple-framebuffer.0) From Javier and Ajax, it should be safer to check for /dev/fb* and /dev/dri/card* instead. I'm doing a new scratch build with the "/dev/fb* and /dev/dri/card*" check here: https://koji.fedoraproject.org/koji/taskinfo?taskID=85926541 I tried to do a more official build with "fedpkg push" and "fedpkg build" but that doesn't work on my setup, (it's my first contribution). I'm re-reading the doc to check what I'm doing wrong.
I was able to do a PR instead: https://src.fedoraproject.org/rpms/xorg-x11-drv-vesa/pull-request/1
+6 FE in https://pagure.io/fedora-qa/blocker-review/issue/749 , marking accepted. Blocker vote is pending. Jocelyn, I think you're not actually marked as a maintainer of the package; that's why you can't commit to it. Ajax could add you as one if you are already qualified as a Fedora packager, I think.
Discussed during the 2022-04-19 blocker review meeting: [0] The decision to classify this bug as an "AcceptedBlocker (Final)" was made as it violates the following criterion: "The generic video driver option...must function as intended...there must be no bugs that clearly prevent the installer or desktop from being reached in this configuration on...wide classes of hardware", affecting all cases where the UEFI simpledrm driver may kick in. [0] https://meetbot.fedoraproject.org/fedora-blocker-review/2022-04-19/f36-blocker-review.2022-04-19-16.09.txt
FEDORA-2022-363d88d863 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-363d88d863
(In reply to Fedora Update System from comment #33) > FEDORA-2022-363d88d863 has been submitted as an update to Fedora 36. > https://bodhi.fedoraproject.org/updates/FEDORA-2022-363d88d863 I created another custom netinst including the update above, it is here: https://fedorapeople.org/groups/qa/rhbz2074789_c33.iso Stefan, Lukas, can you please test it? Again, I tested it using standard and basic graphics mode on both BIOS and UEFI, works fine on my Thinkpad T480s with Intel graphics.
FEDORA-2022-363d88d863 has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-363d88d863` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-363d88d863 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Kamil Páral from comment #34) > (In reply to Fedora Update System from comment #33) > > FEDORA-2022-363d88d863 has been submitted as an update to Fedora 36. > > https://bodhi.fedoraproject.org/updates/FEDORA-2022-363d88d863 > > I created another custom netinst including the update above, it is here: > https://fedorapeople.org/groups/qa/rhbz2074789_c33.iso > > Stefan, Lukas, can you please test it? > > Again, I tested it using standard and basic graphics mode on both BIOS and > UEFI, works fine on my Thinkpad T480s with Intel graphics. same problem as with the https://fedorapeople.org/groups/qa/2074789.iso in basic graphics mode it works without problem in standard boot mode does not work, also can not go with f2 or so to the root login.
Thanks, Stefan. Note this update is not intended to fix 'standard' mode if it was not working before - it is intended to fix only the 'basic' mode. If it does that, it's working as intended. Please file another bug for 'standard' mode not working (if you have not done so already), probably against xorg-x11-drv-nouveau if your video adapter is an NVIDIA one. Thanks for testing!
here the link for the bug in standard mode https://bugzilla.redhat.com/show_bug.cgi?id=2077359
I have tested the build mentioned in comment #34 and on my computer with VGA compatible controller: NVIDIA Corporation GM204GL [Quadro M4000] (rev a1) that Anaconda starts correctly in both BIOS and UEFI basic graphics mode.
Two people confirmed that the fix has been working, I believe we can verify this bug.
FEDORA-2022-363d88d863 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.