F30 Testing request: "basic graphics mode" in Workstation

[Adam Williamson]

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

(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!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Chris Murphy]

On Wed, Mar 6, 2019 at 1:46 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  Hi folks!
>
>  So there's a current Beta blocker bug:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1683197 
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.


-- 
Chris Murphy

[Alexander Ploumistos]

On Wed, Mar 6, 2019 at 9:46 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; 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.

[Adam Jackson]

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

[Adam Williamson]

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

[Lukas Ruzicka]

Great. Thank you very much.

On Tue, Mar 12, 2019 at 8:05 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
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(a)lists.fedoraproject.org
>  To unsubscribe send an email to desktop-leave(a)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/[e-mail]...
>  

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

<https://www.redhat.com>

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>