Hi folks!
So there's a current Beta blocker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1683197
it is currently accepted as a blocker on the understanding that trying to boot to Workstation in 'basic graphics mode' (i.e. with 'nomodeset' on the cmdline) *always* fails, on all hardware (or at least on most hardware). However, we don't yet have enough testing to be sure of this.
It'd be very helpful if folks with a test box can boot a Fedora 30 Workstation live image on it, using the 'Start Fedora-Workstation-Live 30 in basic graphics mode' option from the 'Troubleshooting' menu, and see if it successfully reaches the desktop. Here's an image you can use:
https://kojipkgs.fedoraproject.org/compose/branched/Fedora-30-20190301.n.0/c...
(For bonus points, you can also try this with the F29 final live image, and see if it works with *that* :>)
Please report your findings as a reply to this email, thanks a lot!
On Wed, Mar 6, 2019 at 1:46 PM Adam Williamson adamwill@fedoraproject.org wrote:
Hi folks!
So there's a current Beta blocker bug:
Is this related to this bug from Fedora 29? https://bugzilla.redhat.com/show_bug.cgi?id=1628495
Because I haven't had working nomodeset since Fedora 29. On my laptop that bug was never resolved.
On Wed, Mar 6, 2019 at 9:46 PM Adam Williamson adamwill@fedoraproject.org wrote:
Please report your findings as a reply to this email, thanks a lot!
Hi Adam, I just tested 5 laptops from 3 manufacturers, models from 2011 (I think) to 2018, with either some kind of Intel graphics or Intel + nVidia. Fedora 29 fully updated, the F29 1.2 Workstation live image and the one you gave for F30, all hang when nomodeset is selected, right after the message that GNOME Display Manager has started.
On Wed, 2019-03-06 at 12:46 -0800, Adam Williamson wrote:
Hi folks!
So there's a current Beta blocker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1683197
it is currently accepted as a blocker on the understanding that trying to boot to Workstation in 'basic graphics mode' (i.e. with 'nomodeset' on the cmdline) *always* fails, on all hardware (or at least on most hardware). However, we don't yet have enough testing to be sure of this.
I looked into this today, and while it's a truly gross issue at root, I think I've got a reasonable solution (see patch in comment #11).
The issue seems to be:
a) gdm is expecting a 'master-of-seat' property for the graphics device attached to a given seat before it will deign to touch the seat
b) systemd is now setting that property only for a subset of devices - specifically, drm devices but not fbdev devices.
c) you don't want to set master-of-seat unconditionally for fbdev devices, because it introduces a race: efifb will have bound to the device first, and drm driver load is asynchronous, so there's no guarantee i915 (or whatever) will have loaded by the time gdm starts, and if gdm wins the race the session at best comes up unaccelerated and RANDRless with fbdev and llvmpipe, and at worst crashes when the framebuffer handoff to i915 triggers.
So. The workaround is to add a udev rule:
# allow efifb / uvesafb to be a master if KMS is disabled SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", PROGRAM="/usr/bin/grep -qw nomodeset /proc/cmdline", TAG+="master-of-seat"
This says, if you asked for nomodeset, whatever fbdev device is present is good enough to be a seat master. This doesn't handle all possible cases. It doesn't catch the case of a user saying (for example) i915.modeset=0, which would also disable modesetting, but that's never what our tools write to our grub configs. It wouldn't catch the case of using vgafb or vesafb (or any other fbdev driver) _without_ explicitly saying nomodeset; but we ship very few such drivers, and our tools will not give you any of the generic ones like vga or vesa by default.
So I think this handles 90%+ of the cases we care about, certainly enough to unblock the release. If anyone wants to polish it further, feel free. Let me know if there's any additional insight I can provide.
- ajax
On Tue, 2019-03-12 at 14:11 -0400, Adam Jackson wrote:
On Wed, 2019-03-06 at 12:46 -0800, Adam Williamson wrote:
Hi folks!
So there's a current Beta blocker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1683197
it is currently accepted as a blocker on the understanding that trying to boot to Workstation in 'basic graphics mode' (i.e. with 'nomodeset' on the cmdline) *always* fails, on all hardware (or at least on most hardware). However, we don't yet have enough testing to be sure of this.
I looked into this today, and while it's a truly gross issue at root, I think I've got a reasonable solution (see patch in comment #11).
The issue seems to be:
a) gdm is expecting a 'master-of-seat' property for the graphics device attached to a given seat before it will deign to touch the seat
b) systemd is now setting that property only for a subset of devices - specifically, drm devices but not fbdev devices.
c) you don't want to set master-of-seat unconditionally for fbdev devices, because it introduces a race: efifb will have bound to the device first, and drm driver load is asynchronous, so there's no guarantee i915 (or whatever) will have loaded by the time gdm starts, and if gdm wins the race the session at best comes up unaccelerated and RANDRless with fbdev and llvmpipe, and at worst crashes when the framebuffer handoff to i915 triggers.
So. The workaround is to add a udev rule:
# allow efifb / uvesafb to be a master if KMS is disabled SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", PROGRAM="/usr/bin/grep -qw nomodeset /proc/cmdline", TAG+="master-of-seat"
This says, if you asked for nomodeset, whatever fbdev device is present is good enough to be a seat master. This doesn't handle all possible cases. It doesn't catch the case of a user saying (for example) i915.modeset=0, which would also disable modesetting, but that's never what our tools write to our grub configs. It wouldn't catch the case of using vgafb or vesafb (or any other fbdev driver) _without_ explicitly saying nomodeset; but we ship very few such drivers, and our tools will not give you any of the generic ones like vga or vesa by default.
So I think this handles 90%+ of the cases we care about, certainly enough to unblock the release. If anyone wants to polish it further, feel free. Let me know if there's any additional insight I can provide.
Wow, that sounds icky. Thanks a lot for the investigation!
I agree that your workaround should be sufficient to at least fix the release-blocking case we care about (our 'nomodeset'-based "basic graphics mode" feature). It would be nice if this could be made to work for other cases where we wind up with a non-modesetting driver, as you point out, but I agree we don't need to block releases on that.
Great. Thank you very much.
On Tue, Mar 12, 2019 at 8:05 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Tue, 2019-03-12 at 14:11 -0400, Adam Jackson wrote:
On Wed, 2019-03-06 at 12:46 -0800, Adam Williamson wrote:
Hi folks!
So there's a current Beta blocker bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1683197
it is currently accepted as a blocker on the understanding that trying to boot to Workstation in 'basic graphics mode' (i.e. with 'nomodeset' on the cmdline) *always* fails, on all hardware (or at least on most hardware). However, we don't yet have enough testing to be sure of this.
I looked into this today, and while it's a truly gross issue at root, I think I've got a reasonable solution (see patch in comment #11).
The issue seems to be:
a) gdm is expecting a 'master-of-seat' property for the graphics device attached to a given seat before it will deign to touch the seat
b) systemd is now setting that property only for a subset of devices - specifically, drm devices but not fbdev devices.
c) you don't want to set master-of-seat unconditionally for fbdev devices, because it introduces a race: efifb will have bound to the device first, and drm driver load is asynchronous, so there's no guarantee i915 (or whatever) will have loaded by the time gdm starts, and if gdm wins the race the session at best comes up unaccelerated and RANDRless with fbdev and llvmpipe, and at worst crashes when the framebuffer handoff to i915 triggers.
So. The workaround is to add a udev rule:
# allow efifb / uvesafb to be a master if KMS is disabled SUBSYSTEM=="graphics", KERNEL=="fb[0-9]", PROGRAM="/usr/bin/grep -qw
nomodeset /proc/cmdline", TAG+="master-of-seat"
This says, if you asked for nomodeset, whatever fbdev device is present is good enough to be a seat master. This doesn't handle all possible cases. It doesn't catch the case of a user saying (for example) i915.modeset=0, which would also disable modesetting, but that's never what our tools write to our grub configs. It wouldn't catch the case of using vgafb or vesafb (or any other fbdev driver) _without_ explicitly saying nomodeset; but we ship very few such drivers, and our tools will not give you any of the generic ones like vga or vesa by default.
So I think this handles 90%+ of the cases we care about, certainly enough to unblock the release. If anyone wants to polish it further, feel free. Let me know if there's any additional insight I can provide.
Wow, that sounds icky. Thanks a lot for the investigation!
I agree that your workaround should be sufficient to at least fix the release-blocking case we care about (our 'nomodeset'-based "basic graphics mode" feature). It would be nice if this could be made to work for other cases where we wind up with a non-modesetting driver, as you point out, but I agree we don't need to block releases on that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ desktop mailing list -- desktop@lists.fedoraproject.org To unsubscribe send an email to desktop-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/desktop@lists.fedoraproject.or...
desktop@lists.fedoraproject.org
-
Adam Jackson -
Adam Williamson -
Alexander Ploumistos -
Chris Murphy -
Lukas Ruzicka