Re: F30 Testing request: "basic graphics mode" in Workstation

[Lukas Ruzicka]

Great. Thank you very much.

On Tue, Mar 12, 2019 at 8:05 PM Adam Williamson 
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 -- desk...@lists.fedoraproject.org
> To unsubscribe send an email to desktop-le...@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/desk...@lists.fedoraproject.org
>


-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat



Purkyňova 115

612 45 Brno - Královo Pole

lruzi...@redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. 
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[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
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[Julen Landa Alustiza]

Sounds more than reasonable.

Adam Jackson  igorleak hau idatzi zuen (2019 mar. 12, ar.
19:11):

> 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
> ___
> test mailing list -- test@lists.fedoraproject.org
> To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org
>
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[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
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[Steven Usdansky]

Testing kerneltest.iso
Fails to boot without acpi=off
Problem is Realtek r8169 module; same bug as bugzilla 1674268
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[Chris Murphy]

Following up on this by filing a Pagure issue for the WG to discuss
whether a change (remove or clarify) in release criterion and test
case is warranted. Any clarity the WG can provide whether the actual
behavior squares with intended behavior is appreciated.

https://pagure.io/fedora-workstation/issue/89


--
Chris Murphy
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[Brandon Nielsen]

On 3/6/19 2:46 PM, 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.

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/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190301.n.0.iso

(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!



Using Fedora-Workstation-Live-x86_64-30-20190301.n.0.iso:

Compaq 8510w, BIOS, Intel Core 2 Duo T900, AMD RV630 - Fails, never 
makes it to the desktop. Hangs with no prompt.
Desktop, UEFI, Z87 chipset, Intel Xeon E3-1230 v3, AMD R9 280X GPU - 
Fails, never makes it to the desktop. Hangs with no prompt.



Using Fedora-Workstation-Live-x86_64-29-1.2.iso:

Compaq 8510w, BIOS, Intel Core 2 Duo T900, AMD RV630 - Fails, never 
makes it to the desktop. Hangs with no prompt.
Desktop, UEFI, Z87 chipset, Intel Xeon E3-1230 v3, AMD R9 280X GPU - 
Fails, never makes it to the desktop. Gives a login prompt. Possibly 
relevant section from the journal (I can share the whole thing somewhere 
if someone is interested):


Mar 06 21:13:31 localhost-live /usr/libexec/gdm-x-session[1821]: Fatal 
server error:
Mar 06 21:13:31 localhost-live /usr/libexec/gdm-x-session[1821]: (EE) 
Cannot run in framebuffer mode. Please specify busIDsfor all 
framebuffer devices

___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[pmkel...@frontier.com]

On 3/6/19 3:46 PM, 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.

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/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190301.n.0.iso

(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!



I tested as you requested on my Lenovo M58p with E8400 processor.

For F30 the start up hung after "OK   Started GNOME Display Manager". No 
further.


For F29 the start up hung after "OK   Started GNOME Display Manager" 
followed "Starting Network Manager Script Dispatcher Service...? No further.


For F28 the system booted to the desktop.


Have a Great Day!

Pat (tablepc)
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[Garry T. Williams]

On Wednesday, March 6, 2019 3:46:22 PM EST Adam Williamson wrote:
> 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/compose/Workstation/x86_64/iso/Fedora-
Workstation-Live-x86_64-30-20190301.n.0.iso

Dell XPS-13 laptop i7-8550U: No joy -- hangs without desktop.

-- 
Garry T. Williams


___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

Re: F30 Testing request: "basic graphics mode" in Workstation

[Chris Murphy]

On Wed, Mar 6, 2019 at 1:46 PM Adam Williamson
 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
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org

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.0/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-30-20190301.n.0.iso

(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
___
test mailing list -- test@lists.fedoraproject.org
To unsubscribe send an email to test-le...@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/test@lists.fedoraproject.org