2:46 p.m.
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
3:47 p.m.
On Wed, Mar 6, 2019 at 1:46 PM Adam Williamson
<adamwill(a)fedoraproject.org> 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
4:46 p.m.
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
5:50 p.m.
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....
(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)
8:35 p.m.
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....
(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 busIDs for all
framebuffer devices
1:46 p.m.
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
9:29 p.m.
Testing kerneltest.iso
Fails to boot without acpi=off
Problem is Realtek r8169 module; same bug as bugzilla 1674268
1:11 p.m.
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
1:22 p.m.
Sounds more than reasonable.
Adam Jackson <ajax(a)redhat.com> 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(a)lists.fedoraproject.org
To unsubscribe send an email to test-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/test@lists.fedoraproject.org
2:04 p.m.
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
11:23 a.m.
Great. Thank you very much.
On Tue, Mar 12, 2019 at 8:05 PM Adam Williamson <adamwill(a)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(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/desktop@lists.fedoraproject...
--
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>
1894
days inactive
1901
days old
10 comments
9 participants
participants (9)
-
Adam Jackson -
Adam Williamson -
Brandon Nielsen -
Chris Murphy -
Garry T. Williams -
Julen Landa Alustiza -
Lukas Ruzicka -
pmkellly＠frontier.com -
Steven Usdansky