|Summary:||initrd created with scripts from the host, not the package set|
|Product:||[Fedora] Fedora||Reporter:||Jeremy Katz <katzj>|
|Component:||LiveCD||Assignee:||Jeremy Katz <katzj>|
|Status:||CLOSED RAWHIDE||QA Contact:||David Lawrence <dkl>|
|Version:||rawhide||CC:||dcantrell, triage, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-04-04 00:08:14 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Jeremy Katz 2007-03-20 15:30:06 UTC
The version of mayflower used is from what's installed on the host spinning the liveCD. We should probably instead get the initrd created with things that are installed into the livecd chroot.
Comment 1 Jane Dogalt 2007-07-13 02:55:41 UTC
(In reply to comment #0) > The version of mayflower used is from what's installed on the host spinning the > liveCD. We should probably instead get the initrd created with things that are > installed into the livecd chroot. I think a better way to address the issue is - the version of mayflower used should be the one from the host spinning the livecd, but it should be run under the chroot, and compose the initrd from files under the chroot. (which as I look at the code it clearly already does). I think there should be no dependency on an installed mayflower, just as their would be no dependency on an installed mksquashfs. The latter should come from the squashfs-tools installed on the build host, for the same reasons that I think mayflower should come from the build host as well. I.e. it is a an external build tool, which needn't bloat (even by a few kB) the target livecd.
Comment 2 Jeremy Katz 2007-07-16 19:46:11 UTC
(In reply to comment #1) > I think there should be no dependency on an installed mayflower, just as their > would be no dependency on an installed mksquashfs. The latter should come from > the squashfs-tools installed on the build host, for the same reasons that I > think mayflower should come from the build host as well. I.e. it is a an > external build tool, which needn't bloat (even by a few kB) the target livecd. No, it's not. It's very dependent on the package set being installed (eg, the definition of what modules go in, etc is going to vary based on the target distro) and maintaining that information outside of the repo where packages are being installed from is a recipe for lots of pain. Ultimately, it'd be nice to just be using the normal initrd infrastructure too. That would keep us from having to integrate support for things like network booting which are already supported with mkinitrd. Some of the steps to move this direction with mkinitrd have started with the bash-branch (so that we use bash and better scripting rather than nash as a shell), but it needs some more time/hacking to get to a good place.
Comment 3 Bug Zapper 2008-04-03 23:44:08 UTC
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
Comment 4 Jeremy Katz 2008-04-04 00:08:14 UTC
This actually gets taken care of with F9