I am using livecd-creator from livecd-tools-024-1.fc11.i586 and need to customize the initrd. But I have problems making it work and figuring out what is going on.
I have figured out that livecd-creator through imgcreate creates a /etc/sysconfig/mkinitrd. When rpms runs mkinitrd from their %post script then it will exec mkliveinitrd and use the configured module list. AFAICS livecd-creator then picks up the initrd from /boot, and the end result after having written the iso to usb with livecd-iso-to-disk is that it ends up in /syslinux/initrd0.img.
But if I overwrite the /boot/initrd* in %post like this: /sbin/mkinitrd -f /boot/initrd-$(rpm -q kernel --qf '%{version}-%{release}.%{arch}\n').img $(rpm -q kernel --qf '%{version}-%{release}.%{arch}\n') then it won't be used.
What am I doing wrong? When is the initrd picked up? What is the code flow?
If I make %post preserve /etc/sysconfig/mkinitrd and boots from usb and restores /etc/sysconfig/mkinitrd and runs /sbin/mkinitrd -f /mnt/live/syslinux/initrd0.img $(rpm -q kernel --qf "%{version}-%{release}.%{arch}\n") then it works as expected.
/Mads
On Saturday, August 15 2009, Mads Kiilerich said:
I have figured out that livecd-creator through imgcreate creates a /etc/sysconfig/mkinitrd. When rpms runs mkinitrd from their %post script then it will exec mkliveinitrd and use the configured module list. AFAICS livecd-creator then picks up the initrd from /boot, and the end result after having written the iso to usb with livecd-iso-to-disk is that it ends up in /syslinux/initrd0.img.
Correct
But if I overwrite the /boot/initrd* in %post like this: /sbin/mkinitrd -f /boot/initrd-$(rpm -q kernel --qf '%{version}-%{release}.%{arch}\n').img $(rpm -q kernel --qf '%{version}-%{release}.%{arch}\n') then it won't be used.
What am I doing wrong? When is the initrd picked up? What is the code flow?
%post runs after we've set up the boot loader bits. Otherwise, it %wouldn't be the last thing run. So if you want to do this, you have to do something like we did for Fedora 8 on the initial move of initramfs stuff into mkinitrd proper. See commit 11dbd0bb5ba4b845e80109e990e4e780ca402218
Also note that all of this is subject to some amount of change in Fedora 12 with the move to using dracut instead of mkinitrd
Jeremy
Jeremy Katz wrote, On 08/15/2009 04:45 AM:
On Saturday, August 15 2009, Mads Kiilerich said:
I have figured out that livecd-creator through imgcreate creates a /etc/sysconfig/mkinitrd. When rpms runs mkinitrd from their %post script then it will exec mkliveinitrd and use the configured module list. AFAICS livecd-creator then picks up the initrd from /boot, and the end result after having written the iso to usb with livecd-iso-to-disk is that it ends up in /syslinux/initrd0.img.
Correct
But if I overwrite the /boot/initrd* in %post like this: /sbin/mkinitrd -f /boot/initrd-$(rpm -q kernel --qf '%{version}-%{release}.%{arch}\n').img $(rpm -q kernel --qf '%{version}-%{release}.%{arch}\n') then it won't be used.
What am I doing wrong? When is the initrd picked up? What is the code flow?
%post runs after we've set up the boot loader bits. Otherwise, it %wouldn't be the last thing run.
I intuitively expected %post to be the last step in the kickstart process, but to come before the "taking a snapshot of the chroot and transforming it to something bootable" part. But no one size fits all. Ok. Perhaps different %posts could make some things simpler.
So if you want to do this, you have to do something like we did for Fedora 8 on the initial move of initramfs stuff into mkinitrd proper. See commit 11dbd0bb5ba4b845e80109e990e4e780ca402218
Oh yeah. livecd-creator thinks (knows) that it is creating a CD, and thus the initrd is (has to be) in $LIVE_ROOT/isolinux/initrd0.img.
So /sbin/mkinitrd -f $LIVE_ROOT/isolinux/initrd0.img $(rpm -q kernel --qf "%{version}-%{release}.%{arch}") in %post should do the trick? I will try that.
I tried and was looking for $LIVE_ROOT/syslinux/initrd0.img as it can be seen on running USB sticks, but that mangling is only done later by livecd-iso-to-disk ...
I have had some problems with things copied to $LIVE_ROOT in nonchrooted %post not showing up on the final system, but that might be livecd-iso-to-disk too - I will try harder.
Thanks!
/Mads
On Saturday, August 15 2009, Mads Kiilerich said:
Jeremy Katz wrote, On 08/15/2009 04:45 AM:
On Saturday, August 15 2009, Mads Kiilerich said:
What am I doing wrong? When is the initrd picked up? What is the code flow?
%post runs after we've set up the boot loader bits. Otherwise, it %wouldn't be the last thing run.
I intuitively expected %post to be the last step in the kickstart process, but to come before the "taking a snapshot of the chroot and transforming it to something bootable" part. But no one size fits all. Ok. Perhaps different %posts could make some things simpler.
Yep, it's unfortunate but either way makes someone unhappy :/ Being consistent and saying "last means last" helps a lot there
So if you want to do this, you have to do something like we did for Fedora 8 on the initial move of initramfs stuff into mkinitrd proper. See commit 11dbd0bb5ba4b845e80109e990e4e780ca402218
Oh yeah. livecd-creator thinks (knows) that it is creating a CD, and thus the initrd is (has to be) in $LIVE_ROOT/isolinux/initrd0.img.
So /sbin/mkinitrd -f $LIVE_ROOT/isolinux/initrd0.img $(rpm -q kernel --qf "%{version}-%{release}.%{arch}") in %post should do the trick? I will try that.
Nope -- really, look at the commit[1]. You need the two separate %post sections as it shows you; you can't do just one
I tried and was looking for $LIVE_ROOT/syslinux/initrd0.img as it can be seen on running USB sticks, but that mangling is only done later by livecd-iso-to-disk ...
Yep
I have had some problems with things copied to $LIVE_ROOT in nonchrooted %post not showing up on the final system, but that might be livecd-iso-to-disk too - I will try harder.
Generally we don't copy most things from the CD to the usb stick because we don't know which things matter and then also don't know how to clean the stick, etc if you want to replace things. Other ideas welcome, but probably best implemented in liveusb-creator rather than livecd-iso-to-disk.
Jeremy
[1] http://git.fedorahosted.org/git/livecd?p=livecd;a=commit;h=11dbd0bb5ba4b845e...
Jeremy Katz wrote, On 08/16/2009 02:14 AM:
So if you want to do this, you have to do something like we did for Fedora 8 on the initial move of initramfs stuff into mkinitrd proper. See commit 11dbd0bb5ba4b845e80109e990e4e780ca402218
Oh yeah. livecd-creator thinks (knows) that it is creating a CD, and thus the initrd is (has to be) in $LIVE_ROOT/isolinux/initrd0.img.
So /sbin/mkinitrd -f $LIVE_ROOT/isolinux/initrd0.img $(rpm -q kernel --qf "%{version}-%{release}.%{arch}") in %post should do the trick? I will try that.
Nope -- really, look at the commit[1]. You need the two separate %post sections as it shows you; you can't do just one
Ok, thanks. I'm trying to understand which parts of that commit is essential to me.
So it is because LIVE_ROOT only is available in not in_chroot %post scripts? And the initrd thus has to be created in a normal chrooted %post and copied to the right location in a non-chrooted %post?
Is there any particular reason why LIVE_ROOT isn't available in chroots? Couldn't the image always mounted under $INSTALL_ROOT/mnt/live? Or bind-mounted?
/Mads
On Sunday, August 16 2009, Mads Kiilerich said:
Jeremy Katz wrote, On 08/16/2009 02:14 AM:
So if you want to do this, you have to do something like we did for Fedora 8 on the initial move of initramfs stuff into mkinitrd proper. See commit 11dbd0bb5ba4b845e80109e990e4e780ca402218
Oh yeah. livecd-creator thinks (knows) that it is creating a CD, and thus the initrd is (has to be) in $LIVE_ROOT/isolinux/initrd0.img.
So /sbin/mkinitrd -f $LIVE_ROOT/isolinux/initrd0.img $(rpm -q kernel --qf "%{version}-%{release}.%{arch}") in %post should do the trick? I will try that.
Nope -- really, look at the commit[1]. You need the two separate %post sections as it shows you; you can't do just one
Ok, thanks. I'm trying to understand which parts of that commit is essential to me.
Basically all of it :) eg, when testing mkliveinitrd changes (*sigh*), I use roughly that snippet plus something which grabs my hacked up mkliveinitrd
So it is because LIVE_ROOT only is available in not in_chroot %post scripts? And the initrd thus has to be created in a normal chrooted %post and copied to the right location in a non-chrooted %post?
Correct.
Is there any particular reason why LIVE_ROOT isn't available in chroots? Couldn't the image always mounted under $INSTALL_ROOT/mnt/live? Or bind-mounted?
As much as possible, we try to keep the environment consistent for %post scripts so they can be transferred between real system kickstarts and live image kickstarts. Having things mounted differently like that would impact that
Jeremy
Jeremy Katz wrote, On 08/16/2009 11:25 PM:
On Sunday, August 16 2009, Mads Kiilerich said:
Jeremy Katz wrote, On 08/16/2009 02:14 AM:
So if you want to do this, you have to do something like we did for Fedora 8 on the initial move of initramfs stuff into mkinitrd proper. See commit 11dbd0bb5ba4b845e80109e990e4e780ca402218
Oh yeah. livecd-creator thinks (knows) that it is creating a CD, and thus the initrd is (has to be) in $LIVE_ROOT/isolinux/initrd0.img.
So /sbin/mkinitrd -f $LIVE_ROOT/isolinux/initrd0.img $(rpm -q kernel --qf "%{version}-%{release}.%{arch}") in %post should do the trick? I will try that.
Nope -- really, look at the commit[1]. You need the two separate %post sections as it shows you; you can't do just one
Ok, thanks. I'm trying to understand which parts of that commit is essential to me.
Basically all of it :) eg, when testing mkliveinitrd changes (*sigh*), I use roughly that snippet plus something which grabs my hacked up mkliveinitrd
Thanks, it works fine now. But I don't see why "all of it" should be used.
I am using something like a normal %post with
/sbin/mkinitrd -f /initrd0.img $(rpm -q kernel --qf "%{version}-%{release}.%{arch}")
and a %post --nochroot with mv $INSTALL_ROOT/initrd0.img $LIVE_ROOT/isolinux/
- with the initrd location chosen so that no "rm -f /boot/initrd*" interferes.
Is there any particular reason why LIVE_ROOT isn't available in chroots? Couldn't the image always mounted under $INSTALL_ROOT/mnt/live? Or bind-mounted?
As much as possible, we try to keep the environment consistent for %post scripts so they can be transferred between real system kickstarts and live image kickstarts. Having things mounted differently like that would impact that
Now I know how it works and how to work around it, so I have no problem. But in order to improve the system further and help the next newbie I will argue for some changes:
Making scripts for real installation and for live building as similar as possible is a fine goal. And obviously, when live image kickstarts in some cases needs special %post scripts then it can't be reached completely.
I think that an even more important goal is "%post environment is as close to runtime environment as possible". For real kickstarts "all" file systems mounted on runtime are mounted when %post is run too, so it would be consistent if the same was the case for live kickstarts. I realize that the runtime mount point for /dev/only (currently) only (?) is defined in the %post script in fedora-live-base.ks, so imgcreate wouldn't know where to mount it.
Another fine goal is " '%post' and '%post --nochroot' should be as similar as possible - except for the chroot".
In any case: Having the live root mounted somewhere specified by $LIVE_ROOT in all %post scripts (chroot or not) would make script contexts more consistent and make some things simpler (such as building custom initrd for F11...), and I don't see how it could have any negative impact on the goal of %post scripts being the same for real kickstart and for live image composition.
/Mads
Jeremy Katz wrote, On 08/15/2009 04:45 AM:
%post runs after we've set up the boot loader bits. Otherwise, it %wouldn't be the last thing run. So if you want to do this, you have to do something like we did for Fedora 8 on the initial move of initramfs stuff into mkinitrd proper. See commit 11dbd0bb5ba4b845e80109e990e4e780ca402218
Also note that all of this is subject to some amount of change in Fedora 12 with the move to using dracut instead of mkinitrd
For the record, as a followup to the famours 11dbd0bb5ba4b845e80109e990e4e780ca402218 quote, I now do something like this and it seems to work just fine:
%post /usr/sbin/plymouth-set-default-theme script /sbin/dracut -f /initrd0.img $(rpm -q kernel --qf '%{version}-%{release}.%{arch}')
%post --nochroot mv $INSTALL_ROOT/initrd0.img $LIVE_ROOT/isolinux/
(at least as long as I don't use PAE kernels ;-) )
/Mads
livecd@lists.fedoraproject.org
-
Jeremy Katz -
Mads Kiilerich