Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1679801 - udev not tagging efifb fb0 as master-of-seat
Summary: udev not tagging efifb fb0 as master-of-seat
Keywords:
Status: CLOSED DUPLICATE of bug 1683197
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: 29
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: systemd-maint
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARMTracker
TreeView+ depends on / blocked
 
Reported: 2019-02-21 21:56 UTC by Jeremy Linton
Modified: 2019-05-02 20:07 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-05-02 20:07:56 UTC
Type: Bug
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1683197 0 unspecified CLOSED gdm fails to start with "nomodeset" on BIOS installs due to lack of framebuffer / master-of-seat device 2022-05-16 11:32:56 UTC

Description Jeremy Linton 2019-02-21 21:56:06 UTC 
Description of problem: It seems that the window managers (sddm/gdm) are now activly checking the CanGraphical property from logind. This means they fail to start X on seats that don't have this properly. The efifb device exports a perfectly functional graphical framebuffer which tends to get taken over by native linux drivers (amdgpu/etc). If that doesn't happen then X can go ahead and start on the efifb device anway but with fixed resolution/color depth. AKA switching the DM to xdm allows normal login.


Version-Release number of selected component (if applicable): F29, sddm 0.18.0-1, systemd-udev 239-11. kernel-4.20.10-200


How reproducible: 100% with UEFI-Rpi firmware and latest fedora. I suspect its probably reproducable on any UEFI system where a dedicated kernel module doesn't take over the efifb device. AKA modprobe.blacklist=amdgpu or noveau leaves the efifb in place, and it never gets cangraphcial set.


Steps to Reproduce:
1. Grab RPI+upstream EDK2 firmware for rpi, build/install machine with f29
2. check `loginctl show-seat seat0` CanGraphical=XXX
3. Note `loginctrl seat-status seat0` 
 /sys/devices/platform/efi-framebuffer.0/graphics/fb0
                   graphics:fb0 "EFI VGA"

Actual results:
# loginctl show-seat seat0
Id=seat0
ActiveSession=4
CanMultiSession=yes
CanTTY=yes
CanGraphical=no
...

Expected results:
Cangraphical should be set on working fbX devices.
Comment 1 Jeremy Linton 2019-02-21 21:59:23 UTC 
BTW: SDDM & the rpi in this config works in a basic F29 install, its only after doing an upgrade does it start to fail. Not sure if it was SDDM that caused the problem or systemd-udev or something else irritating the problem (its not the kernel, booting the older kernel displays the same problem).
Comment 2 Peter Robinson 2019-02-24 23:11:10 UTC 
udev is now part of systemd
Comment 3 Jeremy Linton 2019-05-02 20:07:56 UTC 
As this problem was reproduced on x86, was causing a lot of problem, I'm going to dupe this against the gdm changes to remove the master-of-seat check.

*** This bug has been marked as a duplicate of bug 1683197 ***
Note You need to log in before you can comment on or make changes to this bug.