'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 <[email protected]> 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/
