Hello @privacyfreak84 ,
I have just updated to that kernel and the boot seems to be going like normal then hangs. I can’t get a tty to use for login, or even to see the text of the bootup instead of the splash screen. I’m using systemd-boot, not grub2, and the upgrade creates the .conf file for the commit changes so I set that as default like normal and no boot to graphical target. I am currently on the previous kernel to diagnose this further.
Edit: As this was a result of the kernel command line argument being misconfigured due to an earlier setup to suspend-resume, I added tags for suspend-resume
During boot, hold down the Shift or Esc key while the system boots. This should display kernel boot messages, which might reveal where the hang occurs and provide clues about the issue.
Also try to view kernel logs :
dmesg | grep -i failed
or
journalctl -b -1 | grep -i failed
To check the boot logs :
journalctl -b -1
i would test with you all, but I am runing a job that’s going to take an hour to finish.
I am not on 6.8.10, and was not aware of the update so both of you are first. As more people update they could also potentially encounter this problem. Which would mean more threads here or on other forums.
I’ll do that and see what comes up. It definitely does not complete boot to the point where journalctl can give anything, it just reports the previous boot as being the last one with kernel 6.8.9. Which is frustrating to say the least.
Edit: Did as requested and watched the boot up. It gets to the initrd.target complete then waits indefinitely at the device. I’m thinking the boot image is corrupt in some way. I’m going to delete the update boot and clear it from the boot list, then redo the upgrade.
Edit Again: The boot actually makes it to the virtual console starting, then hangs on “dev-disk-by/2xUUID//blah.device/Start”. Seems like an odd UUID to me.
I have same experience with new 6.8.10 kernel. I boot older kernel and reinstall kernel packages like: ‘sudo dnf reinstall kernel*’ and after that boot 6.8.10 normal no problems
I am thinking it is a UUID mismatch, I can’t find corresponding UUID’s for my subvolumes. And at every “/” “X2d” follows, it looks like it’s malformed.
Yeah that is what I get basically. I have waited over an hour yesterday and it still never comes back. I am currently using the 6.8.9 kernel as even reinstalling the 6.8.10 one didn’t fix the issue for me.
It is important to collect data from systems that fail to boot with 6.8.10. Looks like the issue occurs before journalctl starts. Maybe /var/log/boot.log-YYYYMMDD files have some details journalctl doesn’t capture.
Looking at /var/log/boot.log-<date> for a boot of 6.8.9 there are \x2d’s for dashes:
[ OK ] Finished systemd-fsck@dev-disk-by\x2duuid-b831937b\x2d259e\x2d46b4\x2da9cd\x2dc4fb22c1c072.service - File System Check on /dev/disk/by-uuid/b831937b-259e-46b4-a9cd-c4fb22c1c072.
I did this for the boot date in question (yesterday) and I find it is a missing swap.target that times out in 45 seconds (the limit set) when booting kernel 6.8.9, which when booting kernel 6.8.10 has an infinite limit set for the same operation at boot. On the 6.8.9 kernel it times out on my system then continues through the boot process, while with the 6.8.10 version kernel in use, it will wait indefinitely.
Edit: At one time I had a physical swap partition, I wonder if this is related in some way. Like the .target was created when the swap partition existed and didn’t change after the partition was removed from use. I definitely think this is the case. Which begs the question, when you change using swapctl does it not take care of the systemd units that the swap partition is linked to? In my case I switched off the swap partition after I increased memory size to 32Gb, since I felt swap for my use cases could be adequately handled by a zram swapfile.
I also removed my swap partition months ago, but I was bothered by the long boot times, so I cleaned up the boot operation (I forget how exactly, but I think it involved mucking with systemd config), and the computer boots up pretty fast (~5s) since then. I don’t think this bug is related to that? Unless having/having had swap somehow triggers this bug.
IDK, but my system hangs waiting on my old swap partition, that technically still exists (uuid does NOT) but has been absorbed into the BTRFS volume, and is no longer an actual swap partition.
Edit: the UUID of my swap partition does not exist anymore.
Here is a log from a boot yesterday morning with the 6.8.9 kernel. I have included just the particular error that caused delay of 45 sec on my system at boot …
[ *** ] Job dev-disk-by\x2duuid-4c9bbdab\x2d9aaa\x2d461f\x2da0c6\x2d3d583e2caf5d.device/start running (45s / 45s)
270 │ [ TIME ] Timed out waiting for device dev-disk-by\x2duuid-4c9bbdab\x2d9aaa\x2d461f\x2da0c6\x2d3d583e2caf5d.device - /dev/di
│ sk/by-uuid/4c9bbdab-9aaa-461f-a0c6-3d583e2caf5d.
271 │ [DEPEND] Dependency failed for dev-disk-by\x2duuid-4c9bbdab\x2d9aaa\x2d461f\x2da0c6\x2d3d583e2caf5d.swap - /dev/disk/by-uui
│ d/4c9bbdab-9aaa-461f-a0c6-3d583e2caf5d.
272 │ [DEPEND] Dependency failed for swap.target - Swaps.
When I try to boot the 6.8.10 kernel, that job to find a device that doesn’t exist anymore, has it maximum set to infinite instead of 45 seconds. So I wait forever for my new kernel.
Would running dracut after ensuring the swap device has been removed and the entry in /etc/fstab been removed solve this attempt to load a swap device that no longer exists?
I have never (in recent history since ZRAM swap was introduced) used a physical swap file or partition so have not seen these errors, but it would seem that potentially something in the initramfs image may be triggering that issue.
!