[Mageia-dev] MGA2 Installer + Bootloader stage issue: initrd regeneration not happening?

[Colin Guthrie]

'Twas brillig, and Colin Guthrie at 14/07/12 20:12 did gyre and gimble:
> 'Twas brillig, and Colin Guthrie at 14/07/12 20:04 did gyre and gimble:
>> 'Twas brillig, and Colin Guthrie at 14/07/12 19:49 did gyre and gimble:
>>> 'Twas brillig, and Olivier Blin at 14/07/12 17:30 did gyre and gimble:
>>>> Colin Guthrie <mageia at colin.guthr.ie> writes:
>>>>
>>>>> Hi,
>>>>>
>>>>> While debugging https://bugs.mageia.org/show_bug.cgi?id=6692#c8 I
>>>>> realised that the initrd is generated when the kernel is installed, but
>>>>> it's not regenerated again later.
>>>>
>>>> Hi,
>>>>
>>>> /root/drakx/ddebug.log might give some clue about what failed.
>>>
>>> Not a huge deal in it that gives (me) clues:
>>>
>>> * starting step `setupBootloader'
>>> * to put in /mnt/etc/modprobe.preload evdev
>>> * modify_append:
>>> * modify_append:  resume=UUID=f06016be-3bda-495d-900e-72f5c7d13a41
>>> * running: /sbin/display_driver_helper --is-kms-allowed with root /mnt
>>> * modify_append:  nokmsboot resume=UUID=f06016be-3bda-495d-900e-72f5c7d13a41
>>> * bootloader::suggest_onmbr: type empty, onmbr 1, unsafe 0
>>> * adding /boot/vmlinuz-3.3.6-desktop-2.mga2
>>> * current labels: linux
>>> * adding /boot/vmlinuz-3.3.6-desktop-2.mga2
>>> * current labels: linux linux-nonfb
>>> * adding /boot/vmlinuz-3.3.6-desktop-2.mga2
>>> * current labels: linux linux-nonfb failsafe
>>> * looking for configured grub on partitions
>>> * setupBootloaderBefore end
>>> * step `setupBootloader' finished
>>> ...
>>> * fs::get::device2part: unknown device <</dev/sda>>
>>> * running: keytab-lilo.pl us with root /mnt
>>> * program not found: keytab-lilo.pl
>>> * writing grub config to /mnt/boot/grub/menu.lst
>>> * Installing boot loader...
>>> * running: sh /boot/grub/install.sh with root /mnt
>>>
>>>
>>>     GNU GRUB  version 0.97  (640K lower / 3072K upper memory)
>>>
>>>  [ Minimal BASH-like line editing is supported.  For the first word, TAB
>>>    lists possible command completions.  Anywhere else TAB lists the possible
>>>    completions of a device/filename. ]
>>> grub> root (hd0,0)
>>>  Filesystem type is ext2fs, partition type 0x83
>>> grub> setup --stage2=/boot/grub/stage2 (hd0)
>>>  Checking if "/boot/grub/stage1" exists... no
>>>  Checking if "/grub/stage1" exists... yes
>>>  Checking if "/grub/stage2" exists... yes
>>>  Checking if "/grub/e2fs_stage1_5" exists... yes
>>>  Running "embed /grub/e2fs_stage1_5 (hd0)"...  17 sectors are embedded.
>>> succeeded
>>>  Running "install --stage2=/boot/grub/stage2 /grub/stage1 (hd0)
>>> (hd0)1+17 p (hd0,0)/grub/stage2 /grub/menu.lst"... succeeded
>>> Done.
>>> grub> quit
>>> * step `summary' finished
>>>
>>>
>>>
>>>>
>>>>> I'm not sure why this isn't working but perhaps someone more familiar
>>>>> with the installer itself (TV?) could comment?
>>>>>
>>>>> I was under the impression the initrd would be regenerated at the end?
>>>>> Does this even happen or have I just assumed this? I'm pretty sure in
>>>>> the past it did used to regenerate it but I could be mistaken.
>>>>>
>>>>> So the question then remains, how do we ensure that either:
>>>>>  a) the initrd is regenerated at the end of the install process
>>>>
>>>> That's ensured at the bootloader installation step.
>>>> If not present for every configured kernel, an initrd will be created.
>>>
>>> What if the initrd is present? e.g. it was created when the kernel was
>>> installed. Would it still be REgenerated at this stage? (I always
>>> presumed it would be or that it was not generated at the install time).
>>>
>>> Looking at the script /sbin/installkernel I see:
>>>
>>>  [ -z "$DURING_INSTALL" ] || exit 0
>>>
>>> So it shouldn't do anything when run as part of the kernel post
>>> install... So perhaps some other package triggers an initrd generation?
>>>
>>> Looking at things happening live... I see that the symlink
>>> initrd-desktop.img is created, but it points nowhere. I wonder could one
>>> of the bootsplash scripts do something like resolve the symlink name and
>>> then recreate the initrd automatically because the file does not exist?
>>
>> The initrd was generated at 12:49:00 So it was after these packages were
>> installed that it happened....
>>
>> Sat Jul 14 12:47:48 2012:lib64kms1
>> Sat Jul 14 12:47:48 2012:mageia-theme-common
>> Sat Jul 14 12:47:58 2012:bootsplash
>> Sat Jul 14 12:47:58 2012:bridge-utils
>> Sat Jul 14 12:47:58 2012:dash
>> Sat Jul 14 12:47:58 2012:plymouth-plugin-script
>> Sat Jul 14 12:47:59 2012:plymouth
>> Sat Jul 14 12:47:59 2012:plymouth-scripts
>> Sat Jul 14 12:47:59 2012:plymouth-system-theme
>> Sat Jul 14 12:48:00 2012:dracut
>> Sat Jul 14 12:48:00 2012:mageia-theme-Default
>> Sat Jul 14 12:48:07 2012:kernel-desktop-3.3.6-2.mga2
>>
>>
>> One of them must be the guilty party!!
> 
> As there was a period where the symlink existed but the initrd did not,
> I am presuming running /sbin/install kernel exited correctly without
> creating the initrd.
> 
> However, both plymouth and mageia-theme-Default seem to correctly honour
> DURING_INSTALL.
> 
> I'm confused as to what is causing it to be generated... can anyone else
> see it?


Oh wait, I think I see it:

In the post of mageia-theme-Default it has:

if [ "$1" == "0" ]; then
  /usr/sbin/plymouth-set-default-theme -R Mageia-Default
fi


This causes an initrd rebuild (-R argument) and doesn't check
DURING_INSTALL.

That's the problem.

Col


-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/