Could save some space by omitting /boot/vmlinuz from live filesystem

[Mantas Kriaučiūnas]

currently /boot/vmlinuz* file inside filesystem.squashfs is (and should be) the same identifical file, which is on CD, look at /casper/vmlinuz file.

As vmlinuz file is going to be bigger and bigger in every new Linux kernel (currently about 2 Mb) I think it would be wise to remove /boot/vmlinuz* file before compressing filesystem.squashfs when building CD images (like /boot/initrd.img* is removed) and use only one file - /casper/vmlinuz

I understand, that /boot/vmlinuz* file is needed in installed system, but I think for ubiquity there is no difference from which location to copy this file...
Another solution would be create a symlink (which is named like original file /boot/vmlinuz-2.6.nn-blablabla and point to /cdrom/casper/vmlinuz) afer removing original /boot/vmlinuz-2.6.nn-blablabla when creating CD images.

If my suggested solutions aren't good enough for you I think we can find better solution, but waste about 2 Mb in CD isn't good, especially when these 2 Mb can't be compressed (linux images are already compressed)...

[Colin Watson (cjwatson)]

This can only be done with the addition of custom code in ubiquity to make sure that /boot/vmlinuz ends up on /target. I'm willing to consider it, although I'm concerned that this sort of hack is error-prone.

[Colin Watson (cjwatson)]

Move ubuntu-cdimage script to livecd-rootfs.

[Colin Watson (cjwatson)]

("script"? I meant "bug task", of course. Sorry for confusion.)

[Oliver Grawert (ogra)]

i'd like to note that the space hogging part of kernel packages isnt actually the vmlinuz binary nor the initramfs but the modules put under /lib/modules ... in cases where the squashfs is used on teh target device (i.e. USB keys, installs to small flash devices etc) the 80-100M can make a massive difference for the overall squashfs size (ths might be worth to be put into a different bug though but i found it worth mentioning here) ...

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubiquity - 1.9.4

---------------
ubiquity (1.9.4) intrepid; urgency=low

  [ Colin Watson ]
  * Preseed netcfg/dhcp_ntp_servers to the empty string so that clock-setup
    stops breaking.
  * Find and copy the kernel from the CD root if it is missing from the live
    filesystem (LP: #80385).

  [ Jonathan Riddell ]
  * Update install.py for KDE 4's KDM
  * Remove kpersoniser disabling from install.py, kpersonaliser is dead

 -- Colin Watson <email address hidden> Fri, 18 Jul 2008 19:56:43 +0100

[Launchpad Janitor (janitor)]

This bug was fixed in the package livecd-rootfs - 0.62

---------------
livecd-rootfs (0.62) intrepid; urgency=low

  * Use 'set -eu' rather than putting -eu on the #! line, so that running
    'sh -x /usr/sbin/livecd.sh' for testing doesn't invoke different
    error-handling behaviour.
  * Remove the kernel from the livefs; ubiquity >= 1.9.4 will copy it from
    the CD root if it needs to (LP: #80385).

 -- Colin Watson <email address hidden> Fri, 18 Jul 2008 20:01:15 +0100

[Colin Watson (cjwatson)]

Oliver: while this is true, I think it should indeed be a separate bug. /lib/modules is significantly harder to do anything about in Ubiquity. It would be possible, and merely fiddly rather than difficult, to "fill in" parts of /lib/modules from the initramfs if they aren't in the live filesystem. However, in order for this to do any good, you have to remove the modules from the live filesystem as well. Now, what happens if the modules in question don't get loaded by the initramfs for whatever reason but are needed later on? You'd have to copy /lib/modules from the initramfs to the unionfs as well, and that would take up a lot of memory. Even if you copied only those modules that haven't been loaded, that would cause reliability problems: unloading and then reloading any module that had been loaded during the initramfs would fail.

I think this might be tractable for specific devices, but so far I haven't thought of a general-purpose way to exploit this duplication.

[Oliver Grawert (ogra)]

i filed bug #250500 for the additional issue.