Since kernel 6.8.10-300.fc40.x86_64, boot hangs on KDE Plasma (kernel 6.8.9-300.fc40.x86_64 was the last good one). I found that there is a job running infinitely:
'Job dev-disk-by\x2duuid-8e895....running ...' The above mentioned UUID (8e895 ...) corresponds to the kernel 'resume=uuid=...' command line parameter.
When I comment it out in GRUB2, as suggested in
https://discussion.fedoraproject.org/t/solved-boot-hang-job-dev-disk-by-x2uu...
then the system boots as expected.
This is a rather fresh install of fedora 40 (running on ext4):
da 8:0 0 232,9G 0 disk ├─sda1 8:1 0 1,1G 0 part /boot ├─sda2 8:2 0 49,1G 0 part / ├─sda3 8:3 0 31,7G 0 part /home └─sda4 8:4 0 151G 0 part /mnt/Daten3
I have no swap partition, resume after hibernation works without errors.
Although there is an obvious workaround (permanently removing the resume parameter from the kernel command line), I still wonder what has happened?
Klaus-Peter Schrage composed on 2024-06-08 18:20 (UTC+0200):
Since kernel 6.8.10-300.fc40.x86_64, boot hangs on KDE Plasma (kernel 6.8.9-300.fc40.x86_64 was the last good one). I found that there is a job running infinitely:
'Job dev-disk-by\x2duuid-8e895....running ...' The above mentioned UUID (8e895 ...) corresponds to the kernel 'resume=uuid=...' command line parameter.
Does any device within your system actually include 8e895whatever within it?
When I comment it out in GRUB2, as suggested in
https://discussion.fedoraproject.org/t/solved-boot-hang-job-dev-disk-by-x2uu...
then the system boots as expected.
This is a rather fresh install of fedora 40 (running on ext4):
da 8:0 0 232,9G 0 disk ├─sda1 8:1 0 1,1G 0 part /boot ├─sda2 8:2 0 49,1G 0 part / ├─sda3 8:3 0 31,7G 0 part /home └─sda4 8:4 0 151G 0 part /mnt/Daten3
I have no swap partition, resume after hibernation works without errors.
Did you previously have a swap partition whose UUID included 8e895....?
Although there is an obvious workaround (permanently removing the resume parameter from the kernel command line), I still wonder what has happened?
# lsinitrd /boot/initramfs-6.8.11-300.fc40.x86_64.img | grep resume # If you run the above on 6.8.9, do you get the response I do? If yes, then it was creating a process destined to timeout and delay complete boot success. If no, then the resume= parameter in Grub was merely an override of that existing within your initramfs. Do you get the same result running the command on 6.8.10? When you removed it from Grub, you stopped creating what had not been specified in your initrd.
IOW what I think happened is that whether resume= existed within your initrd was changed from 6.8.9 to 6.8.10. Since I always have noresume instead of resume=, I don't think I ever have had resume=in any of my initrds.
Am 08.06.24 um 19:04 schrieb Felix Miata:
Klaus-Peter Schrage composed on 2024-06-08 18:20 (UTC+0200):
Does any device within your system actually include 8e895whatever within it?
No, there isn't any block device with an UUID (or PARTUUID) that includes 8e895
Did you previously have a swap partition whose UUID included 8e895....?
I once had a swap partition (of course, I don't remember its UUID), but it no longer existed when doing the fresh install of F40 on May 3rd.
# lsinitrd /boot/initramfs-6.8.11-300.fc40.x86_64.img | grep resume # If you run the above on 6.8.9, do you get the response I do? If yes, then it was creating a process destined to timeout and delay complete boot success. If no, then the resume= parameter in Grub was merely an override of that existing within your initramfs. Do you get the same result running the command on 6.8.10? When you removed it from Grub, you stopped creating what had not been specified in your initrd.
With 6.8.9, the output is empty like yours, on 6.8.10 an 6.8.11 I get those four lines:
resume
... usr/lib/systemd/systemd-hibernate-resume
... usr/lib/systemd/system-generators/systemd-hibernate-resume-generator
... usr/lib/systemd/system/systemd-hibernate-resume.service
IOW what I think happened is that whether resume= existed within your initrd was changed from 6.8.9 to 6.8.10. Since I always have noresume instead of resume=, I don't think I ever have had resume=in any of my initrds.
What I don't understand: What produced the entry "resume=UUID=8e895..." in the file /etc/default/grub which was created on the install date, May 3rd?
Klaus-Peter Schrage via users composed on 2024-06-09 13:47 (UTC+0200):
What I don't understand: What produced the entry "resume=UUID=8e895..." in the file /etc/default/grub which was created on the install date, May 3rd
Does your fstab or installation media or any other media used during or prior to F40 installation include that UUID fragment?
Am 09.06.2024 um 15:22 schrieb Felix Miata:
Klaus-Peter Schrage via users composed on 2024-06-09 13:47 (UTC+0200):
What I don't understand: What produced the entry "resume=UUID=8e895..." in the file /etc/default/grub which was created on the install date, May 3rd
Does your fstab or installation media or any other media used during or prior to F40 installation include that UUID fragment?
Sorry, I am rather clueless. I installed F40 from a live spin "KDE PLASMA DESKTOP", created with Fedora Media Writer which erased all previuos data on the USB media.
On Sun, Jun 9, 2024 at 7:47 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
What I don't understand: What produced the entry "resume=UUID=8e895..." in the file /etc/default/grub which was created on the install date, May 3rd?
Do you have a /etc/kernel/cmdline file? I was tripped-up recently because that file existed and had data that was not correct for what I was trying to do - an old kernel would boot, newer kernels would not.
Am 09.06.2024 um 20:09 schrieb Go Canes:
On Sun, Jun 9, 2024 at 7:47 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
What I don't understand: What produced the entry "resume=UUID=8e895..." in the file /etc/default/grub which was created on the install date, May 3rd?
Do you have a /etc/kernel/cmdline file? I was tripped-up recently because that file existed and had data that was not correct for what I was trying to do - an old kernel would boot, newer kernels would not.
Yes, I have. I includes the "resume=" parameter as well, and, according to the time stamp, was created (like /etc /default/grub) at install time. So Anaconda should have created it.
I try to sum up what I have learned from the diskussion in this thread: Still on F39, I have rearranged my system with partitions scattered on three drives (in another thread, I reported problems with grub that I supposed to have aroused from that). At that time, I had an old and small swap partition hanging around, which I hadn't used for years (meaning that it wasn't listed in fstab). Now it is no longer present, but a suppose it was at install time of F40.
I definitely did not include the old swap in the manual partition scheme, but I guess that Anaconda found it and included it into the files responsible for the resume kernel parameter. That was no problem until recent kernels which, as Barry stated, require that resume= refers to a physical partition.
Thanks to all who contributed!
On Mon, 2024-06-10 at 11:30 +0200, Klaus-Peter Schrage via users wrote:
That was no problem until recent kernels which, as Barry stated, require that resume= refers to a physical partition.
That's not strictly true. You can arrange to resume to a BTRFS subvolume. My boot params include:
resume=UUID=8e1f7af4-c0bf-434e-b1c4-a9af2c810d56 resume_offset=413818937
It does require some manual setting up however.
poc
On Mon, Jun 10, 2024 at 5:31 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
Am 09.06.2024 um 20:09 schrieb Go Canes:
On Sun, Jun 9, 2024 at 7:47 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
What I don't understand: What produced the entry "resume=UUID=8e895..." in the file /etc/default/grub which was created on the install date, May 3rd?
Do you have a /etc/kernel/cmdline file? I was tripped-up recently because that file existed and had data that was not correct for what I was trying to do - an old kernel would boot, newer kernels would not.
Yes, I have. I includes the "resume=" parameter as well, and, according to the time stamp, was created (like /etc /default/grub) at install time. So Anaconda should have created it.
If the "resume=" parameter is causing the problem, remove it from /etc/kernel/cmdline and rebuild one of the failing initramfs. If the rebuilt initramfs boots, rebuild the rest and you should be good.
Am 10.06.24 um 13:05 schrieb Go Canes:
On Mon, Jun 10, 2024 at 5:31 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
Am 09.06.2024 um 20:09 schrieb Go Canes:
On Sun, Jun 9, 2024 at 7:47 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
What I don't understand: What produced the entry "resume=UUID=8e895..." in the file /etc/default/grub which was created on the install date, May 3rd?
Do you have a /etc/kernel/cmdline file? I was tripped-up recently because that file existed and had data that was not correct for what I was trying to do - an old kernel would boot, newer kernels would not.
Yes, I have. I includes the "resume=" parameter as well, and, according to the time stamp, was created (like /etc /default/grub) at install time. So Anaconda should have created it.
If the "resume=" parameter is causing the problem, remove it from /etc/kernel/cmdline and rebuild one of the failing initramfs. If the rebuilt initramfs boots, rebuild the rest and you should be good.
Thanks! Well, I followed
https://fedoramagazine.org/setting-kernel-command-line-arguments-with-fedora...
and
# grubby --update-kernel=ALL --remove-args="resume=UUID=8e895273-b3ca-465e-b991-b7a0e4e10345"
was all I had to do, which (hopefully) should work on every present and future kernel.
On Mon, Jun 10, 2024 at 11:17 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
Thanks!
You're welcome!
Well, I followed
https://fedoramagazine.org/setting-kernel-command-line-arguments-with-fedora...
and
# grubby --update-kernel=ALL --remove-args="resume=UUID=8e895273-b3ca-465e-b991-b7a0e4e10345"
was all I had to do, which (hopefully) should work on every present and future kernel.
My understanding is that dracut will pull in the parameters from /etc/kernel/cmdline, so keep an eye on it.
Am 10.06.24 um 18:39 schrieb Go Canes:
On Mon, Jun 10, 2024 at 11:17 AM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
Thanks!
You're welcome!
Well, I followed
https://fedoramagazine.org/setting-kernel-command-line-arguments-with-fedora...
and
# grubby --update-kernel=ALL --remove-args="resume=UUID=8e895273-b3ca-465e-b991-b7a0e4e10345"
was all I had to do, which (hopefully) should work on every present and future kernel.
My understanding is that dracut will pull in the parameters from /etc/kernel/cmdline, so keep an eye on it.
I observed, that the grubby command did (at least) three things:
- Change the line GRUB_CMDLINE_LINUX in /etc/default/grub
- Recreate /etc/kernel/cmdline (which I had deleted before)
- Adjust all entries in /boot/loader/entries/
In all these places reference to the kernel command line was altered - I don't know which changes were really crucial, but all present kernels now boot as expected. The initramfs files in /boot were left unchanged.
On 8 Jun 2024 at 18:20, Klaus-Peter Schrage via users wrote:
Date sent: Sat, 8 Jun 2024 18:20:26 +0200 To: users@lists.fedoraproject.org Subject: Boot hangs on recent kernels Send reply to: Community support for Fedora users users@lists.fedoraproject.org From: Klaus-Peter Schrage via users users@lists.fedoraproject.org Copies to: Klaus-Peter Schrage kpschrage@gmx.de
Since kernel 6.8.10-300.fc40.x86_64, boot hangs on KDE Plasma (kernel 6.8.9-300.fc40.x86_64 was the last good one). I found that there is a job running infinitely:
'Job dev-disk-by\x2duuid-8e895....running ...' The above mentioned UUID (8e895 ...) corresponds to the kernel 'resume=uuid=...' command line parameter.
When I comment it out in GRUB2, as suggested in
https://discussion.fedoraproject.org/t/solved-boot-hang-job-dev-disk-by-x2uu...
then the system boots as expected.
might want to run blkid and see what it reports.
My notebook reports this type of info. Note lines wrap here, but you might see the uuid in that. Old notebook that originally had windows 7 but works fine. Uses kernel 6.8.11-300.fc40.x86_64
# blkid /dev/sdb1: LABEL_FATBOOT="G4L" LABEL="G4L" UUID="17AF-405F" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="G4L" PARTUUID="0b1903e5-65a5-429d-ad59-47e389d5e71b" /dev/sda2: LABEL="SYSTEM RESERVED" BLOCK_SIZE="512" UUID="2036488536485DC2" TYPE="ntfs" PARTUUID="7c819ab2-02" /dev/sda9: UUID="0fada7bc-4eb7-4a9d-a80b-10093423db8d" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7c819ab2-09" /dev/sda7: UUID="12b58c6d-c9f1-4ffe-ba7a-aa816f762ba3" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7c819ab2-07" /dev/sda5: UUID="fa908208-22bd-4031-b620-841498e0708c" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7c819ab2-05" /dev/sda3: LABEL="Acer" BLOCK_SIZE="512" UUID="6C224AD8224AA744" TYPE="ntfs" PARTUUID="7c819ab2-03" /dev/sda1: LABEL="PQSERVICE" BLOCK_SIZE="512" UUID="1C0647FA0647D384" TYPE="ntfs" PARTUUID="7c819ab2-01" /dev/sda8: UUID="0c44fcc6-2aa1-4dff-bd40-0dea2c17711f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7c819ab2-08" /dev/sda6: UUID="a5875ef2-b439-474f-9571-01e00c6599f3" TYPE="swap" PARTUUID="7c819ab2-06" /dev/zram0: LABEL="zram0" UUID="425a1d11-ec0a-495b-98f3-dd7aeb54b31b" TYPE="swap" /dev/sr1: BLOCK_SIZE="2048" UUID="2008-05-06-12-26-42-" LABEL="U3 System" TYPE="iso9660"
This is a rather fresh install of fedora 40 (running on ext4):
da 8:0 0 232,9G 0 disk ├─sda1 8:1 0 1,1G 0 part /boot ├─sda2 8:2 0 49,1G 0 part / ├─sda3 8:3 0 31,7G 0 part /home └─sda4 8:4 0 151G 0 part /mnt/Daten3
I have no swap partition, resume after hibernation works without errors.
Although there is an obvious workaround (permanently removing the resume parameter from the kernel command line), I still wonder what has happened? -- _______________________________________________ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
+------------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mikes@guam.net mailto:msetzerii@gmail.com mailto:msetzerii@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +------------------------------------------------------------+
Am 08.06.24 um 19:52 schrieb Michael D. Setzer II:
On 8 Jun 2024 at 18:20, Klaus-Peter Schrage via users wrote:
might want to run blkid and see what it reports.
The output is similar to yours, but
# blkid | grep -i 8e8952 # shows that there isnt any device with an UUID containing 8e8952... (the one that is part of the resume parameter of my kernel command line).
On 6/8/24 9:20 AM, Klaus-Peter Schrage via users wrote:
This is a rather fresh install of fedora 40 (running on ext4):
da 8:0 0 232,9G 0 disk ├─sda1 8:1 0 1,1G 0 part /boot ├─sda2 8:2 0 49,1G 0 part / ├─sda3 8:3 0 31,7G 0 part /home └─sda4 8:4 0 151G 0 part /mnt/Daten3
I have no swap partition, resume after hibernation works without errors.
If you have no swap, then how can you resume after hibernation? Do you mean suspend?
Am 08.06.24 um 22:04 schrieb Samuel Sieb:
On 6/8/24 9:20 AM, Klaus-Peter Schrage via users wrote:
This is a rather fresh install of fedora 40 (running on ext4):
da 8:0 0 232,9G 0 disk ├─sda1 8:1 0 1,1G 0 part /boot ├─sda2 8:2 0 49,1G 0 part / ├─sda3 8:3 0 31,7G 0 part /home └─sda4 8:4 0 151G 0 part /mnt/Daten3
I have no swap partition, resume after hibernation works without errors.
If you have no swap, then how can you resume after hibernation? Do you mean suspend?
Of course, please excuse my bad terminology.
On Sat, Jun 8, 2024 at 12:20 PM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
Since kernel 6.8.10-300.fc40.x86_64, boot hangs on KDE Plasma (kernel 6.8.9-300.fc40.x86_64 was the last good one). I found that there is a job running infinitely:
'Job dev-disk-by\x2duuid-8e895....running ...' The above mentioned UUID (8e895 ...) corresponds to the kernel 'resume=uuid=...' command line parameter.
A small nit... Boot is probably not hanging. You have not waited long enough for the timeouts and the fschk.
You should either (1) ensure disk UUIDs are correct, or (2) disable suspend. A good discussion in the context of Ubuntu is at https://askubuntu.com/a/1087262.
I've also seen a missing swap file cause the condition. In my case, I deleted the swap file, extended the physical size of the drive, and then created a new swap file at the end of the free space. The swap file's UUID changed, and it caused the slow boot waiting for timeouts and the fschk.
Jeff
Am 08.06.24 um 22:27 schrieb Jeffrey Walton:
On Sat, Jun 8, 2024 at 12:20 PM Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
Since kernel 6.8.10-300.fc40.x86_64, boot hangs on KDE Plasma (kernel 6.8.9-300.fc40.x86_64 was the last good one). I found that there is a job running infinitely:
'Job dev-disk-by\x2duuid-8e895....running ...' The above mentioned UUID (8e895 ...) corresponds to the kernel 'resume=uuid=...' command line parameter.
A small nit... Boot is probably not hanging. You have not waited long enough for the timeouts and the fschk.
It surely hangs ... The other day, I left boot unattended for more than an hour - Never Ending Tour.
You should either (1) ensure disk UUIDs are correct, or (2) disable suspend. A good discussion in the context of Ubuntu is at https://askubuntu.com/a/1087262.
I've also seen a missing swap file cause the condition. In my case, I deleted the swap file, extended the physical size of the drive, and then created a new swap file at the end of the free space. The swap file's UUID changed, and it caused the slow boot waiting for timeouts and the fschk.
What I already mentioned: It doesn't hang on kernel 6.8.9, only on more recent ones, with everything else left constant (e. g. no boot partition).
On 9 Jun 2024, at 13:06, Klaus-Peter Schrage via users users@lists.fedoraproject.org wrote:
What I already mentioned: It doesn't hang on kernel 6.8.9, only on more recent ones, with everything else left constant (e. g. no boot partition).
The latest kernels require that resume= refers to an existing partition.
You must remove the resume=xxx for the kernel command line to make your configuration valid so that the system will boot.
Barry
-
Barry Scott -
Felix Miata -
Go Canes -
Jeffrey Walton -
Klaus-Peter Schrage -
Michael D. Setzer II -
Patrick O'Callaghan -
Samuel Sieb