Gnome 42 - Wayland - hangs at initial ramdisk - starts without NetworkManager

No, this is the default configuration. I am guessing all Garuda users get this setup. I have to assume it's not terribly problematic to have unnecessary modules in there.

This explains that adding the crc32c-intel module doesn't work--however my system gets this:

sudo dmesg | grep crc32c
[sudo] password for jeremy:
[    1.547821] Btrfs loaded, crc32c=crc32c-intel, zoned=yes, fsverity=yes

So either it is working, or perhaps crc32c-intel is compiled into the kernel. Since I don't know which, it seems an unnecessary risk to remove it. I do take your meaning on the other modules though--they obviously bring no benefit (no hidden graphics cards :laughing:).

Well...which came first, the chicken or the egg? :wink:

This caused a curious change; instead of getting stuck on initial ramdisk, I got kicked to tty1 (without doing anything). I logged in and entered sudo systemctl restart gdm.service, but it failed with "Unit gdm.service has a bad unit file setting." :flushed:

sudo systemctl status gdm.service says "Warning: The unit file, source configuration file or drop-ins of gdm.service changed on disk. Run 'systemctl daemon-reload' to reload units."

After reloading the daemon, it still doesn't work but the status error message adds a line at the bottom that specifies: "gdm.service: Service has more than one ExecStart= setting, which is only allowed for Type=oneshot services. Refusing."

I was able to get out of it with

sudo systemctl revert gdm
sudo systemctl restart gdm.service

These drop-in files are delicate, huh?

1 Like

That was a mistake from speed :laughing:

ExecStartPre=/usr/bin/sleep 3

It would help you reading man systemd.service and man systemd.unit @BluishHumility :wink:

What's the worst that could happen? :laughing:

Ya, sorry I mostly write oneshot services, so I didn't take that into account. What you need to do then is wrap it all into one command.


ExecStart=/usr/bin/bash -c "/usr/binsleep 3; /usr/bin/gdm"

Sorry I'm only on my phone and this is just off the top of my head without checking any references.


Corrected my code as I just noticed my phones spell checker added an unwanted white space after the dash "-". Bloody spell checker drives me nuts.

Bingo! This line fixes the login. Plymouth loads normally, briefly reverts back to initial ramdisk and then resolves to the GDM login screen without intervention.

The "Pre" in ExecStartPre appears to be a crucial note, and the ExecStart=/usr/bin/gdm line seems to be unneeded--perhaps because it is already associated with gdm through the gdm.service directory path?

I think you were right on with this assessment tbg, nice one.

I agree, "smart" keyboards can be a source of grief when trying to do simple things with Termux as well! :unamused:

Noted sir, will do.

I guess that pretty much wraps it up. I realize now this is a bit of an edge case--most folks will not experience this issue to any degree--but I've learned a lot through this whole process and I really appreciate you guys hashing it out with me.


Corect. Only one line with ExecStartPre (with the section)

I don't see it that way. It is just a matter of time...
When a similar report is posted, you know what to ask! :stuck_out_tongue_winking_eye:
Once more, @tbg 's experience with services and modules gave success!!

Anyway, when you find time (after warrior's rest), you might want to test if there is any difference without any module in mkinitcpio.conf.


I removed all the modules, regenerated, and rebooted and was planning to add modules back one by one to find the most minimal possible configuration--but it booted find, with no modules. :thinking:

Also, the output of sudo dmesg | grep crc32c is still:

Btrfs loaded, crc32c=crc32c-intel, zoned=yes, fsverity=yes

I suppose this particular setup does not require any modules. :man_shrugging:

I've marked this as the solution:

For those keeping score at home, the final working configuration was to run sudo systemctl edit gdm and add

ExecStartPre=/usr/bin/sleep 3

Thanks again guys. Time to see what else is broken in here... :cracks knuckles:


Nice work with all your troubleshooting @BluishHumility to finally find the cause. I think @petsam is correct it will only be a matter of time till others are affected by this issue, so it is a good thing you identified the cause. If you hadn't spent so much time troubleshooting I would never have twigged to what was happening.

If all users did such a thorough job of troubleshooting and reporting the results finding solutions to most issues on the forum would be a breeze.

Nice work. :+1:


This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.