Bug 8738

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)

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

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 :-(

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) => NEEDINFO
CC: (none) => stormi
Source 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 => RESOLVED
Resolution: (none) => OLD