So on my Desktop, without this, with systemd based init (which iirc is about to become the default), ends up starting plymouth before the nVidia Drivers have a chance to kick in - plymouth will start up in about 0.6 seconds, but the nVidia driver won’t finish loading for almost 2 seconds - So what happens is plymouth starts up, grabs the screen, and them almost immediately nVidia loads and I just get a text boot instead because the screen buffer that plymouth grabbed doesn’t exist or at least isn’t primary any more.
This makes plymouth wait for the modules to finish starting, and fixed the issue.
So… Who do I poke on nixpkgs github to get this included in nixpkgs? This could fall under nVidia, or Plymouth, or even Systemd.
(Also if someone relevant sees this, and decides to just add it, that’d be fantastic)
Hrm… I’ve been experiencing inconsistent behavior on this front. Some boots I’d get plymouth and other I wouldn’t. Either with AMD or with some integrated Intel. For possibly months on unstable. Never looked into it. Just accepted it. So, I hope that this can be fixed.
This is really not the kind of solution I’d want to see, for a couple of reasons.
Graphics drivers in initrd are not a good idea if they can be avoided. They’re generally not actually necessary (simple-drm will handle graphics well enough for this stage, and your EFI should be picking a good-looking resolution to start with (which you can fix with systemd-boot’s console mode if it isn’t)) and they bloat the size of your initrd by a lot (taking up a lot of /boot / ESP space).
If plymouth isn’t figuring out what to do later when the GPU driver takes over, that’s a plymouth bug, not a NixOS bug. Delaying the start of plymouth for the GPU driver is just a really wrong solution; plymouth should be handling the transition correctly, not starting later.
It’s because it’s (usually) pointless, and as I said it makes the initrd on your ESP way bigger, wasting space. I imagine it would also be bad for performance, since it’s more data for the kernel to decompress as it unpacks the initrd, and since loading something like amdgpu will probably take time in stage 1 that would be better done in the background of stage 2. But performance isn’t really my primary motivation; it’s just adding something big and messy to stage 1 that doesn’t need to be there.
That’s true, it’s definitely worse; however plymouth doesn’t support changing framebuffers as far as I can tell, and nVidia’s drivers are primarily the only ones doing this - And you basically have to put them initrd to even come close to a “seamless” boot.
Hm, I’m not sure that’s right? If I boot with modprobe.blacklist=amdgpu and plymouth:debug, then I’ll boot without the GPU driver and plymouth will do debug logging. I can boot up, delete /var/log/plymouth-debug.log, and then do systemctl restart plymouth-start.service. What this does is put me into a state where I have interactive control over SSH and plymouth is running with a clean log and for sure with simpledrm as its display backend (I can even tell visually since I can cause it to boot with a worse resolution for the EFI framebuffer, which amdgpu would modeset away). Once I visually confirm it’s running, over SSH I can run modprobe amdgpu to load the GPU driver and see how it handles the change over. After a few seconds, amdgpu takes over the display and does modesetting, and plymouth visibly takes over the amdgpu output with the improved resolution. Here’s what I get in the debug log: plymouth-debug.log · GitHub
When amdgpu takes over, the simpledrm device is removed, which causes plymouth to stop trying to use it for display output. Then the amdgpu DRM outputs come up, and after a moment it finds card1 to use, and plymouth successfully switches to the new video output.
So unless you mean nvidia does something other than bringing down the simpledrm device and bringing up an nvidia DRM device, I’m not sure why nvidia wouldn’t work just fine the same way.
