___Symptom: After updating kernel today, system fail to boot; After having entered the encryption key it soon scrolls several iterations of: mount: /dev is not a block device umount: /sysroot: not mounted device node has wrong file type device node has wrong file type And then: Dracut Warning: Can't mount root filesystem Dropping to debug shell But it is not much one can do there... ___Why it can not boot: Inspection find that grub entries for the default start as well as the specific new kernel points to wrong root ___How reproducible: 2 of 2 almost identical systems using LUKS configured as in "Steps to Reproduce" got hit. (specifics: current mga2-64 KDE on two Lenovo T61 laptops, SSD drives) Issue did *not* appear on two other laptops not using LUKS, running mga2-32 KDE on mechanical drives, root, swap, home on LVM. ___Steps to Reproduce: 1. Install mga2 *(not net install as we want it to have old kernel), partition using installer as separate /boot rest as LVM, tick encrypted, and in it create / /home swap. (later using gparted I see that /boot is a primary partition and the encrypted is in extended partition) 2. Update kernel 3. Reboot - Or better, mcc -> Start -> Start system and inspect the entries, see that root is set to /dev/sda1 but should be /dev/vg-mga/root (or similar) __How to boot anyway alt 1) at boot menu, select elder kernel alt 2) at boot menu, select failsafe. The question for encryption key is hidden (known bug) but start typing it and youĺl see... then there is another invisible prompt, issue init 3. Then ther eis blackness but disk working... then you can login as regular user, then startx and you are up. __How to fix Once booted, mcc -> Start -> Start system and inspect the entries, see that root is set to /dev/sda1 change to /dev/vg-mga/root (or how it should be for you, see entry for elder kernel, or the failsafe entry)
CC: (none) => thierry.vignaud, tmbSource RPM: (none) => drakxtools ?
Same issue here. In my case I'm using a plain ext3 partition as root, but I modified fstab and menu.lst to use LABEL instead of device names/UUIDs. The line for the default kernel after the update had just a "root=/dev/" instead of "root=LABEL=mdv20090" (and later on the was a section named the same with the correct root). I just used the grub menu to edit the entry in order to boot the new kernel. This is menu.lst after the update: timeout 10 color black/cyan yellow/cyan gfxmenu (hd0,4)/boot/gfxmenu default 1 title windows root (hd0,0) makeactive chainloader +1 title linux kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=linux root=/dev/ nokmsboot resume=UUID=2ab3d1fe-f531-11dd-bfba-00237de74325 vga=0x368 initrd (hd0,4)/boot/initrd.img title sin_initrd kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=linux root=/dev/sda5 rootfstype=ext3 nokmsboot resume=UUID=2ab3d1fe-f531-11dd-bfba-00237de74325 vga=0x368 title desktop 3.3.8-2.mga2 kernel (hd0,4)/boot/vmlinuz-3.3.8-desktop-2.mga2 BOOT_IMAGE=desktop_3.3.8-2.mga2 root=LABEL=mdv20090 nokmsboot resume=UUID=2ab3d1fe-f531-11dd-bfba-00237de74325 initrd (hd0,4)/boot/initrd-3.3.8-desktop-2.mga2.img title alt_windows root (hd0,0) makeactive chainloader +1 title linux kernel (hd0,4)/boot/vmlinuz BOOT_IMAGE=linux root=LABEL=mdv20090 nokmsboot resume=UUID=2ab3d1fe-f531-11dd-bfba-00237de74325 vga=0x368 initrd (hd0,4)/boot/initrd.img title desktop 3.4.24-3.mga2 kernel (hd0,4)/boot/vmlinuz-3.4.24-desktop-3.mga2 BOOT_IMAGE=desktop_3.4.24-3.mga2 root=/dev/ nokmsboot resume=UUID=2ab3d1fe-f531-11dd-bfba-00237de74325 vga=0x368 initrd (hd0,4)/boot/initrd-3.4.24-desktop-3.mga2.img
CC: (none) => luca
BTW, that was a 32 bit system. I just checked another system (64 bits) where I updated the kernel but didn't reboot, and that has the correct "root=LABEL=..." in place.
Interesting... I wonder what is the common thing here... Also see Bug 8734 for similar problem on cauldron and LVM And possibly the erroneous detection of partition have something in common with my Bug 5811 where fstab get mangled.
Sorry wrong reference, Bug 8717 (not 8734)
CC: (none) => thomas.bigot
Still valid, latest update of mga2. Another odd thing is that in menu.lst it say root=/dev/, while opening in MCC->Start->Configure start system, it say different: that root is /dev/sda1 sda1 is the root partition, everything else is in encrypted lvm. And the correct root is /dev/vg-mga/root
Typo: i meant sda1 is the boot partition
CC: (none) => mageia
Please attach (not paste) your /etc/fstab. Can you try this patch: https://bugs.mageia.org/attachment.cgi?id=3684 then try installing another kernel (such as kernel-tmb-latest: urpmi kernel-tmb-latest 2>&1|tee -a LOG_8738.txt). Do you got any error? Also attach the generated LOG_8738.txt file
try Attachment #3685 [details] instead.
try Attachment #3686 [details] instead :-(
CC: (none) => nelg
I guess this is fixed with that same remedy as bug 8717 for mga3, waiting to test drakxtools update on mga2.
Last mga2 kernel update to -45 exactly the same problem. Applying patches is over my head, not my cup of tea, unfortunately. If you can put something in -testing i can test downgrad and upgrade kernel again. I think will probably work as on mga3, and after i test it can be pushed. My mga3 (RC + updates) machine with same LVM on LUKS setup handle grub correctly when upgrading kernels.
Morgan, please test if you can with the following procedure : as root, edit /usr/sbin/bootloader-config (after saving a copy of it) look for the following line : my $root_part = fs::get::root([ fs::get::fstab($all_hds) ]) or die "cannot find root partition\n"; On my mga2 it's line 153. Replace it with those lines: my $fstab = [ fs::get::fstab($all_hds) ]; my $root_part = fs::get::root($fstab); use Data::Dumper; warn Data::Dumper->Dump([ $all_hds, [ fs::get::fstab($all_hds) ], $root_part ], [ qw(all_hds fstab root_part) ]); is_empty_hash_ref($root_part) and die "cannot find root partition\n";
Keywords: (none) => NEEDINFOCC: (none) => stormiSource RPM: drakxtools ? => drakxtools-backend
Warning : warn Data::Dumper->Dump([ $all_hds, [ fs::get::fstab($all_hds) ], $root_part ], [ qw(all_hds fstab root_part) ]); must be on the same line (see contents of the attached patch to be sure)
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Mageia 2 changed to end-of-life (EOL) status on ''22 November''. Mageia 2 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD