Description of problem: I am unable to boot my Mageia 10 Cauldron system using kernel 6.6.22-desktop-2.mga10 and above, including kernel 6.6.28-desktop-1.mga10 . On my system, I use an LVM volume which contains /root (as ext4 partition), /home (as ext4 partition) and swap partition. /boot exists as a separate ext4 partition not part of LVM, and /boot/EFI exists as a separate vfat partition not part of LVM. When booting an affected kernel, it times out with a dracut prompt stating that it could not boot, as my root and swap partitions does not exist (likely meaning that they cannot be mounted, the physical device it exists on is detected). The printout given is as follows (volume names slightly edited for privacy): dracut Warning: Cancelling resume operation. Device not found. dracut Warning: Could not boot. dracut Warning: Cancelling resume operation. Device not found. dracut Warning: Could not boot. dracut Warning: /dev/mapper/main-root does not exist. dracut Warning: /dev/mapper/main-swap does not exist. ... Dropping to debug shell. I have also noticed that with the non-booting kernels, LVM is not loaded, so debugging in dracut shell is very limited. I have tried to rebuild initrd for an affected kernel, using mkinitrd, without any affect. I have also noticed that a working kernel has an initrd size of about 41MB, and a not-booting kernel has an initrd size of about 39MB. I have also tried to rebuild grub from the Mageia 9 recovery media, also without any affect. However, kernel 6.6.22-desktop-1.mga10 and below, boots and functions as expected. Version-Release number of selected component (if applicable): kernel-desktop-6.6.22-2.mga10.x86_64, kernel-desktop-6.6.27-1.mga10.x86_64, kernel-desktop-6.6.28-1.mga10.x86_64 How reproducible: Every time kernel 6.6.22-desktop-2.mga10 or newer is selected from grub. Steps to Reproduce: 1. Use LVM for root, home, swap 2. Boot kernel 6.6.22-desktop-2 or newer 3. Wait a few minutes until dracut timeout
Thank you for the report. (In reply to lazerdude from comment #0) > Description of problem: > I am unable to boot my Mageia 10 Cauldron system using kernel > 6.6.22-desktop-2.mga10 and above, including kernel 6.6.28-desktop-1.mga10 . > > On my system, I use an LVM volume which contains /root (as ext4 partition), > /home (as ext4 partition) and swap partition. /boot exists as a separate > ext4 partition not part of LVM, and /boot/EFI exists as a separate vfat > partition not part of LVM. All this looks correct. > However, kernel 6.6.22-desktop-1.mga10 and below, boots and functions as > expected. Important; a regression. Assigning to kernel.
Source RPM: (none) => kernelAssignee: bugsquad => kernel
I was able to reproduce the issue within Virtualbox. Here are the steps taken: Create a Mageia 9 virtual machine, in System -> Motherboard settings of the virtual machine, enable EFI. Install mageia 9 as normal, but in disk partitioning, create it as the following: /boot - ext4 /boot/EFI - fat32 Create an LVM with the remaining space. Within the LVM, create /root ext4 and swap. Then proceed to install as normal. Once installed, update the system to latest updates. It should be noted that kernel 6.6.28-desktop-1.mga9 works as expected here. Now upgrade the system to a cauldron system following the instructions on the wiki. Upon bootup of the new cauldron system, select kernel 6.6.28-desktop-1.mga10 and it will fail to boot, dropping the user into a dracut shell.
I decided to test today if building kernel 6.6.28 from the source rpm on my local mga10 machine would make any difference, as well as rebuild initrd targeting my compiled kernel (using mkinitrd), and to my surprise it boots correctly and appears to function as expected. So it seems that this may be a build-system related issue, perhaps as a guess from the i586->i686 transition, though why it would affect x86_64 I am not sure.
FWIW I have three systems happily using latest mga9 kernels with LVM on a LUKS partition, separate ext4 /boot, two using legacy BIOS and one EFI (Laptop Asus Aspire 7). For testing, maybe you can try the mga9 kernel kernel-desktop-6.6.28-1.mga9.x86_64
CC: (none) => fri
Today I upgraded my real Cauldron machine to kernel 6.6.32-desktop-1.mga10, as well as my test virtualmachine to the same kernel, and it seems to work correctly, thus resolving my problem.
Status: NEW => RESOLVEDResolution: (none) => FIXED