Age | Commit message (Collapse) | Author |
|
--hdd-partition-start
|
|
|
|
|
|
|
|
in the code:
--firmware-binary
--firmware-chroot
--hooks
--parent-mirror-chroot-updates
--parent-mirror-chroot-backports
--parent-mirror-binary-updates
--parent-mirror-binary-backports
--mirror-chroot-updates
--mirror-chroot-backports
--mirror-binary-updates
--mirror-binary-backports
--templates
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in the command line get ignored. Adds a documentation line for the other
command line options as well.
|
|
-f was --filesystem
-l was --language
-p was --package-list
-e was --encryption
|
|
functionality was added 2008-11-01, but was not really active.
|
|
functionality was added 2008-11-01, but was not really active.
|
|
Since syslinux 5.00, this file is installed into the disk root by the
extlinux and syslinux installer commands. For pxelinux and isolinux,
these files still need to be added manually. This is documented at:
https://wiki.syslinux.org/wiki/index.php?title=Library_modules#All_Syslinux_variants_need_an_additional_ldlinux_module
Keeping these unused files around is probably only confusing, so better
to remove them.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This option was removed in commit 7e633e77f (Moving grub and grub2
templates into shared bootloader config directory.), but the
documentation stayed around.
|
|
|
|
Before Stretch there was an special amd64 kernel in the i386 arch repo.
So if you wanted to install an amd64 kernel alongside an i386 system
you did not need an additional arch repo.
Debian added multiarch support. That way you can install library packages
from multiple architectures on the same machine.
So there is no longer a need for having an amd64 kernel in i386 arch repo.
You can add an amd64 arch repo to an i386 arch system and fetch the amd64
kernel from the am64 arch repo.
live-build can be setup to use several linux kernel flavours in a single
image.
So in the days previous to this patch you could issue:
lb config --linux-flavours "486 amd64"
to use both 486 and amd64 kernel flavours.
Adding additional arch support to linux flavours poses two problems:
* Packages need to have its arch suffix (e.g. amd64:amd64).
If the suffix is not there apt-get insists on search amd64 kernel
package on i386 arch repo and, of course, fails to find it.
* The rest of the code which handles labels (bootloader config files)
or installed filenames (kernel images themselves) do not use the arch suffix.
This patch adds foreign architecture package support to
linux kernel flavours having taken those problems into account.
Practical example usage: i386 system and extra amd64 kernel.
First add amd64 foreign architecture in your i386 system
thanks to:
dpkg --add-architecture amd64
apt-get update
.
Finally enable amd64 kernel from amd64 arch alongside the
i386 system's 686 kernel thanks to:
lb config --architectures i386 --linux-flavours "686 amd64:amd64"
|
|
|
|
|
|
|
|
Building image will fail without this directory for buster
|
|
replace deprecated httpredir.debian.org to deb.debian.org and use
it as default mirror since it is appropriate for users
|
|
|
|
It's an error on Stretch, which causes annoyances when backporting.
|
|
|
|
|
|
Not used at the moment, but it will be in the future when we bump it,
so that we don't forget
|
|
Turns out gcd works fine after adding /boot/grub/grub.cfg in the img,
as that's the path that gets hardcoded, and adding the EFI/debian/
grub.cfg was not necessary, so remove it.
|
|
For secured boot in binary_grub-efi, the gcdx64.efi.signed is
the boot loader for removable device, like CD or USB flash drive,
while grubx64.efi.signed is for hard drive. Therefore for live system,
use gcdx64.efi.signed for amd64 and gcdaa64.efi.signed for arm64.
|
|
not be ignored.
|
|
With the merged /usr feature now enabled in debootstrap, we have
/bin and /lib which are symlinks to /usr/bin and /usr/lib. If
the live-build configuration provides files in
config/includes.chroot/lib/ or config/includes.chroot/bin/ then
lb chroot_includes will replace the /lib or /bin symlink with real
directories having only the content provided in chroot.includes and
problems will follow... the build will usually fail later with a
cryptic error message (for example a hook failing to execute
/usr/bin/env).
Work around the issue by creating a tarball of the files to install
and by unpacking that tarball from within the chroot with appropriate
options.
|
|
|
|
|