python-imgcreate adds syslinux to the list of installed packages. AFAICS that is because it uses data files from syslinux in the installed root to populate isolinux. It do not execute any syslinux files in the installed root.
The problem is that syslinux depends on perl. The unused syslinux on the livecd is the only reason my live cd has perl, and it thus costs 30+ Mb.
How do you think that could be solved / worked around?
Could python-imgcreate be changed to use files from the build system if they can't be found in the installed root?
Or could syslinux be split into a executable package depending on perl and a /usr/share/syslinux package?
/Mads
I haven't tried this, but how about:
%post yum -C -y remove perl %end
Make sure you know what you're doing... by which I mean that this would be a dangerous game to play if you weren't certain that syslinux was the only thing using perl!
As I recall, by the time %post executes, the initrd has already been created (see previous posts passim.). If syslinux data files are being used in that stage, then removing them in %post shouldn't screw things up. If they're being used after the squashfs image gets created, you might be in trouble.
Suck it and see...
James
On Tue, 2010-03-02 at 20:03 +0000, Mads Kiilerich wrote:
python-imgcreate adds syslinux to the list of installed packages. AFAICS that is because it uses data files from syslinux in the installed root to populate isolinux. It do not execute any syslinux files in the installed root.
The problem is that syslinux depends on perl. The unused syslinux on the livecd is the only reason my live cd has perl, and it thus costs 30+ Mb.
How do you think that could be solved / worked around?
Could python-imgcreate be changed to use files from the build system if they can't be found in the installed root?
Or could syslinux be split into a executable package depending on perl and a /usr/share/syslinux package?
/Mads
livecd mailing list livecd@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/livecd
On 03/02/2010 11:34 PM, James Heather wrote:
On Tue, 2010-03-02 at 20:03 +0000, Mads Kiilerich wrote:
python-imgcreate adds syslinux to the list of installed packages. AFAICS that is because it uses data files from syslinux in the installed root to populate isolinux. It do not execute any syslinux files in the installed root.
The problem is that syslinux depends on perl. The unused syslinux on the livecd is the only reason my live cd has perl, and it thus costs 30+ Mb.
How do you think that could be solved / worked around?
Could python-imgcreate be changed to use files from the build system if they can't be found in the installed root?
Or could syslinux be split into a executable package depending on perl and a /usr/share/syslinux package?
I haven't tried this, but how about:
%post yum -C -y remove perl %end
Yes, that would remove perl, but it will not remove whatever dependencies has been installed because of it. So I will have to enumerate these packages or use package-cleanup.
As I recall, by the time %post executes, the initrd has already been created (see previous posts passim.). If syslinux data files are being used in that stage, then removing them in %post shouldn't screw things up. If they're being used after the squashfs image gets created, you might be in trouble.
I wasn't sure that the syslinux files from the installed root was extracted before %post (when the initrd was built). But now I have convinced myself that that is how it has to be and how it is.
So yes, thank you, that is perhaps the workaround I asked for. But I had hoped to find something prettier than that ... ;-)
/Mads
Mads Kiilerich a écrit :
Or could syslinux be split into a executable package depending on perl and a /usr/share/syslinux package?
This looks like the best solution to me in the long term. If a small, well defined and useful subset of syslinux can be isolated, saving 30Megs of dependencies, then it should be extracted to some new, small "syslinux-data" RPM. This could be useful in other contexts.
Marc Herbert wrote, On 03/03/2010 11:19 AM:
Mads Kiilerich a écrit :
Or could syslinux be split into a executable package depending on perl and a /usr/share/syslinux package?
This looks like the best solution to me in the long term. If a small, well defined and useful subset of syslinux can be isolated, saving 30Megs of dependencies, then it should be extracted to some new, small "syslinux-data" RPM. This could be useful in other contexts.
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.
Using files from different unrelated packages even has the risk of causing problems whenever the feature-set changes.
I think the best solution is to drop the hardcoded dependency to syslinux and use the files from the host system. Perhaps something like the following (untested) patch.
And of course, if anyone wants to customize or replace these files they can do whatever they want and modify it in an unchrooted %post, just like all other boot-loader manipulations
/Mads
diff --git a/imgcreate/live.py b/imgcreate/live.py --- a/imgcreate/live.py +++ b/imgcreate/live.py @@ -308,7 +308,7 @@ "-boot-load-size", "4" ]
def _get_required_packages(self): - return ["syslinux"] + LiveImageCreatorBase._get_required_packages(self) + return LiveImageCreatorBase._get_required_packages(self)
def _get_isolinux_stanzas(self, isodir): return "" @@ -316,7 +316,7 @@ def __find_syslinux_menu(self): for menu in ("vesamenu.c32", "menu.c32"): for dir in ("/usr/lib/syslinux/", "/usr/share/syslinux/"): - if os.path.isfile(self._instroot + dir + menu): + if os.path.isfile(dir + menu): return menu
raise CreatorError("syslinux not installed : " @@ -337,10 +337,10 @@ files += [mboot]
for f in files: - if os.path.exists(self._instroot + "/usr/lib/syslinux/" + f): - path = self._instroot + "/usr/lib/syslinux/" + f - elif os.path.exists(self._instroot + "/usr/share/syslinux/" + f): - path = self._instroot + "/usr/share/syslinux/" + f + if os.path.exists("/usr/lib/syslinux/" + f): + path = "/usr/lib/syslinux/" + f + elif os.path.exists("/usr/share/syslinux/" + f): + path = "/usr/share/syslinux/" + f if not os.path.isfile(path): raise CreatorError("syslinux not installed : " "%s not found" % path)
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?
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". 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.
Using files from different unrelated packages even has the risk of causing problems whenever the feature-set changes.
Could you elaborate on this?
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.
FYI: my build system tends to be automatically kickstarted to avoid the concerns I mentioned above.
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
On Thu, Mar 04, 2010 at 12:32:19 +0100, Mads Kiilerich mads@kiilerich.com wrote:
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.)
There is a problem with root password changing not working if it is run in enforcing mode. If you forget to go to permissive during the build you have to do some work to be able to install from the image later.
Expect there to be an lzma/zlib option in F14.
Bruno Wolff III wrote, On 03/06/2010 08:24 PM:
On Thu, Mar 04, 2010 at 12:32:19 +0100, Mads Kiilerichmads@kiilerich.com wrote:
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.)
There is a problem with root password changing not working if it is run in enforcing mode. If you forget to go to permissive during the build you have to do some work to be able to install from the image later.
There is also the nscd problem (https://bugzilla.redhat.com/show_bug.cgi?id=481796) (if it still is a problem?). It would be nice to get some kind of workaround implemented ... or at least a warning.
/Mads
On Sat, Mar 06, 2010 at 20:35:41 +0100, Mads Kiilerich mads@kiilerich.com wrote:
There is also the nscd problem (https://bugzilla.redhat.com/show_bug.cgi?id=481796) (if it still is a problem?). It would be nice to get some kind of workaround implemented ... or at least a warning.
Yeah, I forgot about not being able to umount the build areas if livecd-creator gets shutdown after it starts installing stuff. That gets annoying quickly when you don't have a lot of free space.
livecd@lists.fedoraproject.org
-
Bruno Wolff III -
James Heather -
Mads Kiilerich -
Marc Herbert