Unfortunately, syslinux as of wheezy and newer apparently does not support
long filenames anymore. Therefore, we do have to shorten the filenames
from:
/live/vmlinuz-3.2.0-1-amd64
/live/initrd.img-3.2.0-1-amd64
to:
/live/vmlinuz
/live/initrd.img
In case more than one kernel flavour is used, the files are being
numbered, starting with vmlinuz1 and initrd1.img.
If LB_BACKPORTS=true, then backports are configured in sources.list,
however, not enabled.
If backports are enabled depends on pinning, either manually through
apt/preferences.d snipplets in local includes/chroot_apt, or,
depending on distribution (e.g. building artax-backports enables
pinning automatically).
If both bootstrap-base and live-installer are available on the installer,
live-installer is prefereded by d-i (because of the live specific .disk info).
If live-installer is included, can be disabled with live-installer/enable=false
and d-i will use bootstrap-base in order to debootstrap the base system on
/target.
This reverts part of cacf9b6e34 (but also adds a "bind" option to the
remount command, as documented in mount(8)).
Apparently, doing "mount -o bind,ro" doesn't work. It outputs:
mount: warning: chroot/root/config seems to be mounted read-write.
and mounts read-write instead of read-only. This behaviour is
documented in mount(8). Newer kernels do seem to allow
combining bind with the read-only option (see mount(2)), but this does
not seem to work (possibly because mount is trying to be smart).
Previously, the config was bindmounted inside the chroot only for hooks
from the config dir, now it is done earlier so it is available for all
hooks.
Note that it is now also done if there are no hooks, but this is
probably enough of an exception case to not warrant the extra plumbing
required to detect the case (and doing an extra bindmount shouldn't
really hurt anyway...).
lb_chroot_hooks would copy the hooks to run to
chroot/root/lb_chroot_hooks, but then try to run them from chroot/root
(which obviously fails). This means lb_chroot_hooks has not been working
for hooks from /usr/share/live/build/hooks since lb_chroot_hooks was
added in revision e4793268. Running hooks from the config directory was
unaffected.
Apparently, dash doesn't expand shell patterns within a quoted string,
whereas bash does. We can't remove the quoting entirely, though, since
that would cause problems when $LB_BASE or $_HOOK contains spaces (note
that $_HOOK can probably never contain spaces, but let's handle it just
in case). Only quoting the expansion of $LB_BASE and $_HOOK, but not the
shell pattern should make the hooks work with both bash and dash again.
Daniel Baumann
intrigeri
Colin Watson
Matthijs Kooijman