This is handled by kernel %post{,un} scripts

Source RPM: drakxtools => bootloader-utils

AFAIK this bug got fixed some time ago. Maybe you had some old kernel with this bug?

CC: (none) => sander.lepik

(In reply to comment #1)
> This is handled by kernel %post{,un} scripts


Nope.

kernel %post(un) scripts only alter the vmlinuz-$flavour and initrd-$flavour.img

the default /boot/vmlinuz and /boot/initrd.img is handled by bootloader-utils (or the drakx* backend)

...which is used by... kernel %post{,un} scripts

yeah, but I cant fix in kernel spec what the bootloader-utils/drakx* does as I only call /sbin/installkernel and /sbin/kernel_remove_initrd

(or technically I can if I do it "behind drakx* back", but...)

but we might be hitting another bootsplash bug too

(In reply to comment #2)
> AFAIK this bug got fixed some time ago. Maybe you had some old kernel with this
> bug?

No : I'm running cauldron with daily updates (no risk, no fun !). I keep only the 2 last versions of kernel.

Cannot reproduce here.

I've seen something similar in the past (long time ago) but I think the trigger conditions are much more complex than how you state here.

There was a bootspash bug recently that caused the initrd.img symlink to be overwritten with a file rather than a link... perhaps some hangover from that?

CC: (none) => mageia

one question, can you boot by choosing the right kernel from the list? i mean not choosing the "linux" default option...

CC: (none) => anaselli

I have set in release_blocker because I have seen somebody with a similar bug on irc after an upgrade of mga1

(In reply to comment #9)
> one question, can you boot by choosing the right kernel from the list? i mean
> not choosing the "linux" default option...

I have just reproduced the bug here, using urpme and no I cannot boot choosing the right kernel in the grub list because the line for the new kernel is not added.

I had this message :
(urpme desktop-3.3.1 -a)

Cannot find a bootloader installed. Only taking care of initrd.

CC: (none) => lists.jjorge

I can help repair, as I encountered the same kind of problem, but I did not
find the cause of it.

I ended up with many missing links of links still pointing to *2.6.38* in
/boot/

I could not diagnose what caused it, only the result which I tried to analyze
at 
http://mageiacauldron.tuxfamily.org/TestingMageia2Upgrade (see after title for upgrade of my laptop Latitude E6400).


To be short, correcting was "only" a matter of:
1. booting with an usb key with LiveUSB Mageia 1
2. chrooting after mounting my local hard disk partition
3. mounting /dev + /sysfs + /proc correctly
4. running dracut correctly
5. recreating the appropriate symlinks to *3.3.1* files
6. editing /boot/grub/menu.lst to have the appropriate entry

(not really in this order...)

CC: (none) => baud123

(In reply to comment #9)
> one question, can you boot by choosing the right kernel from the list? i mean
> not choosing the "linux" default option...

Yes, it boots without any problem when choosing the right kernel from the list.

(In reply to comment #8)
> Cannot reproduce here.
> 
> I've seen something similar in the past (long time ago) but I think the trigger
> conditions are much more complex than how you state here.
> 
> There was a bootspash bug recently that caused the initrd.img symlink to be
> overwritten with a file rather than a link... perhaps some hangover from that?

In fact, before the problem occurs, the /boot/initrd.img was currently a plain file ! I just saw messages in /var/log/user.log stating : 

 ERROR: /boot/initrd.img is not a symbolic link

May it be a potential cause of the problem ?

(In reply to comment #14)
> (In reply to comment #8)
> > Cannot reproduce here.
> > 
> > I've seen something similar in the past (long time ago) but I think the trigger
> > conditions are much more complex than how you state here.
> > 
> > There was a bootspash bug recently that caused the initrd.img symlink to be
> > overwritten with a file rather than a link... perhaps some hangover from that?
> 
> In fact, before the problem occurs, the /boot/initrd.img was currently a plain
> file ! I just saw messages in /var/log/user.log stating : 
> 
>  ERROR: /boot/initrd.img is not a symbolic link
> 
> May it be a potential cause of the problem ?


To be more precise, error message is :

bootloader-config[20182]: ERROR: /boot/initrd.img is not a symbolic link

Yup, see my comment from earlier:

There was a bootspash bug recently that caused the initrd.img symlink to be
overwritten with a file rather than a link... perhaps some hangover from that?

It would certainly be nice if that was the cause (as it's now fixed!).

Gah, you quoted my comment... I can't read :p

Just another thought. On upgrade we need to ensure that the upgraded bootspash is installed early before it's used as if this bug (the symlink overwrite issue) existed on mga1, it could still be used when the themes or kernel are installed and thus the scripts are used.

Just add conflicts with older version of bootsplash to (all) kernels then.
Or to just dracut. Should be enough since it's a new require of kernels

Hardware: i586 => All

dracut 017-9.mga2 will now conflict bootsplash < 3.3.9-1, and kernel-3.3.4-1 (that will be on the RC) will require dracut >= 017-9

This will not be enough. Bootsplash scripts are used by e.g. theme RPMs too. So similar tweaks will be needed there.

I don't know how many there are, but mageia-theme at least (I've just fixed it). 

urpmq --what-requires didn't seem to suggest anything else needs them, but there could be some stuff lurking there somewhere....

I'm using Cauldron and I have encountered the problem just a few days ago. I have the habit of removing some older kernels to keep the grub menu not too long to display on the screen.

Things were fine when I had a menu of default, failsafe, kernel-desktop-3.3.1-1, kernel-desktop-3.3.1-2, and kernel-desktop-3.3.3-1. Then the kernel-desktop-3.3.4-1 update came and I installed it. After the system rebooted, I removed kernel-desktop-3.3.1-1 and kernel-desktop-3.3.1-2. Rebooting again, and the problem occurred.

I checked the /boot/ dir, and found there didn't exist any /boot/initrd.img symbolic link, but a /boot/initrd-desktop.img one did exist instead. So I went to Mageia Control Center, trying to reinstall the grub thing, and on the step for editing the grub menu, I edited the default and failsafe menu items by choosing /boot/initrd-desktop.img from the drop-down list in the advanced options. This solved the problem for me.

CC: (none) => piscestong

I'm pretty sure this bug was caused by a bug that was fixed a couple of
weeks ago. (Can't remember which package it was right now).

As such, it only affects people upgrading older cauldron installations.

I'll close this bug, but feel free to reopen if you can recreate the
problem, installing a new kernel, starting with a Mageia 1 system,
or a clean install of cauldron.

Status: NEW => RESOLVED
CC: (none) => davidwhodgins
Resolution: (none) => WORKSFORME