[SOLVED] Unable to update kernel -- mkinitrd locks up

[ishark]

Hello,
I've run into a quite weird problem which I never encountered before. After (unsuccesfully) trying to install the NVIDIA driver, I ended up messing with some of the files of the latest kernel package, so in order to put things back in order, I just reinstalled it. The installation locked up in the post-script execution, leaving me with an unbootable system.
Since this is a secondary PC, I just reformatted and reinstalled from the Mageia 1 i568 CD. I did the basic set-up (= network, the machine is not supposed to be used for anything else than firefox), one user, you get the idea.
The I fired up drakconf to update the system, grabbed the 1st mirror from the list it offered (zarb.org) and launched the update.

At the kernel package, the updater stopped.

After some more tests, I tracked down the problem to mkinitrd. The kernel package is updated correctly, but then when the post-script execution invokes mkinitrd, this last step fails. With the package installed (but no initrd image -- so the system is not bootable), I invoked mkinitrd manually with -v to see were exactly it's stopping. It stops immediately after printing the first line ("creating initramfs"). The processor is at 0% activity, I tried to wait something like 5-10 minutes, nothing happened.

The weird thing, is that before I started messing with it, I had updated the kernel in the past. It's right now that mkinitrd is failing (also note: the CD installation works, so the mkinitrd invokation at that time works fine).

So my two questions:
- can you imagine anything which could be the cause? No hardware changes were done on the PC between the 1st install+updates and the reinstall.
- my only guess is that mkinitrd locks up attempting to determine which modules to load (= determining the hardware), is there a way to crank up the verbosity of mkinitrd so that I can see EXACTLY which device detection hangs up the process?

Thanks in advance.

[ishark]

Ok, I might have found the cause.

What I did:
- mkinird is a shell script, by editing it and adding 'set -xv' at the beginning enables full debugging mode: all lines executed are printed to the screen, so if the process locks up, it's possible to see WHERE.
- it's locking up in nashResolveDevice, when trying to convert the UUID of the / and /home partitions into a /dev/sdXX string. In fstab, replacing UUID=.... with /dev/sdXX solves the problem (mkinitrd successfully creates the initrd.img)
- the reason MAY be that my partition table is strange: I have /dev/sda3 (a primary partition) which corresponds to sectors which are inside /dev/sd4 (the extended partition). How this came to be is completely beyond me, but chances are that it messes up the device search. I'll try to repartition the disk, but I don't want to reformat, so i'll be a high anxiety moment , and see if it solves the problem.

[ishark]

Confirmed: upon recreating the partition table so that the partitions do not overlap the problem disappears.