Created attachment 1700528 [details] photo of About You page in gnome-initial-setup Description of problem: Upon installation of Fedora-Workstation-Rawhide-20200706-btrfs.raw.xz to a RasPi3B+, the gnome-initial-setup doesn't allow text entry at the "About You" page, rendering the system "stuck" here. Version-Release number of selected component (if applicable): Fedora-Workstation-Rawhide-20200706-btrfs.raw.xz How reproducible: Always Steps to Reproduce: 1. Install Fedora-Workstation-Rawhide-20200706-btrfs.raw.xz 2. Boot, wait for gnome-initial-setup to start 3. Attempt to fill in the Full Name and Username fields on the About You page Actual results: Text entry not allowed Expected results: Text should be allowed and user should be created Additional info: See attached photo for exact spot that bug occurs
I tried to repro this now, and I was able to complete the initial setup successfully. It is quite slow though, and I had to wait several minutes at the "About You" before I could get it to accept text. After setup ended, I saw a screenful of bcm2835-dma messages in the format of: bcm2835-dma 3f007000.dma vchan 00000000ecd4b140: txd ... submitted (sorry, didn't manage to copy it off in time) and then it went back to gdm. I suspect there's something interacting poorly with the RPi internals here, but it doesn't seem to be brtfs related so far. I'll see if I can get this to boot with the serial console attached so I can gather more data.
Created attachment 1700710 [details] journal log Ok, this happens reliably after attempting to login to gdm -- it never gets to a desktop, just prints a screenful of stuff like bcm2835-dma 3f007000.dma: vchan 00000000cff7511b: txd 0000000071174e34[b980]: submitted and goes back to the login prompt in gdm. I've pulled the journal logs off the sdcard and attached them here.
I'm doing this in qemu. I see no btrfs failures here. But there are some curiousities: [ 268.395107] localhost.localdomain systemd[1]: Starting Repartition Root Disk... [ 273.938548] localhost.localdomain systemd[1]: Finished Repartition Root Disk. [ 280.000020] localhost.localdomain systemd-repart[704]: Didn't find any partition definition files, nothing to do. ... [ 328.172782] localhost.localdomain lvm[698]: WARNING: Device /dev/vda3 not initialized in udev database even after waiting 10000000 microseconds. ... [ 436.304800] localhost.localdomain kernel: Rounding down aligned max_sectors from 4294967295 to 4294967288 ... [ 512.435339] localhost.localdomain rngd[919]: [rtlsdr]: Initialization Failed ... [ 558.025596] localhost.localdomain systemd[1]: sssd.service: Failed with result 'timeout'. [ 558.303636] localhost.localdomain systemd[1]: Failed to start System Security Services Daemon. ... [ 560.933513] localhost.localdomain systemd[1]: NetworkManager-wait-online.service: Main process exited, code=exited, status=1/FAILURE ... [ 688.720063] localhost.localdomain gnome-shell[1296]: Failed to create backend: No drm devices found I'll try virtio graphics next. Also the following AVCs but it's well after the other failures. [ 916.124448] localhost.localdomain audit[1322]: AVC avc: denied { getattr } for pid=1322 comm="login" name="/" dev="proc" ino=1 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0 [ 922.730964] localhost.localdomain audit[1323]: AVC avc: denied { getattr } for pid=1323 comm="login" name="/" dev="proc" ino=1 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0 [ 932.293166] localhost.localdomain audit[1324]: AVC avc: denied { getattr } for pid=1324 comm="login" name="/" dev="proc" ino=1 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0
Neither VGA nor virtio graphics works for me. And in Davide's case Jul 11 18:25:57 localhost.localdomain systemd[1677]: gnome-shell-wayland.service: State 'stop-sigterm' timed out. Killing. Jul 11 18:25:57 localhost.localdomain systemd[1677]: gnome-shell-wayland.service: Killing process 1861 (gnome-shell) with signal SIGKILL. Jul 11 18:26:28 localhost.localdomain kernel: bcm2835-dma 3f007000.dma: vchan 00000000cff7511b: txd 0000000071765f3b[7daf]: submitted Jul 11 18:26:28 localhost.localdomain kernel: bcm2835-dma 3f007000.dma: vchan 00000000cff7511b: txd 000000002bd0d863[7db0]: submitted Jul 11 18:25:57 localhost.localdomain systemd[1677]: gnome-shell-wayland.service: Killing process 1902 (Xwayland) with signal SIGKILL. Jul 11 18:25:57 localhost.localdomain systemd[1677]: gnome-shell-wayland.service: Killing process 1870 (gdbus) with signal SIGKILL. Jul 11 18:25:57 localhost.localdomain systemd[1677]: gnome-shell-wayland.service: Main process exited, code=killed, status=9/KILL Jul 11 18:25:58 localhost.localdomain systemd[1677]: grub-boot-success.service: Succeeded. Jul 11 18:25:58 localhost.localdomain systemd[1677]: Finished Mark boot as successful. Jul 11 18:26:00 localhost.localdomain systemd[1677]: gnome-shell-wayland.service: Failed with result 'timeout'. I'm not sure what that is all about but it's not btrfs related.
> [ 268.395107] localhost.localdomain systemd[1]: Starting Repartition Root Disk... > [ 273.938548] localhost.localdomain systemd[1]: Finished Repartition Root Disk. > [ 280.000020] localhost.localdomain systemd-repart[704]: Didn't find any partition definition files, nothing to do. Is there something we need to do to get systemd-repart to auto-expand a btrfs volume for this? It seems like it didn't attempt that for some reason?
Nothing to do here at the moment. systemd-repart only supports GPT and these images use MBR. #fedora-arm today 07:54:34 @pwhalen | cmurf: there is a shell script used to write images to sd, resize and make slight adjustments to the image. We'll need to extend that for btrfs. So it could be an option to deprecate that shell script and use systemd-repart instead if the images are made with GPT partitioning; or update that shell script to handle Btrfs resizes. The nice thing about systemd-repart is that it can grow ext4,xfs,btrfs. But GPT support might confuse some firmware (not sure).
(In reply to Chris Murphy from comment #6) > Nothing to do here at the moment. systemd-repart only supports GPT and these > images use MBR. > > #fedora-arm today 07:54:34 @pwhalen | cmurf: there is a shell script > used to write images to sd, resize and make slight adjustments to the image. > We'll need to extend that for btrfs. > > So it could be an option to deprecate that shell script and use > systemd-repart instead if the images are made with GPT partitioning; or > update that shell script to handle Btrfs resizes. The nice thing about > systemd-repart is that it can grow ext4,xfs,btrfs. But GPT support might > confuse some firmware (not sure). If it's not too bad, let's just have the shell script handle this properly. The fact that systemd-repart only works with GPT worries me.
> systemd-repart instead if the images are made with GPT partitioning; or Except it would mean that the images wouldn't work on a whole raft of devices we support that only boot from MBR devices. Why would a resize script need to be specific to GPT?
>Except it would mean that the images wouldn't work on a whole raft of devices we support that only boot from MBR devices. Whatever advantages there are of GPT, however unfortunate it is that devices can't handle it - I'm definitely not advocating dropping support for such devices; or otherwise making it harder to support them. If they can't use GPT, then it means systemd-repart isn't helpful here. > Why would a resize script need to be specific to GPT? Systemd-repart's logic depends on partition type GUIDs to unambiguously define the purpose+intent of each partition, and know which ones to modify. A resize script that's predicated on MBR must make assumptions based on partition number and type - that's much more limited. It's possibly risky to use on devices/images created for some other use case.
More concretely, systemd-repart depends on a specification that nobody is using: https://systemd.io/DISCOVERABLE_PARTITIONS/ This specification mandates GPT and describes a set of GUIDs that you'd set as labels for partitions for systemd to be able to use to discover how to auto-configure the system. There are two fundamental flaws in that document: 1) UEFI does not mandate GPT. It *does* require an ESP, but there are both MBR and GPT identifiers for the ESP. 2) This "specification" is impossible to implement on volume managing filesystems, because partition GUIDs can only be applied at the base volume, not the individual subvolumes. This is problematic for any Linux system using Btrfs, ZFS, bcachefs, or any other volume managing filesystem. In any case, we should just extend the existing mechanism used for growing volumes to grow a Btrfs volume. Does anyone know what that is?
Based on what Chris said in #fedora-arm, I went ahead and made a PR to extend fedora-arm-installer: https://pagure.io/arm-image-installer/pull-request/59
(In reply to Neal Gompa from comment #10) > > 2) This "specification" is impossible to implement on volume managing > filesystems, because partition GUIDs can only be applied at the base volume, > not the individual subvolumes. This is problematic for any Linux system > using Btrfs, ZFS, bcachefs, or any other volume managing filesystem. > Heh, I stand corrected: subvolumes can have UUIDs of their own, though I don't see a way to set them...
This bug appears to have been reported against 'rawhide' during the Fedora 33 development cycle. Changing version to 33.
Is the reported gnome-initial-setup "no text entry" problm still happening with a current nightly?
This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Let's log this is a dupe of 2017043 even though the later is a later bug. *** This bug has been marked as a duplicate of bug 2017043 ***