Another issue I’m seeing with the upgrade to unstable (latest as of yesterday): I’m getting phantom power button presses immediately on boot:
Feb 24 22:42:41 thinkpadt14sg6 systemd[1]: Starting User Login Management...
Feb 24 22:42:41 thinkpadt14sg6 systemd-logind[1037]: New seat seat0.
Feb 24 22:42:41 thinkpadt14sg6 systemd-logind[1037]: Watching system buttons on /dev/input/event0 (gpio-keys)
Feb 24 22:42:41 thinkpadt14sg6 systemd-logind[1037]: Watching system buttons on /dev/input/event2 (hid-over-i2c 04F3:000D Keyboard)
Feb 24 22:42:41 thinkpadt14sg6 systemd-logind[1037]: Watching system buttons on /dev/input/event1 (pmic_pwrkey)
Feb 24 22:42:41 thinkpadt14sg6 systemd[1]: Started User Login Management.
Feb 24 22:43:21 thinkpadt14sg6 systemd-logind[1037]: Power key pressed short.
Feb 24 22:43:21 thinkpadt14sg6 systemd-logind[1037]: Powering off...
Feb 24 22:43:21 thinkpadt14sg6 systemd-logind[1037]: System is powering down.
Feb 24 22:43:21 thinkpadt14sg6 systemd[1]: Stopping User Login Management...
Feb 24 22:43:21 thinkpadt14sg6 systemd[1]: systemd-logind.service: Deactivated successfully.
Feb 24 22:43:21 thinkpadt14sg6 systemd[1]: Stopped User Login Management.
which means it immediately shuts down, or if I boot a configuration with gdm enabled it seems to suspend or at least power down the screen. In that latter case if I press the power button the screen flashes up briefly (showing the gdm login screen) and then goes black again (presumably it’s immediately suspending), and that happens repeatedly every second time I press the button. I can see the effect of my key presses on the screen when it flashes up, so the system is still responsive to some extent.
If I boot back into my 24.11 generation I don’t see this problem at all, and nothing about power button presses appears in the logs, although I do notice the button blinks as the system finishes starting up.
Just throwing it out there in case anyone else has seen this. I couldn’t find an obvious bug report anywhere. I will try the various systemd-logind config options to ignore power button presses tomorrow to see if that helps.
I too have not read about this issue. I’m running sway on -rc kernels and gnome on linuxPackages_latest. I do have services.logind.lidSwitch = "ignore";.
Finally getting back to this, thanks for sharing the config. I think I reproduced your config pretty much exactly (including the kernel), but I’m still having issues on unstable. I’ll look into it further.
Out of interest, could you share which commit of nixpkgs you’re using? I’m using ba487dbc9d04e0634c64e3b1f0d25839a0a68246 FWIW.
EDIT: To clarify ‘issues’, it boots, I see various boot status messages fly past, and then end up with a blank unresponsive screen (regardless of whether I have a window system enabled). I don’t see anything obvious in journalctl (the power key thing I saw before was a red herring I think, I was confused by the system time being wrong!). Pressing the power key shuts it down successfully, but the usual things (e.g. ctrl-alt-f* to switch ttys) don’t work.
Update: it turns out everything is responsive, it’s just the screen is blank. I can log in with the root password and type reboot and it’ll reboot. So I’m guessing it’s a problem with GPU initialization. Booting with nomodeset doesn’t seem to help.
Mine goes blank for about 10 seconds before tty login/password appear. This is with sway, which I start at the command line (and is installed with home-manager).
Thanks very much @ookhoi . Using the same commit made no difference. Here’s the difference in the logs (my broken one is left (<), yours is right (>)):
I don’t see much of a difference apart from the iommu group being different. I will play with some of the other settings you sent later on. Thanks so much!
Yes I had the same thought about brightness, but I didn’t think about the OLED vs LCD wrinkle. Mine is OLED, so that definitely sounds like a lead (just pressing the brightness controls doesn’t do anything, of course). There are a bunch of references to OLED brightness being broken in the kernel/dtbs at various points, but I’m now using the same kernel in both the working and the broken case.
Since it happens later in boot, it feels like it’s something that systemd is starting that’s causing the issue. I’ve tried disabling a few obvious services to no avail. Unfortunately systemd.confirm_spawn=true seems to crash the system, because otherwise that would be really useful to debug.
Anyhow, I’ll keep hacking away at it, thanks for the help!
I narrowed it down a bit further: the screen appears to go blank after systemd-udevd starts (if I add a delay to the start of that unit, the screen remains active until after the delay expires). I’ve taken a look at the difference between the udev rules on the two systems and they look pretty similar, and doing udevadm info --attribute-walk --path=/sys/class/drm/card1 looks similar (not exactly the same, the newer systemd seems to have more information). I’ll keep looking!