On 03/04/2010 11:49 AM, Marc Herbert wrote: > Hi Mads, > >> Livecd-creator is executed on the host system and creates isolinux.cfg >> (syslinux.cfg) by its own logic and hardcoded templates. It also runs >> isohybrid if available, and the hosts livecd-iso-to-disk runs syslinux. >> I don't see any reason why livecd-creator should use vesamenu.c32 and >> isolinux.bin from the installed image. > > Because it makes sure they are available and from a well defined > version?
Good point. But they still they are referenced from a boot loader installation and syslinux.cfg and which doesn't come from a well defined version. > I think a bootloader is generally supposed to "belong" to the system it > boots. People say that they have installed "Fedora 16", not "Fedora 16 > and GRUB 3.14". On the other side: The bootloader is a meta thing which only for convenience is so deeply and seamlessly integrated with Fedora. That is also why a image unaware of syslinux can be booted with syslinux, even though some packages (kernels/dracut/plymouth) does a (IMHO) hackish but efficient "layering violation" and assumes that grub is used. Looks like you are suggesting to make the liveCD even > more an exception to this rule than it already is. Is this the right > design choice? I honestly do not know. If it made sense I would prefer > going all the opposite way and depend as little as possible from the > software of the (unknown) build system. Right now there _is_ an exception, and I think it should be a primary goal here to make it more consistent - with or without an exception. livecd-creator itself _is_ an exception. Using a different version of livecd-creator can make a huge difference to the created image. (livecd-creator has however been very stable recently - stable in the sense that it works fine and there hasn't been much new development.) A consequence of what you propose would be to install livecd-creator (and anaconda?) in the image and let it do all the hard work with applying the kickstart configuration and installing the boot loader. Obviously the build system would have to bootstrap it, probably mostly by taking care of the %package section. I guess that could work, but I think it is unfortunate to put even more dependencies into the live image. I would rather focus on making sure that the live image only contains what is need on runtime. >> Using files from different unrelated packages even has the risk of >> causing problems whenever the feature-set changes. > > Could you elaborate on this? What I meant was that with the content of syslinux.cfg coming from livecd-creator in the build system and vesamenu.c32 and isolinux.bin from the installed image then they can come out of sync, and it will be hard to ever make changes to either of them. >> I think the best solution is to drop the hardcoded dependency to >> syslinux and use the files from the host system. > > Then a new "syslinux-data" RPM would still be useful - now to the build > system. IMHO the dependency chain isn't that big a problem on the build system, and more important: The build system will (in most cases) need "syslinux-executables" anyway. I'm not sure that splitting syslinux up to allow mixing independent parts is an good idea. > FYI: my build system tends to be automatically kickstarted to avoid the > concerns I mentioned above. I can see how that can be a good idea - assuming that you have a stable local yum mirror. /Mads -- livecd mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/livecd
