Upgrading from F39 to F40 (ya i know) but the dnf install reboot hangs with the circle of death and never gets to logon.
I can reboot into the F39 kernel (6.11.9) but the F40 kernel (6.12.11) always hangs.
This is older lenovo P500 with Woodcrest Xeon(R) CPU E5-2630 v3 if that matters.
Some pointers would be appreciated.
In grub ecit to remove the rhgb and quiet options.
Then see how far into the boot you get.
Let us know what you see.
Also worth checking the grub command line for any refs to a disk uuid you do not have.
I am application guy. How do i get to grub ecit (exit?)
As you boot the system hold down SHIFT - you should then see the grub menu.
Select the new kernel type “e” to edit the entry.
Go to the line that starts linux and remove rhgb and quiet from it.
Then type Ctrl-X to boot.
You should see the kernel and systemd boot messages.
Where does it hang?
Thank you, that was helpful.
So the last 2 lines where:
[ OK ] finished systemd-vconsole-setup.service - Virtual Console Setup.
[ ] Job dev-disk-by\xZduuid-43680908\xZd4fde\xZd05841b3fc499.device/start running ( / no limit)
From the Disks tool this would be my 34Gb Raid-0 swap parition
Swap (version 1) — Not Active
/dev/md/swap
43680908-6127-4fde-ab55-05841b3fc499
A couple years ago I upgraded memory to 64Gb. Don’t this systems uses swap space at all.
But F37/38/39 had no problems with this.
BTW. the total disk config is 10Tb.
this looks like
check the kernel cmdline for resume=uuid- and try booting without this option
ah the old f39 kernel is 6.11. so this probably is something else, but looks suspiciuosly similar.
Yes removing the resume on the swap UUID allowed the F40 reboot to complete.
So how do I remove that permanently?
sudo grubby --remove-args="<the full string to be removed>" --update-kernel=ALL
verify with sudo grubby --info=ALL
It worked with f39 because it did timeout after 45 seconds.
This worked.
Not sure when the kernel stopped liking raid-0 swap partitions.
But elliminating:
resume=UUID=43680908-6127-4fde-ab55-05841b3fc499
Allowed boot to logon.
If I’m not mistaken, then the boot process hangs if the kernel could not find the uuid! Many users removed their swap partition/volume and migrated to zram but forgot to remove the resume= option.
I guess swap is on a MD disk? Is root volume also a MD device (RAID1) ?
Is root volume also a MD device (RAID1) ?
Yes
I was able to reproduce with a vm. Created swap on a MD device (/dev/md0) and added the resume=uuid= line.
I suspect this has never really worked with your setup, because the md device has not been assembled yet when the kernel tries to access swap to see if there is a hybernated session stored.
So if you don’t hybernate your system, then leave it as it is.
Otherwise you need to tell the kernel to assemble this MD device very early.
see man dracut.conf add_device=
f39 or older waited up to 45 seconds for the resume-uuid to be available and continued to boot the system, f40+ waits indefinitely for the resume-uuid to appear.
How is it that /dev/md/swap is “not assembled”
The Disks tools knows about it and lists it in the volumes as:
34 GB (34,376,515,584 bytes)
Swap (version 1) — Not Active
/dev/md/swap
43680908-6127-4fde-ab55-05841b3fc499
at this stage it’s not yet available.
I think this is still in the early initramfs stage. System needs to know whether to resume a hybernated session or proceed with a normal boot.
Ok I can do without this for now.
But If I allocated swap on a primary partition of a HD would that work?
Or does it have to be on the same HD as /boot (root)?
AFAIK, any swap partition that is not part of a MD device or LVM should support hybernation (resume=UUID= ). I think it needs to be encrypted though.
For your current setup, you can use your MD for swap but for resume it won’t work OOB. I think you need to build a custom initramfs or add the RAID UUID with rd.md.uuid= to the kernel cmdline.
sudo mdamd --detail /dev/md/swap
sudo grubby --args="rd.md.uuid=<raid uuid>" --update-kernel=0 # first kernel only
sudo grubby --args="resume=UUID=<swap uuid>" --update-kernel=0
I don’t know if this will prevent the kernel from assembling the raid device for the root filesystem. though.
If boot works, test hybernate / resume cycles and then make the grubby changes default ( --update-kernel=ALL ).