If 'eatmydata' is found, use it.
On a CI system calling 'sync' influences the other processes that are
running on the shared host. 'debootstrap' calls 'sync' in its second
stage. For live-build, the synchronisation is not required.
When building against the snapshot server, adjust the sources.list entry
such that 'apt-get update' (in the live environment) will not complain
about the expired release file
See #1090981: dictionaries-common: Randomness in emacsen-ispell-dicts.el
(now due to enchant)
This applies the same patch as proposed in the bug report and makes the
output of 'update-dictcommon-aspell' reproducible again.
The error message:
N: Download is performed unsandboxed as root as file '/root/packages/./InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
The _apt user cannot access files in /root/packages, instead /packages
will be used.
Add the apt indices for the additional source of packages on the live
medium. It allows for installing packages from that source without
running 'apt-get update' first
Fixes the "Invalid 'Date' entry in Release File
/var/lib/apt/lists/partial/_run_live_medium_dists_bookworm_Release"
message when running 'apt-get update'
The previous version with faketime can hang Java on some machines. This
solution adds a tiny startup delay when required, but effectively keeps
the image reproducible (because the offending file is not present in the
image, but will be generated on startup)
This makes the postinst file from ca-certificates-java
(/etc/ssl/certs/java/cacerts) reproducible.
It contains embedded timestamps for 'now'.
Debian-Junior includes ca-certificates-java and is now reproducible.
Package realtek-firmware 20240909-2 migrated to testing/trixie. The
removal of firmware-realtek-rtl8723cs-bt in #1085075 has not taken place
yet, so the workaround needs to be applied to trixie too.
When a configuration file for Calamares is diverted by e.g.
`config-package-dev`, it becomes a symlink. The in-place modifications
must be applied on the symlinked file, not on a newly created copy.
After removal of the package, no remainders are left.
See https://salsa.debian.org/live-team/live-build/-/merge_requests/353#note_540394
dracut uses the `iso-scan/filename` kernel parameter for loopback
booting with tools like Super Grub Disk, whereas live-boot uses the
`findiso` parameter for this purpose. Conditionally set which one is
used depending on the selected initramfs.
There is a file conflict in the non-free-firmware realtek packages,
which prevent the sid live images from being built.
This workaround will be removed a soon as the bug is resolved.
Iterate over source package names and call `apt-get source $srcpkg`, instead of
looping over binary package names and calling `apt-get source $binpkg`.
Taking libreoffice as an example, this means calling `apt-get source
libreoffice` once instead of hundreds of times.
Specify --only-source in `apt-get source` to make explicit the fact that the
argument is a source package name. This is necessary to make ambiguous cases
work, such as `libftdi1` which is both a source package name and a binary
package provided by a different source, `libftdi`.
The checksums in source/{live,debian}/sha256sum.txt are identical with and
without this patch.
We need to ensure that anna always auto-loads live-installer when running d-i
to install a live system, regardless of the presence of a udeb_include to copy.
* zsync was orphaned 2021-09-19 #994648
* zsync FTBFS with GCC-14 #1075710
* zsync was only available for iso and iso-hybrid
* zsync output is ignored by the live-setup package which generates the
official live images
/bin/hostname and /sbin/start-stop-daemon are being moved from / to /usr
in trixie. Hence, these diversions become ineffective. Temporarily add
both diversions to handle both variants.
Closes: #1064408
Add IMAGE_ID=live and BUILD_ID set to a human-readable SOURCE_DATE_EPOCH.
If building sid, also fix the broken VERSION_CODENAME so that it matches
reality.
When the zero-byte file /etc/.pwd.lock is present in the ISO image,
diffoscope will abort
(https://salsa.debian.org/reproducible-builds/diffoscope/-/issues/367)
This file will be generated when needed, so it can be removed from the
image.
Cleanup /run/mount/utab (and its directory)
Work together with Emanuele Rocca during MiniDebCamp Hamburg 2024
* rebuild: New command line option: --architecture
* installer: Enable the GTK installer
* bootloader: Set a default bootloader
* no qemu-binary in chroot
When grub-efi-amd64-signed and grub-common have mismatched
dependencies (e.g. due to binNMUs), allow a shim-only secure boot.
The user has to enroll the hash of the EFI/boot/grub*.efi file and then
secure booting can continue.
Shim-only is supported only for '--uefi-secure-boot=auto'
This fixes the last non-reproducible file for KDE (bookworm):
* install-info has an unstable sort when a new section is started
Newer versions (not yet released) have been fixed
* The backup file (dir.old) does not need to be in the live image
For bookworm, live-config does not contain the fix for #1037295
With the patched policykit file, many password prompts will not show up
any more, e.g. with Calamares
* source_tar: The order of the files in the tarball are now predictable.
This has been verified with 'disorderfs'
* rebuild.sh: The timestamp of the directory of theme.txt must also be
adjusted.
The test 'if [ x$grub_platform == xefi -a x$lockdown != xy ]' is meant
to be done by GRUB at runtime, so this line should appear verbatim in
the grub.cfg file.
However the variables are expanded at build-time by the script, because
the dollar symbol is not escaped.
Here's the result on a 12.1.0 live image:
$ cat <<debian-live-12.1.0>>/boot/grub/x86_64-efi/grub.cfg
if [ x == xefi -a x != xy ] ; then
insmod part_acorn
insmod part_amiga
insmod part_apple
insmod part_bsd
insmod part_dfly
insmod part_dvh
insmod part_gpt
insmod part_msdos
insmod part_plan
insmod part_sun
insmod part_sunpc
fi
source /boot/grub/grub.cfg
Note that this mistake would have been caught if only the nounset option
had been used (ie. 'set -u').
Fixes commit: 7b36f5b0ad
Setting the value of PARTITIONLIST in a sub-shell is scoped to the
sub-shell, it will not change the value of the variable in the parent
shell.
In other words:
#!/bin/sh
FOOBAR=
(FOOBAR=foo)
echo FOOBAR=$FOOBAR
gives the output:
FOOBAR=
As a consequence, PARTITIONLIST being empty, there are no part_*
modules embedded in the boot<platform>.efi binary. This is clearly a
regression, introduced in 7b36f5b0ad.
Somehow, Debian doesn't seem to be impacted. Kali Linux is impacted, but
only under very special conditions, leading to this bug report:
<https://bugs.kali.org/view.php?id=8441>
This commit fixes it, by setting the PARTITIONLIST variable first, and
then using it where needs be. As a consequence it greatly simplifies the
next part of the code, as we can just use a heredoc to create the grub
config.
As noted in https://lists.debian.org/debian-live/2023/08/msg00008.html,
the timestamp of theme.txt for bookworm images is not reproducible.
Additionally the splash image is now matching the resolution of the boot
menu, which makes it more crisp.
because it doesn't end on ".hook.chroot", so it wouldn't be linked from
the `lb config` stage. Probably to the better, as it does not seem very
useful to indiscriminately raze all apt sources lists.
The shim EFI file on Ubuntu can be a symlink, as it may be in the alternatives system, so
previously, when calculating the size of the FAT32 partition, we would measure the size of the
symlink instead of the actual file and get "Disk full" errors when trying to copy the files into
the new FAT32 partition.
If we dereference the file on copy, we get the actual file and can calculate the size accurately.
```
lrwxrwxrwx. 1 root root 36 Jul 12 20:04 bootx64.efi -> /etc/alternatives/shimx64.efi.signed
```
* The ISO volume is constructed similar to Debian 11
* The file .disk/info can be overridden
* The file .disk/info does not contain 'Official' per default
* Overrides that are required for live-setup are now explicit in
rebuild.sh
* New .disk/generator contains tracable information to the rebuild.sh
script
* The ISO volume is unique for each desktop environment
When building the Debian installer from git, ignore any configured
kernel version, and use the kernel version that is present in the chroot
environment.
This fixes a build error on Trixie/testing, which occurred after a new
kernel became available when the freeze was lifted.
Follow-up for 18ad612b72.
The availability of 'firmware-linux' must be checked inside the chroot
instead of on the host.
This fixes building Bullseye without 'non-free' available (as discovered
by autopkgtest)
The font size was reduced to fully capture the long live-build version.
Exported without Inkscape information.
Manually adjusted the coordinates to use integers instead of fractional
coordinates (for sharper conversion to png).
d-i and Calamares select the needed grub packages based on how the
computer is started (BIOS vs UEFI). Because the packages for each
variant conflict, they must be provided as .deb files.
Commit 8403487d introduced in the chroot stage a naming scheme for local
archive keys which distinguishes between ASCII-armored keys and binary
ones, and then adds the appropriate extension (either `.asc` or `.gpg`,
respectively) when copying them to `/etc/apt/trusted.gpg.d`.
However, this change was not applied to the binary stage: ASCII-armored
and binary keys are still both copied with the `.asc` extension, which
introduces a discrepancy between the two stages. This, in turn,
may prevent using the same `.list` file for both stages, as entries
such as
deb [signed-by=/etc/apt/trusted.gpg.d/my-repository.key.asc] ...
will fail in the chroot stage if `config/archives/my-repository.key`
is in binary format (as it will be copied with the `.gpg` extension),
while entries such as
deb [signed-by=/etc/apt/trusted.gpg.d/my-repository.key.gpg] ...
will fail in the binary stage (as the key will this time be copied
with the `.asc` extension).
Previous commits to support Memtest86+ 6.00+ split the files into
"memtest" (backwards compatible / new BIOS name) and "memtest.efi"
(new EFI name). However, the 6.00 non-EFI binaries are now
32/64-bit, and will not work with GRUB's linux16 boot when using GRUB
for BIOS boot.
- Legacy Memtest86+ pre-6.00 will continue to be "memtest", linux16
(continue to support builds on current Debian stable bullseye)
- Change 6.00+ filename to "memtest.bin"
- GRUB memtest.cfg contains logic for legacy / new bios / new EFI
- Change EFI boot from "chainloader" to "linux", which allows for
passing command line options to Memtest86+
- syslinux @MEMTEST@ will conditionally be memtest.bin or memtest
- @MEMTEST_BIN@ will conditionally be memtest.bin or memtest, but is
completely legacy at this point (all internal code paths now check
for @MEMTEST_DIR@/memtest or @MEMTEST_DIR@/memtest.bin)
Getting complicated, but this logic can be simplified again once we
no longer need to support current Debian stable.
- BIOS: Final filename doesn't change (memtest), but now uses a
64-bit version on amd64.
- EFI: Now included as memtest.efi; 32-bit on i386, 64-bit on amd64.
As it's GRUB-only, we can test for the existence of memtest.efi
(6.00+ only) in GRUB itself.
- Add @MEMTEST_DIR@ to facilitate directory-based testing in GRUB.
This expands upon the previous MVP commit
15e78a3eec .
memtest86+ 6.00-1 (in testing as of this date) adds and changes its
available binaries:
- /boot/memtest86+x32.bin
- /boot/memtest86+x32.efi
- /boot/memtest86+x64.bin
- /boot/memtest86+x64.efi
Future live-build functionality would ideally incorporate these new
binaries (x64 for amd64 builds, efi for grub-efi), but in the meantime,
this is an MVP update which supports either old memtest86.bin or new
memtest86+x32.bin.
The request asked for 5 additional variables to be resolved for the SVG
images:
Added: LB_ISO_APPLICATION, LB_ISO_PUBLISHER and LB_LINUX_PACKAGES
Not added: LB_ISO_PREPARER: xorriso recommends not changing this
variable
Not added: LB_ISO_VOLUME: is can contain '@ISOVOLUME_TS@' which resolves
to a timestamp and would need additional handling
For reproducibly building live-images, it turns out that the initial
build does not necessarily have to use a snapshot server.
Within a time slot of 6 hours (the interval between synchronisations of
the Debian archive) the reproducibility of a live image can be checked
by running the rebuild.sh script twice. The resulting ISO files should
be identical.
Currently it's only supported in the chroot/binary phases. Omitting
bootstrap was an oversight.
Note that config/archives/*.conf are assumed to be apt.conf files,
so the apt_auth files are required to end with .auth and will be renamed
to .conf when copied into the chroot.
With this 'distribution', the installer is built from its git
repository, matching the date in SOURCE_DATE_EPOCH.
Additionally the kernel version is matched to the kernel version in the
chroot (to ensure that the installer can be run).
Rationale: The 'daily' installers are not archived, and therefore cannot
be used for a reproducible build.
The installer stage has a clean chroot for its own usage. The chroot
from the chroot stage is available in chroot/chroot (implemented similar
to the binary stage).
This makes the default value of --parent-debian-installer-distribution
the same as --debian-installer-distribution, like the other
--parent-distribution-* options.
The new includes.chroot system implemented in !214 adds the option
to include files in the chroot before and after package installation.
chroot_hostname and chroot_resolv have been updated but not chroot_hosts.
Gbp-Dch: Short
Persist LB_BOOTLOADERS in lb_binary_* configuration, since
Init_config_data called from lb_binary_* calls Prepare_config which
then overrides LB_BOOTLOADER_BIOS and LB_BOOTLOADER_EFI if
LB_ARCHITECTURE is amd64 or i386, and these can only be restored to
their proper values by the presence of LB_BOOTLOADERS.
This therefore ensures that the value of the "--bootloaders" parameter
to lb_config is respected by the lb_binary_* steps.
Allow APT_AUTH.CONF(5) config files to be used with archives.
Note that config/archives/*.conf are assumed to be apt.conf files,
so the apt_auth files are required to end with .auth and will be renamed
to .conf when copied into the chroot.
Closes: #991065
That prevents potential errors during future Remove_packages calls without APT indices available. In such cases, APT tries to remove packages with unrecognized names, which results in an error and fails the script execution. An example of this would be installing apt-utils in chroot_archives with --apt-indices option set to false.
Similar to iso images, the timestamp of a file/folder inside the binary
image cannot be newer than SOURCE_DATE_EPOCH.
Also set the timestamp of the hdd image.
This previously undocumented value for '--chroot-filesystem' creates the
uncompressed folder 'live/filesystem.dir'.
This will speed up the generation of live images a lot, because the
squashfs compression is skipped.
Example command line:
lb config -b hdd --chroot-filesystem plain --binary-filesystem ext4
The package might be missing when building with a minimal configuration,
as recommended in the Live Manual, the example 'Base image' scenario:
'lb config --apt-recommends false --debootstrap-options "--variant=minbase"'
Notes:
- No bootloader is configured; images must be booted via direct kernel
- Tested via qemu + opensbi fw_jump.elf + kernel/initrd
- As riscv64 is currently in ports, the following options are required:
--distribution unstable
--mirror-bootstrap http://ftp.ports.debian.org/debian-ports/
--security false
--debootstrap-options --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg
- Normally ports require stacking two dists, unstable and unreleased.
debootstrap does not support doing this, but as of this writing, there
is nothing in riscv64 unreleased which is required to bootstrap.
However, this would not have been possible a year ago.
There are two main scenarios:
1) The host with live-build is configured to use a proxy
This proxy will automatically be used by live-build
2) The user of live-build explicitly specifies a proxy
2A) With the environment variable 'http_proxy' (preferred)
2B) With the command line option --apt-http-proxy
Any inconsistency in the setting of a proxy results in an error message of 'lb config'
All internal tools (apt/apt-get/aptitude, wget and debootstrap) use the environment variables 'http_proxy' and 'no_proxy', which are passed along to the chroot where needed.
Test scenario:
- A virtual machine with all out-going traffic blocked, except for the proxy.
MR !173 removed the export of several variables moving/renaming them.
Continue to export both the new name and older compatibility name.
Closes: #992572
This adds support for dm-vertiy on the root filesystem.
Currently only squashfs is supported.
Three new flags are introduced.
* --dm-verity: Enable basic dm-verity support
* --dm-verity-fec NB_ROOTS: Enable forward error correction. Optional
* --dm-verity-sign SCRIPT: Specify signing script for the root hash. Optional
1) lb config rejected multiple checksum types
2) When using the installer, cdrom-checker requires a md5 checksum file,
use 'Check the integrity of the installation media' in the installer
3) The comments in the first lines of the checksum files caused
cdrom-checker to fail the integrity of the image
If grub/splash.png exists, assume the configuration editor intends
to have a grub-specific splash.png, and do not modify theme.txt.
But if syslinux has the only known splash.png, use it for both
syslinux and grub.
(This allows for a hybrid image where the grub side can have e.g. a
16:9 1920x1080 splash.png which gets grub is capable of automatically
scaling, while the syslinux side has a 640x480 splash.png which
effectively must be this fixed size.)
When a package lists contains only packages protected by a test
that doesn't match for the current run, then Expand_package_list
outputs nothing and the following "grep -v" fails because it
has not filtered anything. Avoid this by protecting the "grep -v"
call with "|| true".
Before commit 9f3e5fe8d (Fix the way the .disk/mkisofs file is created)
all these commands (`mkdir`, write to `binary/.disk/mkisofs` and
`xorriso`) were in the same `binary.sh` script. Since that commit, the
write was extracted, to prevent issues with quoting, but the related
mkdir was left in `binary.sh`. This means that the write is now executed
first, and the `mkdir` only afterwards, making the `mkdir` quite pointless.
In practice, this did not break becaue binary_disk also does the same
`mkdir` and runs before `binary_iso`, but if one runs commands manually
and skips `binary_iso`, then this does break.
Even though this is not really a supported usecase, just move the mkdir
outside of `binary.sh`, so it runs *before* the write again as intended.
Moved includes.chroot to includes.chroot_after_packages and added
includes.chroot_before_packages. includes.chroot does still work as before.
We also now use rsync for copying files if it is installed.
This improves runtime and space consumption for large includes.
Gbp-Dch: Short
Closes: #927128
Installation of flatpaks doesn't work with normal chroots.
This patch enables support for using systemd-nspawn in hooks.
Gbp-Dch: Short
Closes: #965953
avoids spitting out warning
> [2020-06-07 22:30:32] lb binary_grub-efi
> P: Begin preparing Grub based EFI support...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Package grub-efi-amd64-signed is not available, but is referred to by another package.
> This may mean that the package is missing, has been obsoleted, or
> is only available from another source
>
> E: Package 'grub-efi-amd64-signed' has no installation candidate
> W: UEFI Secure Boot disabled due to missing signed Grub/Shim.
We want to be resilient to small network hiccups and when you download
a large number of packages, the probability of a network hiccup are
increasing... as are the chances of hitting one of the apt bugs
(cf "Undetermined error"...).
this simplifies things to avoid the messy recursion.
it is also a necessary step to implementing handling of common options
like --debug. we need to process all options to decide how to approach
doing things (e.g. with debug messages to be output or not) before actually
performing any work, in order for options like --debug to be reacted to
properly.
also, as things were, options like `--debug` were not being passed along
in the recursive executions, while now that is no longer an issue.
the order of file/folder deletions for `--all`|`--purge`|`--remove`
actions is slightly changed here, but i don't see any issue with that and
it's cleaner to not preserve that.
Gbp-Dch: Short
per layout from MR #199 discussion.
under "Advanced install options" we have:
- Graphical installer
- Text installer
- Graphical installer with dark theme
- Text installer with dark theme
- Installer with speech synthesis
under each of these we have a set of:
- Install
- Expert install
- Automated install
- Rescue mode
note that the 'automated' entries are moved up before the 'rescue' entries.
for hotkeys, the four entries above have hotkeys of 'i', 'x', 'a', and 'r'
respectively. ('x' is used instead of 'e' to avoid clash with standard
grub hotkey). this means that some entries that previous had no hotkeys
due to the flat list now have them. the other big difference is the main
graphical install entry going from 'g' to 'i' for consistency and the main
speech synth entry going from 's' to 'i' for the same reason.
furthermore, in the level above we have 'g' for normal graphical, 't' for
normal text install, 's' for speech synth, 'd' for graphical dark mode,
and 'k' for text dark mode.
the text-only sets are identical to the graphical ones except only for
dropping the graphical groups, simplifying maintenance, bringing clarity
to users of images (who may not have even made the image) that the set is
text-only, and keeping consistent hotkeys between graphical and text-only.
a 'start installer with speech synthesis' entry shortcut has been placed
at the top menu level alongside the 'start installer' shortcut.
Gbp-Dch: Short
following the presence of them in the official install discs.
also drops unnecessary word "graphical" from existing speech
synth entry, following official Debian install discs.
i've not bothered to update grub-legacy this time.
Gbp-Dch: Short
This reverts commit 665372c19d.
the kali test failed due to their script using a hack of passing along a
custom option after an early terminator through to their auto/config file.
the change implemented here was valuable, but i'll have to look into
revising things to work with what Kali is doing.
Gbp-Dch: Ignore
some scripts temporarily install packages to accomplish some work before
then removing them. the list of packages installed is kept in memory in a
variable.
a weakness of this design is that if a failure occurs or the user cancels,
and then following this the user re-runs `lb build`, letting it try to
pick up and recover from where it left off, that list of packages that had
been installed is lost, resulting in those packages that were installed
then being a permanent part of the chroot.
here we fix this weakness by backing up the list to a file, which is always
read from on removal. thus in a recovery situation, any packages still
installed from a situation like that just described, will be removed upon
the next use of `Remove_package()`.
this is not perfect, since we are having to wait for opportunistic
execution of the remove function. we need to find a suitable place for the
`Cleanup_temp_packages()` function to be used.
- doing so in `Init_config_data()` would not be suitable because we don't
hold the lock when that's run, even if we ignored the hijacking of that
function for taking such action...
- doing it in `Exit()` doesn't seem a good fit either.
- putting it explicitly in every build script just seems a little messy...
perhaps a local exit trap like for removing the lock...?
note that `binary_rootfs` skips running the remove function after installing
tooling, since it just throws the wrapper chroot away, which then leaves the
file around with stale data for the next remove instance to pick up, which
then does not actually remove it because it's not installed. this is not
ideal either... perhaps the optimisation should be removed from that script?
Gbp-Dch: Short
after handling arguments, catch and report any remaining "non-option"
arguments.
for instance users could make the basic mistake of using
`lb config --bootloaders syslinux grub-efi`, i.e. failing to quote the
multiple bootloaders (i actually encountered a user doing this who swore
that "it just worked"). catching and reporting such mistakes could be
valuable to users.
previous behaviour:
```
$ lb config --bootloaders syslinux grub-efi
P: Updating config tree for a debian/buster/amd64 system
P: Symlinking hooks...
```
new behaviour:
```
$ lb config --bootloaders syslinux grub-efi
[2020-05-05 18:56:07] lb config --bootloaders syslinux grub-efi
E: Unexpected argument found: grub-efi
```
Gbp-Dch: Short
debootstrap must obviously exist in the host. we thus must pass 'host'
not 'chroot' such that a warning about needing to install it on your host
system is output, rather than it being added to a list of packages to be
installed, which never occurs in this script.
Gbp-Dch: Ignore
- the comparison with LB_ARCHITECTURE seems to be based upon an old idea
of it potentially being intended in the past to hold more than one
arch (when it's name as also plural), but it in fact only holds one.
- similarly LB_BOOTSTRAP_QEMU_ARCHITECTURE is singular, so the comparison
with the set of params is bad.
- storing $@ in a variable before then looping is not a good idea
- script name was not being passed to the warnings
- can simplify by just returning in the valid case
i'm very suspicious about the correctness of the qemu bits, but that
can wait for now.
Gbp-Dch: Short
when loopback support was introduced, it initially duplicated the code
for generating a grub2 config, before the duplicated code was removed from
the grub-pc script, effectively thus moving grub config generation to the
loopback feature script.
grub-efi support was added after this.
this results in a misleading filename, since the `binary_loopback_cfg`
script is essential for use of grub-pc|grub-efi, and actually only has a
single line of code on top that's needed for adding actual loopback
support on top. (when grub-pc and grub-efi are not used, the entire script
is still needed for loopback support to work).
so here we rename it to make better sense, and correct/clarify bits of
documentation.
Gbp-Dch: Short
with LB_BOOTLOADER_BIOS and LB_BOOTLOADER_EFI introduced, we can simplify
and correct things here.
previously it was possible for more than one of each type to be added.
Gbp-Dch: Short
the design choice from when EFI support was introduced was to change
`--bootloader` to `--bootloaders`, with users specifying their selection
of BIOS and EFI bootloaders together. at this time there were not even any
decent validation checks being performed, and invalid combinations could
cause some chaos.
since then proper validation was put in place, including checking that
only a single instance of each of BIOS and EFI bootloaders exists in the
selection.
here we tweak things such that we stick with the same option, but we split
the selection up such that we store the BIOS and EFI selections separately
within the saved config file, and offer it up to scripts to help simplify
those scripts.
we must however retain support for splitting from the combined option,
both because we still use it in the combined option, and for backwards
compatibility with older saved configs.
Gbp-Dch: Short
thus far, config bootloader validation only did the basic check that each
bootloader specified was a known and supported bootloader, it did not check
combinations.
it now checks combinations, and strips out the previous "bootloader role"
stuff.
the no-bootloaders warning is duplicated, covering two slightly different
situations (empty string, and whitespace string). this is anticipated to
be just temporary, with this just being the first step in better handling
bootloader selections.
Gbp-Dch: Short
"grub" presumably was what is now called "grub-legacy"
removed both because there is already a proper piece of code adding
bootloader packages.
Gbp-Dch: Ignore
The core purpose of `Prepare_config()` is to prepare the config by setting
defaults where not specified. It should not be involved itself in
validation of user options.
This can be an important distinction, for instance in `clean` where we
use this function, but avoid validation to potentially allow for an option
that deletes the config, that should work even in the face of an invalid
config.
Gbp-Dch: Ignore
while `lb build` ran the config validation check, spotting invalid configs
and stopping with an error, the major build stages if executed directly did
not, nor did the component stages.
here we move execution of the validation function into the common init
function, with an exported variable used to indicate that validation has
been performed. thus validation is performed no matter what part of the
build system you execute, but only once.
Gbp-Dch: Short
`Init_config_data` is more suited to build scripts than here. note that
it's not used in `config` either. this deliberately does not pass along
arguments to it because `Arguments()` can only handle the basic common
options, not the `clean` set. this is somewhat confusing and causes a
pointless execution of `getopt`. furthermore the function is expanding
slightly further beyond it's original scope, with yet more change coming
that's unsuitable for `clean`, so it makes sense to avoid using the
function here just for the couple of function calls needed.
validation of the config is disabled, as it is not performed currently.
it is not clear if it should be enabled or not for `clean`. it may be
useful to not validate, if we wish to be able to provide users with an
option to be able to delete the config.
Gbp-Dch: Ignore
using `$VERSION` as part of the default `$LB_ISO_PREPARER` means that when
you simply run `lb config` once, this variable is stored as a part of the
string, and replaced on use, but if you run `lb config` twice, it gets
replaced with a fixed version, that is then used in all subsequent builds.
let's replace with a placeholder (`@LB_VERSION@`) that can be used both in
the default, or in user strings, and will be replaced on use only.
this means that subsequent builds will always reflect the actual version
of live-build used.
Gbp-Dch: Ignore
`DATE_UTC_OPTION` is set in `Prepare_config()` for use by scripts, even
though only a few scripts will actually use it, since it allows those
scripts to be cleaner. we may want to possibly extend this as a
`DATE_OPTIONS` variable perhaps as part of enabling proper reproduciblity.
Gbp-Dch: Short
since date is not obtained as UTC, timezone is an important detail of
understanding the given time, which users may want to make use of.
Gbp-Dch: Short
don't construct each part from a fresh "now", which can result in
inaccuracies in the overall date due to "now" drifting over the individual
date calls. instead feed the full date that was obtained back into it when
extracting the component parts.
Gbp-Dch: Ignore
- the definition of $PROGRAM as used in $USAGE strings defined in each
script has been broken for a long time, being simply "lb" when it needs
to be "lb COMMAND".
- `config` changed $PROGRAM to "lb config" thus its output was correct in
this regard unlike everything else, but with the switch to a more
"intelligent" `Man()` function recently, it means that instead of
`man lb config`, what was actually run was `man lb config config`,
which displayed the manpage, then on exiting with `q`, it showed some
sort of index line todo with a "config" search (no exact manpage
match?), for which you had to enter `ctrl+c` to get rid of.
this revises things to fix the issues, minimising change by changing
$PROGRAM to "lb COMMAND", with the frontend overriding this.
Gbp-Dch: Ignore
did not properly consider all usage cases properly in deciding placement.
this captured `--usage` in `$PROGRAM --usage` as the action for instance.
Gbp-Dch: Ignore
load the base set of files first, then any user arch/dist specific override
files second.
this is important since whenever config items get moved in the base files,
this can break the override files, if an option specified in one was moved
to a different common file that it loaded after.
Gbp-Dch: Ignore
these should be bypassing the possibility of running the auto script
surely, just like how this is done for `--all`, otherwise you pass through
the auto file twice.
Gbp-Dch: Ignore
- detect lack of options using actual arg count rather than first arg
being an empty string.
- fix string splitting issues by looping properly on "${@}"
- tidier
Gbp-Dch: Ignore
...alongside printing usage (which is perhaps unnecessary), so that it is
actually clear to users that a problem occurred, and what.
and capture it before option processing of remaining args.
Gbp-Dch: Ignore
- it's only used by the debootstrap script after alternatives were dropped
long ago, so let's move it, avoiding it being loaded for everything
else.
- there's no need to pass printing another message through it.
- there's little point in making the sid distinction if you happen to
decide to build sid, it's a given that it's less stable than stable.
really, is there any need for this at all?
Gbp-Dch: Ignore
the default grub config has a quirk of using the syslinux splash when
present, which as a sidenote i believe is because only the syslinux script
has the code for converting an SVG (i've not researched to confirm).
the problem is that the default splash is such, with the text listing
package versions used, that this overlaps with the menu title in grub.
i've tweaked the "built on" and package details text to reduce its size
(bumped the line-height up slightly though) to avoid the overlap.
this was a pain in the *** to get done. inkscape likes to crash at the
slightest little thing like clicking on interface controls; each time it
saves it seems to swap a bunch of stuff in the file which can make a
hugely messy diff, i had to save, close, open, change, undo, and save
again, just to get a sain diff; and numerous times testing different sizes
and such in actual builds (rather than separate conversions) some of the
package detail lines would for some unknown reason decide to end up on the
same line as another, wth...
anyway, i've finally managed to get a new revision successfully created
and it seems bug free wrt. that same line issue to me, both converting
outside of live-build (in my sid host), and within a buster build. the size
of the text changed seems closer to the size of the actual menu entries
(there's no need for it to be bigger), and now is nicely clear of the menu
title.
Gbp-Dch: Short
opening the file in inkscape resulted in a dialog explaining that inkscape
used to work on a 90 DPI basis but switched to 96 DPI for better
compatibility reasons, and wanted to convert the file.
this is simply the result of it having done the conversion.
it advised that for documents not intended to be printed that there should
be no noticeable difference. i checked the output and it seems identical
to before. i tried to look at the actual diff, but it's a lot of noise,
most of which is just reordering, and i gave up, since the output looks
identical i'm not going to worry.
Gbp-Dch: Ignore
in tweaking a previous commit to remove some excessive change before
submission, i mistakenly identified the part of the sed replacement
restored here as being unnecessary to its functionality, but in fact it is.
without it the placeholder is not actually removed.
the lack of removal of the placeholder meant that you ended up with
duplicate copies of the live menu entries.
Gbp-Dch: Ignore
more fitting now that we've moved the advanced installer entries
out to a different submenu, leaving just memtest (and HDT on
syslinux).
the advanced.cfg file is also renamed to utilities.cfg in the syslinux
case, but in a backwards compatible way of moving the user advanced.cfg
file over the new one, if the user provides a file with the old name.
alternatively we could just leave the old name in place, but that would be
a little odd.
Gbp-Dch: Short
- most entries used vga=788 rather than vga=normal (which are equivalent)
- the syslinux menu uses 788 exclusively
- so do the official install discs
Gbp-Dch: Short
This is considered to be more robust.
Two instances remain:
scripts/build/chroot_archives, line 257:
if [ "${LB_APT}" = "aptitude" ] && [ ! $(Chroot chroot "which aptitude") ]
The command is run inside a chroot where the environment might be special,
and would need further testing.
manpages/Makefile, line 42:
@if [ ! -x "$$(which po4a 2>/dev/null)" ]; \
I am insufficiently familiar with makefile syntax to edit this.
instead of cramming the live entries into a string via a layer of functions
for terminating entries with newlines, which we then have to run through
perl to tweak the newlines for correct use with sed... let's write the
entries to a temp file, then use that file in the sed replacement.
the helper functions injecting newlines to the end of entries as they were
built into a long string have obviously become unnecessary and so were
removed. one function was renamed for reasons of consistency and clarity.
the file is initially deleted before use for reasons of wanting to bullet
proof the codebase to work properly under conditions of recovering from
failure/cancellation, `--force` re-running and such.
this removes the last use of perl.
Gbp-Dch: Short
support for this has not existed since v2.0~a24-1 !!
until 4d22ca948a (v2.0~a24-1), `PROGRAM` was
defined as `PROGRAM="$(basename ${0})"`. then this commit simply got rid
of the definition.
it then flipped back and forth a bit in a few ways, but always sticking
to a simple fixed "live-build" type string after that commit, as it has
been ever since.
the code removed here has thus been junk since then, and the documentation
corrected here out of date since then.
the checking of `LB_CONFIG` is also possibly junk, but i know too little
about it. it was introduced in v1.0~a43-1 in commit
705a4178e7 with a changelog entry of
"Centraly evaluate LH_CONFIG for custom configuration file."
Gbp-Dch: Short
it reported: "possible bashism in scripts/build/binary_loopback_cfg line 284 (should be '.', not 'source')"
which is clearly a misidentification.
Gbp-Dch: Ignore
also enables greater flexibility for users to override more aspects of
theme separate from menu entries, and similarly the initial config details
separate from the menu entries. (with the recent change to merge user files
with the defaults rather than replace them, users can pick which of these
individual components they wish to customise.
identical to change as sent in to Kali and accepted by Raphaël.
Gbp-Dch: Short
partly lost in some adjustments that were made to the submitted work,
which was focused on restoring the 'start installer' entry.
there is no need for dynamic setting of these two `source` imports in the
default file, in fact user modifications should also use the fixed import
commands in future.
note that the old placeholders however remain replaced, which inject
precisely this string, for backwards compatibility.
Gbp-Dch: Ignore
during testing i encountered an unexpected error resulting from the
following condition:
- bootstrap was cached
- cache of bootstrap packages was empty (from playing with `lb clean`)
- installer was not none|live
everything works fine up until the main installer script, which comes to
an abrupt halt with an error due to the missing cached bootstrap packages
that it wants to copy.
this situation is easy to unintentionally create, as i managed to do.
here we catch the failure condition, correcting for it.
this is done by checking for the missing cached packages when restoring
the bootstrap from the cache, and skipping this if the packages were
missing, thus forcing the bootstrap to be rebuilt. the packages should
then be found within the cache, allowing the installer stage to complete
successfully.
of course the bootstrap stage will only cache the packages if caching is
enabled, but if caching is disabled and installer enabled, the config
validation will catch that, reporting that problem.
Gbp-Dch: Short
install mode was silent when selinux was not enabled, whilst remove mode
always output a "Begin unmounting..." message. this makes both modes silent
when selinux is not enabled.
this also happens to fix an unintended side effect of
d79c96232b whereby a warning subsequently
was always emitted in remove mode when selinux was not in use, which was
not ideal.
Gbp-Dch: Short
not worth listing the specifics
mostly the following though:
- "(comma or space separated)" -> "(a comma or space separated list)"
- quoting values
Gbp-Dch: Ignore
The unconditional SVG to PNG conversion could overwrite a splash.png
provided by the user. Ensure we don't overwrite such a file. But we
still remove the SVG file as syslinux is not able to make use of it.
there are several files of which identical duplicate copies are held in:
- share/bootloaders/extlinux
- share/bootloaders/pxelinux
- share/bootloaders/isolinux
- share/bootloaders/syslinux
it is a pain to maintain this from a development standpoint, having to
copy modified config files into the other directories each time changes
are made and mistakes have been made before due to this.
this creates a new folder share/bootloaders/syslinux_common and moves them
to this new directory.
it also expands the binary_syslinux stage to use it, with it now
constructing the installed set of bootloader files as follows:
1. copy {LB_DIR}/bootloaders/syslinux_common
2. copy {LB_DIR}/bootloaders/{syslinux|isolinux|extlinux|pxelinux} on top
3. copy config/bootloaders/syslinux_common on top
4. copy config/bootloaders/{syslinux|isolinux|extlinux|pxelinux} on top
note, to explain part of the binary_syslinux change, instead of just
copying the correct bootloader folder full of the files, we now make the
target bootloader specific directory, then copy the contents of source
directories into it.
Gbp-Dch: Short
* Use same menu labels
* Use same hotkeys
* Get rid of a nested menu that is not present in grub
* Add "menu title" statement to hide the caret of the hotkey (^)
0bf9d2d390 expanded the set of install
options, whilst also moving them all to a submenu.
it has since been raised that this is not actually what is wanted, that
having an entry for the most common install option is wanted at the top
level, like currently with grub2.
this adds such an entry.
Gbp-Dch: Short
Due to this mistake, the helpers were not called in reverse order
during the removal step. This lead to things like "apt update" failing
because a broken /etc/resolv.conf has been restored before the call
to "chroot_archives remove".
Gbp-Dch: Ignore
for some reason the syslinux folder one had these but not the others.
probably a result of having four separate copies of the files and this
part of the past change to expand the install menus failed to be
duplicated.
Gbp-Dch: Short
This is a recipe for disaster and it actually already fails when
you pass something that looks like a long option as first argument
because $(which --long-option) will produce an "Illegal option"
string on its standard output.
$ lb --debug config --archive-areas "main contrib non-free"
Illegal option --
/usr/bin/lb: 54: [: Usage:: unexpected operator
E: Unknown command: --debug
introduced by an issue with the implementation of
91d446d93e
the introduced of that commit caused builds to fail doing `apt-get update`
or downloading packages and such.
this tweak fixes the problem.
Gbp-Dch: Ignore
just as most scripts are skipped if their stagefile exists (indicating
that they have already been run to completion), including chroot
preparation scripts in install mode, this implements the same guard for
chroot prep remove mode, such that they exit early if their stagefile
does not exist, indicating that the modification has already been removed.
(also override-able by --force in the same way).
this basically just uses a tweaked copy of Check_stagefile().
Gbp-Dch: Short
no backwards compatibility hack for reading the old var from existing
saved config used because this was previously stored in the alternate
format config/build file.
Gbp-Dch: Short
no backwards compatibility hack for reading the old var from existing
saved config used because this was previously stored in the alternate
format config/build file.
Gbp-Dch: Short
back in v4.0~a6-1 a transition process was started to move the live-build
config to a new format. the new format was INI style, and required
parsing functions to read/write values, compared to the existing format
which was just shell script code setting variables.
this partial transition is the explanation for the existence of the
`New_configuration()` function, and understanding this is important to
understanding the purpose of it - it is not in fact intended for creating
a new configuration, it is just related to the new config format
transition.
the positives of the new format were that it was somewhat cleaner looking,
while the negative was the terrible relative efficiency.
the file `config/build` was created to hold options in this new format.
the transition was only ever completed for a handful of config options:
- architecture
- archive areas and parent archive areas
- live image name
- live image type
a 'configuration version' attribute was also saved, which is not used by
anything.
the bootstrap-mirror and parent-bootstrap-mirror attributes are pointlessly
stored in it seemingly resulting from work done in v4.0~a17-1. (they are
also stored in another config file from which the value is actually used).
it in fact seems to have been a source of confusion for Raphaël in
authoring 44b9b0a650, since the new
`[parent]-distribution-{chroot|binary}` options it introduced were stored
both in `config/bootstrap` and in `config/build`, while only used from the
former. i expect, understandably, that he thought that `config/build` was
just an information file.
Gbp-Dch: Short
the grub-pc image creation code has no business being in binary_iso, it
should be in binary_grub-pc.
it should be noted that the binary_iso script did not even have the
necessary package check for grub-mkimage, while binary_grub-pc did have
it, pointlessly.
Gbp-Dch: Short
This fixes cryptsetup modules not being installed into initrd with warning:
> cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries
> nor crypto modules. If that's on purpose, you may want to uninstall the
> 'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs
> integration and avoid this warning.
Thanks-to: Marcel Partap
live-build might be run from a local folder rather than the system
installation, so the dpkg version number should not override the version
picked up from VERSION
if we care about the possibility of the installed package version
potentially differing from the version of the git checkout, or
whatever, then this should be printed alongside it, as now done.
Gbp-Dch: Ignore
[Raphaël Hertzog: tweak to apply on top of my changes]
thus it can correctly indicate success/fail status instead of always
indicating failure. when a user asks for usage with -u|--usage then we
should exit in success mode rather than failure as when usage in printed
in response to incorrect usage.
Gbp-Dch: Short
this means that the usage goes from:
lb {-h|--help|-u|--usage|-v|--version}
lb COMMAND [OPTIONS]
to:
lb {-h|--help|-u|--usage|-v|--version}
lb [FRONTEND_OPTIONS] COMMAND [COMMAND_OPTIONS]
though it is probably not worth is to update the description in the
manpages...? hmm...
so for instance this matters for color control with --color|--no-color
(you already had full control via environment vars). previously you could
do `lb COMMAND --no-color` to turn off colour, only to find that output
at the frontend level was still coloured (the option is processed at the
command context level, not the frontend), so you might try to instead use
`lb --no-color COMMAND`, only to find that this was not supported. Well
now it is, and used at the frontend level will fully control colour output
(after the command is processed anyway).
the full set of common options are thus available (except --force) at the
frontend level, and thus for instance all Echo_*() helpers used in the
frontend will work correctly after args are processed.
furthermore usage like `lb --color --help` will actually work. (not that
color is used there, but this previously would have failed with the
frontend treating the `--color` argument as the command; that's the point!)
Gbp-Dch: Short
as far as the user is concerned, 'foo' in `lb foo` is a command; they do
not know or need to know that the commands also correspond to actual
scripts.
Gbp-Dch: Short
this was previously not done in 8b109ffb96
to keep the renaming simple, but leaving the variable plural is a cause
for confusion.
since this property is stored in the INI style config/build config file
rather than a shell script based one, at the property there is already
singular, there was no need for a backwards compatibility hack.
Gbp-Dch: Short
being done in Prepare_config() meant that it would get saved into the
config stored on disk which is not what was intended.
being saved on disk is not a big problem, since the injection of the
dynamically determined option is always done on top of the value read
from the saved config anyway, so you'd always end up with two copies of
the option given to apt, the first being from the saved config, the second
being the more correct dynamically determined one, overriding the first.
so there is no functional change here, just better achieving what was
intended.
Gbp-Dch: Ignore
note that the bit of code removed from source_debian relies upon a
variable LB_TASKS which itself is an old leftover artefact from before
v4.0.
Gbp-Dch: Short
since everywhere where 'apt' is a permitted value, 'apt-get' is also, it
just wasn't listed in the option's documentation and thus was also not
listed in the new validation check.
Gbp-Dch: Short
80aa5ab611 implemented a hack to handle
replacement of LB_LINUX_FLAVOURS with LB_LINUX_FLAVOURS_WITH_ARCH in
config files, but implemented it in the wrong place.
adding a conditional conversion within the config file meant that the old
value would only be read from **new** config files that are created
obviously without it, including re-saved configs if `lb config` were
re-run with additional options (not recommended). any existing value in an
existing config file would actually be ignored.
the right place to read the old value was in the Set_defaults() function
(since renamed).
a second issue also existed with the hack, it failed to excape the `$`
and thus printed the existing value of $LB_LINUX_FLAVOURS into the
conditional check being constructed in the config file, instead of
printing the name of the variable. the check embedded into the config
file thus became this on an amd64 machine:
```
if [ -n "amd64" ]
then
LB_LINUX_FLAVOURS_WITH_ARCH="amd64"
fi
```
which is clearly not what was intended.
Gbp-Dch: Short
while helpful for users to know the defaults, the values printed as the
supposed defaults for most are actually the same values as being
configured, or in some cases a piece of text "autodetected or empty", and
thus the information is completely wrong and actually unhelpful since it
misinforms the user.
fixing this to give the real defaults is very much non-trivial.
as a workaround users wanting to know the default for an option can always:
a. use `lb config` wit no options (or auto) in a clean directory and thus
get a config with all defaults.
b. look at the live-build code.
if they just want to reset an option, they can also just comment it out.
Gbp-Dch: Short
Closes: #904614
(and move the wget options setting down where it should be while at it)
the value of LB_DEBIAN_INSTALLER is now properly checked in the main
validation routine, so we can just directly exit here as a simple safety
check should validation be bypassed.
Gbp-Dch: Short
- add a validation check where an error will be printed
- replace the check done in the grub scripts with one that simple exits
if executed bypassing the validation check
Gbp-Dch: Short
the stuff in defaults.sh is only partially to do with setting default
config values, it also does other prep work like centralised comma
separated value to space separated conversion, and validation.
this is split into two parts to keep the diff simple, first we move the
two small functions from configuration.sh into default.sh...
Gbp-Dch: Short
move away from the somewhat config file grouping based organisation to
an alphabetised list, after grouping into script-specific; general;
build-specific and other.
the config file based organisation was a bad choice, making it hard to
find the right place to insert options for instance.
Gbp-Dch: Short
running `lb config --validate` causes the script to stop after running
the validation check on the config compiled at that point, prior to
writing the config to disk.
this gives users the ability to check the validity of a config without
modifying or rewriting the saved config.
note that if users provide new config options alongside --validate, these
are taken into account in the check performed.
the 'check complete' message will not be seen if an error is reported by
the check function, while it will be seen if only warnings are given, but
it would require a redesign of the validation check function to make any
improvement in that area, and it's perhaps not worth it.
Gbp-Dch: Short
it mostly applies defaults where a value does not exist, but does more in
some cases. the new name better reflects its usage and functionality.
Gbp-Dch: Short
whilst some parts of the codebase were set up to work with multiple types
specified, others did not work with it and would not necessarily be easy
to adjust. this thus makes some tweaks to adjust things accordingly.
- option renamed to singular form (maintaining backwards compatibility)
- a validation check has been added
- unnecessary glob style type references fixed
- checks with In_list changed to a direct singular comparison
- typo of type "netboot" written as just "net" fixed (though unreachable
so of no consequence; really the code could be removed but it's trivial)
Gbp-Dch: Short
this option actually only has an impact when used for `lb config`; it thus
was incorrectly accepted and captured by Arguments() and the documentation
was wrong.
going back through git history, this has been incorrect since the v0.99 days.
also, reorganised the list alphabetically (no-color was inserted in the
wrong place).
Gbp-Dch: Short
live-build page: list of individual commands outdated (color options not
added); incorrect (conffile is `lb config` specific as to be addressed
otherwise separately); is unnecessary here; and the synopsis suggests
usage without a command (e.g. `lb --help` is wrong when it is not).
lb: consistensy fix in formatting.
all: placeholders should be in capitals for consistency; "OPTIONS" is
better the "live-build options" as a placeholder.
config: unlike the others where "live-build options" is replaced with
"OPTIONS", it makes more sense to specifically list the info (help; usage;
version} options, since below the full list of other options including
other generic options are given.
Gbp-Dch: Short
two parts of the code worked with both comma and space separated lists,
while two others only worked with comma separated.
swapping out commas with spaces when we setup the var in
Set_config_defaults() means that individual scripts no longer need to worry
about it and everything supports both; and that we can avoid the
IFS/OLDIFS mess.
Gbp-Dch: Short
the bootloader list should be comma separated not space. i do not know
what possessed me to write space based in
aed4e0fef2.
fix "booloader" typo while at it.
Gbp-Dch: Ignore
the environment variables when held in a variable need to be used via
`env` otherwise you get command not found errors.
example:
```
$ echo "AA=aa" > config/environment
$ lb config
/usr/bin/lb: 83: AA=aa: not found
$ ENV="AA=aa"
$ ${ENV} true
bash: AA=aa: command not found
$ "${ENV}" true
bash: AA=aa: command not found
$ env ${ENV} true
```
Gbp-Dch: Short
to protect against simple mistake of using 'all' instead of
'all-except-archives' when manually executing scripts (e.g. during
development) at the bootstrap stage level. (the bootstrap stage does not
and should not use the archives helper).
Gbp-Dch: Ignore
it now covers:
- `lb chroot_apt install-binary`
- `lb chroot_archives {chroot|binary|source} {install|remove}`
by expanding usage from:
`lb chroot_prep {install|remove} HELPERS [ARGS]`
to:
`lb chroot_prep {install|remove} HELPERS [MODE[ MODE..]] [ARGS]`
where `[MODE[ MODE..]]` is an optional set of one or more of:
- archives-chroot, which specifies to use 'chroot' as the first param to
the chroot_archives script
- archives-binary, which specifies to use 'binary'
- archives-source, which specifies to use 'source'
- apt-install-binary, which specified to pass 'install-binary' instead of
'install' to chroot_apt
thus _all_ chroot prep scripts can be run through this helper now!
note, in the case of the binary stage, 'archives' is deliberately not added
to CHROOT_PREP_OTHER, this is not a mistake!
Gbp-Dch: Short
rather than explicitly running one helper after another in the major
build stages, or by hand (e.g. while testing things during development),
they can be run in bulk via this new helper. it essentially just takes a
list of helpers to run and runs them one by one.
it supports running all helpers except chroot_archives because that one
has different parameter requirements to the rest and supporting it would
make things messier.
helper scripts can either be named by their full script name or without
the 'chroot_' prefix for brevity. you can also just specify 'all' to
refer to all helpers (except chroot_archives, per above).
it automatically reverses the order of the list when run in remove mode.
Gbp-Dch: Short
it was not run in install mode so should not be run in remove mode.
(whether it should in fact be run in install mode is another question; as
is whether chroot_tmpfs should be being used)
Gbp-Dch: Short
i've been noticing that in the binary_syslinux stage a wholebunch of
packages get installed whilst installing isolinux, and then upon removing
the installed packages at the end of the script, apt is listing a large
number of those that were auto installed as no longer in use and can be
removed via `apt autoremove`. this then persists through package
installation and removal steps throughout remaining scripts.
adding `--auto-remove` to `apt-get remove --purge` and similarly
`--purge-unused` to `aptitude purge` instructs apt to get rid of the unused
auto-installed packages at the same time as removing specific package that
brought them in in the first place, and thus resolves the problem.
Gbp-Dch: Short
when used alongside syslinux and when a single kernel flavour is used,
things work correctly. otherwise booting from EFI is broken.
the problem comes from the fact that syslinux, for a single kernel flavour
creates the file /live/vmlinuz, which is used by the minimal EFI grub.cfg
to locate the device and partition containing the live image. when multiple
kernel flavours are used, it instead creates /live/vmlinuz1, /live/vmlinuz2,
etc. which thus is a problem. similarly when syslinux is not used, you are
left only with long filenames for the kernel files, for example
/live/vmlinuz-4.19.0-8-amd64. in these situations grub cannot find the
device containing the image and thus fails to display the boot menu.
the solution here, instead of dynamically changing the filename searched
for depending upon bootloader configuration, switches to doing a search for
the file /.disk/info instead. this file is generated by binary_disk, and
is present for iso, iso-hybrid and hdd images types, though grub-efi cannot
be used for the hdd type. it is not created for the netboot type, but again,
grub-efi is not compatible with that anyway. it is not created for the tar
type, which the grub-efi script does not block as incompatible, but is this
not a mistake?
furthermore, switching to searching for /.disk/info helps avoid issues for
systems that happen to actually include a real /live/vmlinuz path other
than on a removable live disk or CD/DVD, as is the case with a HP system
discussed in #924053.
this patch was written by adrian15sgd@gmail.com, as per the authorship,
who attached it to the #924053 bug discussion. this commit message however
has been re-written by jnqnfe@gmail.com, prior to submission via an MR,
as part of the fix towards the issues reported in #956131.
Gbp-Dch: Short
Closes: #924053
don't include the advanced menu at all if it's only entry - memtest - is
not included (you just get a menu entry that does nothing, which may
confused users into thinking that something is broken, as opposed to
showing an empty submenu as i expected).
Gbp-Dch: Short
backwards compatibility:
1. the new file will be included alongside any user custom config
2. rather than replace MEMTEST with an actual config entry, we replace it
with a line to import the content of the new file, and thus will work
just as before.
thus no backwards compatible breakage
Gbp-Dch: Short
backwards compatibility:
1. the new install.cfg and install_start.cfg files (chosen
automatically from the install_*gui.cfg and install_*test.cfg
files) will be included alongside any user custom config.
2. the placeholders are now replaced with lines importing these files
thus everything will work just as before, i.e. no backwards
compatibility breakage.
Gbp-Dch: Short
as just done for grub2|loopback
the primary benefit here is that it means that user configs do not
have to carry copies of all files; they just carry the ones they
want to replace (or add).
Gbp-Dch: Short
`$_SOURCE` is always composed of `<foo>/${_BOOTLOADER}`, so we can just use
`${_BOOTLOADER}` as the basename, without calling `basename ${_SOURCE}`
Gbp-Dch: Ignore
...rather than choosing between the default set and a user provided set
1. ensures backwards compatibility after we switch from generation of
certain content to that content being in pre-prepared config files,
and thus no longer writing that config out to existing files.
2. means that user configs do not have to carry copies of all files; they
just carry the ones they want to replace (or add).
Gbp-Dch: Short
this takes a step forward in moving towards the same updated layout as
with syslinux; here we get:
- <live entries>
- Start installer
- Advanced install options...
- <full set of install options>
- Advanced options...
- Memory Diagnostic Tool (memtest86[+])
note that this only affects the default menu. custom configs are not
affected by this change.
further steps to complete the move to the updated layout will follow
later.
"Advanced options..." should perhaps be renamed later.
Gbp-Dch: Short
an official current debian install disc was compared with to achieve
better consistency.
main menu:
- i: for the single "start" entry
advanced submenu:
- g: for the main graphical entry
- i: for the main text-based entry
- x: for the main expert entry
- a: for the main auto entry
- r: for the main rescue entry
- s: for the synth entry
for expert, auto and rescue, the hotkey is given to the graphical entry
where present, otherwise to the text entry.
Gbp-Dch: Short
...for consistency with syslinux config placeholders and improved
clarity of what text is a placeholder.
the old placeholders without the bookends are still replaced for
user configs for backwards compatibility.
the new ones are little used just at the moment but are expected to
become used much more in later commits.
Gbp-Dch: Short
For consistency with install entries (both in live-build and
official Debian install discs).
Comparing with live-build created installer entries, grub-legacy
and grub2 both favour vga-788 for GUI entries and vga=normal for
test entries, whilst syslinux uses vga-788 for everything.
Gbp-Dch: Short
apt v2.0.1 introduced support for coloured E:/W:/N: labels. this adds
support to control it based upon our own colour control.
note that with utilities like dpkg we do not do this, but apt only uses
its new colour support automatically when `apt` is used directly, it is
not automatically enabled (per isatty()) for `apt-get`/`aptitude` (the
`apt` developer responsible for adding colour support in response to my
request for it told me that it was deliberately done like this per being
customary to not change behaviour of those tools for compatibility
reasons). colour errors/warnings are useful, so we want to turn it on for
our use of these tools where we can.
Gbp-Dch: Short
this reverts commit 0cef87ffca though
retaining the 'advanced options' menu entry using a label rather than a
title.
despite having done a lot of testing back in 2015 with my bootloader
improvements, i notice now that in fact the syslinux caret fix has an
undesired side effect of modifying the title displayed above the menus. it
does not help that the text embedded into the splash overlaps with this
menu title; perhaps this explains why i missed this problem back in 2015.
purely reverting the implemented fix solves this title problem, but
restores the caret problem to the advanced options menu (in menu.cfg);
however that menu was using a caret in a title entry, unlike everywhere
else where they are only used with labels, which must have been the
original source of the problem all along. ensuring that this menu uses a
label instead of a title in this reversion leaves everything working
correctly afaict.
Gbp-Dch: Ignore
...from the `Set_config_defaults` function, to being done directly
in `build.sh` (the component which is also responsible for loading
functions, loaded at the start of every script, including the front
end).
thus the colouring decision will now correctly...
- apply to the frontend, such as to the 'root privileges needed'
error, the 'no such script' error, and the command name
colouring that I want to add (the most significant issue).
- apply to error messages generated by the `Arguments` and
`Read_conffiles` functions, which are called before
`Set_config_defaults` by scripts.
as things were, due to the comparison with "false", colour would
_always_ be used in these places (unless _COLOR_ERR=false or
_COLOR_OUT=false wrt. the new command highlight, were set in the
environment when executing a script throught the frontend).
this would not be a problem for normal terminal use of course,
besides being inconsistent where color were turned off, but would
be a bit of a problem if redirected to a file.
a re-evaluation of _COLOR is performed in `Set_config_defaults` to
adjust _COLOR_OUT and _COLOR_ERR where necessary, to correctly
respond to _COLOR being set in saved config files (disabled by
default but a user could always enable), after the point of config
files being loaded.
_COLOR can still be controlled from the environment just as before,
overriding both _COLOR_OUT and _COLOR_ERR.
note that this does not address the fact that --color|--no-color
do not work in the frontend and thus will not impact the colouring
of to-be-introduced command highlighting. this needs to be
addressed separately.
Gbp-Dch: Short
d-i removed this in commit 0917b2dde3ff73a204d27dd2f2fffc8a41175ddd
Note: There was inconsistency between grub and syslinux in use of this, with
syslinux not having it on graphical rescue and auto modes while grub entries
did. The patch to fix that has been dropped since we're removing it everywhere
anyway.
(#395040)
Gbp-Dch: Short
progress-linux, as discussed in MR #142 ([1]) is a little known distro,
which appears to be little more than a personal project of the original
author of live-build.
given that, the expense of maintaining all of these old hacks for it
cannot be justified. it is not known whether or not live-build is even
used with respect to it since the author abandoned live-build some
years ago.
also, at least one past change in live-build possibly broke progress-linux
compatibility anyway, which would have required progress-linux users of
live-build to use a custom progress-linux config, or a progress-linux
fork of live-build, and there is no knowing how much of the hacks in this
"upstream" codebase any user of progress-linux currently relies upon.
and again, progress-linux appears to just be a personal project of
Daniel's, with afaik very little userbase. (Daniel seems to be the only
developer working on the project which speaks to how small it is).
[1]: https://salsa.debian.org/live-team/live-build/-/merge_requests/142
Gbp-Dch: Short
seems to have been obsolete since all the way back at v1.0~a22-1.
history:
- in 0d0de885e3 it was renamed from
LIVE_ROOT to LH_ROOT, but also seems to have become completely
obsolete at this point, and thus mistakenly not actually removed.
before this it seems to have been used to hold the base directory of
live-build from which paths were constructed, but then this use was
removed making it redundant, but it remained in the code.
- 83bc63f725 renamed to LB_ROOT.
- a79a5bea10 dropped setting the variable
only if not already set, in favour of always setting it depending upon
LB_MODE. but still it remained unused.
Gbp-Dch: Short
when the --fdisk and --losetup options were removed, the entries in the
getopt option list should have remained for backwards compatibility such
that the usage warnings can kick in instead of unknown option errors.
Gbp-Dch: Ignore
unless `LIVE_BUILD` is set in the environment when running live-build,
this var will be empty. this will result in the frontend trying to load
the file '/scripts/build.sh', which is doubtful the file intended to be
loaded, if it exists. the intention of checking the path
"${LIVE_BUILD}/scripts/build.sh" is really only to do so if the var is
actually used, so let's only do so if it's non-empty.
since we use `set -e`, if build.sh is not found in either location then
failure will occur. if it is found, presuming it is the real file that we
expect to be found, this file sets the var to a default if it was an empty
string, thus we need not worry about use of the var later in the frontend
script.
also, the var is exported prior to exec'ing the command script, so we know
that in the command scripts it is not going to be empty, and those in
themselves loading build.sh which again exports the var ensures that it
will be set for subsequent loads of component scripts (which happens to
go through the frontend again, not that that matters. so except for at the
start of execution, it should never be found to be empty.
Gbp-Dch: Short
the frontend handles -h|--help directly and correctly redirects to the
man page.
component scripts however fail to load the correct manpage because they
are being directed to `man <script>` instead of `man lb script`.
(affects the top level commands and major build stages which actually have
man pages; the low level components don't and so will always fail anyway).
this is handled for every script in build.sh. this is not stored in the
saved config or anything, so no need to re-evaluate in
`Set_config_defaults`. this just seems to completely pointless.
Gbp-Dch: Short
this function takes one or more required stage fileS _plural_, and exits
if any are missing (or at least it does now after the refactor).
let's rename it to make things more clear
Gbp-Dch: Short
the name of the stage is already printed earlier in the output prior to
the error here being printed. so the error really does not need to include
the script name itself.
now having investigated my suspicions of the functionality and use of
Require_stagefile(), i conclude that it has been fundamentally broken
all the way back to v1.0~a8-1 (or at least usage of it since v1.0.1-2).
gah. (╯°□°)╯︵ ┻━┻
----
very early on in the history of live-build this function took the name of
a _single_ stage file only and did `exit 1` should the file not be found.
this was simple and clearly accomplished "what was on the tin", so to
speak.
in bd1a5ddc82 (2007, 1.0~a8-1) things got
weird. it was modified to support a list of multiple files. but instead of
being written to cause failure if _any_ of the listed files were missing
as perhaps one might expect, it was instead written to fail only if all
files were missing!
if you jump to the conclusion that i'm talking about a simple flipped
logic from a lack or otherwise of a `!` here, you'd be mistaken; there is
a comment inside the function that could not be more clear about what was
intended by the author - "Find at least one of the required stages"! this
makes me thoroughly confused about what they were thinking.
as we'll get to, this was fundamentally flawed (or at least its later use
was), but furthermore there were other notable issues introduced at this
point (but don't worry too much about these, they've all been addressed):
- `NAME` was modified in the loop, using the existing value, but nothing
initially set it...
- the setting of `NAME` seems related to its use in the subsequent error
output, yet they are logically separated; it is only set if a file
exists, while the error is only printed if none exist.
- it is pointlessly using a messy `CONTINUE="true"` based mechanism,
when it could just `return 0`.
- it did not handle correctly the bad use case of no params having been
supplied.
it doesn't seem to have been entirely thought through, despite its
pervasive use throughout the build system.
note that no change was made in that commit to make actual use of the
new multi-param support. it would not be used until about a year later.
the function has remained largely untouched since then. in
c68c0a2708 a notable change was made to add
an initial setting of `NAME`, which partially addressed one of the above
issues. but it did not really address the issue the change was meant to
solve, since the `NAME` as printed in the error was now the name of the
script when what was really wanted was the name of the stagefile. this was
finally fixed properly in d54990695f.
however the weirdly pointless setting of `NAME` persisted in the loop.
finally i personally just refactored the function in the commit prior to
this one, retaining the same functionality but addressing the remaining
of the above minor implementation issues.
looking at usage of the new functionality introduced in
bd1a5ddc82, it does not seem to have been
until 0cbbde2b96 (2008, almost a year after
it was made possible) that changes were made to finally start making use
of the ability to pass more than one filename at a time to the function,
and it would appear that perhaps the author forgot what it actually was
that the function accomplished when used with multiple params, and failed
to double check.
in this first use of multiple parameters, this commit went from passing
single file names to individual calls to the function to passing the files
in one single call, in a commit the purpose of which was described as
simply tidying things up. it was most certainly not intended to change
stage requirements.
unfortunately, a change in requirements did occur as a result since the
new usage of the function was not accomplishing the same as before. this
change completely broke the stage requirements protection mechanism such
that only a single one of the listed stages needed to have completed for
the check to pass, rather than all as expected.
this flaw made it into release v1.0.1-2 and it has existed every since.
in the very next commit from that one,
6204dc0e6d things got even worse. here we
see the config stage being specified commonly as the first stage listed,
which is still the case today. this means that ever since this commit,
if you've already got a config before building (which you inevitably do,
especially after some later commits introduced automatically creating it
if missing), then all other stage requirements are simply ignored.
so it seems pretty damn clear that this function is accomplishing
completely the wrong objective. it _should_ be checking that _all_ files
given to it exist, not just one or more. ¯\_(ツ)_/¯
this FINALLY addresses this mistake.
(not that i wish to berate the author; i've made silly mistakes of my own
before)
- count of params is available as $#, we don't need the pipe-to-wc logic.
- the whole 'CONTINUE' based logic is silly, we can just return once one
of the files is found.
- setting of 'NAME' in the loop was completely pointless.
- the error message for multiple files was not very clear just injecting
a sequence of words into a sentence.
- it did not work correctly if no arguments were given (bad usage)
note, you might question whether the functionality of this function is
correct, as did I; this is tackled in a followup commit whilst this
commit retains the existing functionality!
Gbp-Dch: Short
as suggested by Raphaël
rather than have fixed stagefile filename strings at all in the scripts,
use `$(basename $0)` to use the name of the script (which is the same for
almost all cases anyway, and the stage files are supposed to be almost
exclusively unique per-script). we can thus simplify things by determining
the filename for most use cases within the functions themselves.
this does change the file used by a couple of scripts, affecting backwards
compatibility of executing live-build upon an existing partially or fully
completed build:
- binary_grub-pc used "binary_grub"
- chroot_includes used "includes.chroot"
care had to be taken for the following cases:
- there are some cases like bootstrap_cache, source_debian and
bootstrap_debootstrap which are dealing with more than one file, and/or
otherwise a filename that is not specific to the script itself exactly,
or should not be based upon its name.
- some cases like chroot_cache, bootstrap_cache and
chroot_install-packages need to append something to the end of the name
depending upon which pass/action mode the script is being executed with.
- furthermore in the bootstrap_cache case one of the filenames is used
within the bootstrap_debootstrap and thus needs very careful handling
to be certain that a change in filename of bootstrap_cache does not
break bootstrap_debootstrap.
Gbp-Dch: Short
- avoid all need to pass ".build/" path in stage file names into the
functions
- add a helper to remove a stage file (required to complete the above
properly)
- avoid duplicating filenames within scripts which makes them prone to
mistakes (some instances of which I've actually encountered and had
to fix)
Gbp-Dch: Short
Fixes the following
- Correct version (memtest86/memtest86+) shown instead of fixed 'memtest86+' text
- Ensure correct directory path always used by using replaceable placeholder
Gbp-Dch: Short
all vars affected have been carefully checked to be quite certain
that they are definitely local
where variable is assigned the return value of a function/command, the
local "declaration" is deliberately done on a separate line, since
`local FOO` is actually treated itself as a command rather than a
declaration; will thus always cause $? to be zero, and thus if done on
the same line as such an assignment can not only clobber $? but in doing
so unintentionally blocks failure of a command from triggering the
expected exit from having `set -e`.
also, from testing, i have found that when assigning "${@}" this must be
done on a separate line confusingly as otherwise an error occurs.
Gbp-Dch: Short
The '---' delimiter should appear before the final 'quiet' parameter
(which is used by the debian installer I believe).
This delimiter is added by live-build in syslinux configs, and is present
in both grub2 and syslinux configs in an official debian 7.7 disc image,
suggesting strongly that live-build grub/grub2 menu creation code is in
the wrong here by missing it.
update: this commit previously used -- as was correct at the time, and has
since been updated to use --- per #775128; which was previously tackled in
a separate later commit. the switch to --- was already done for syslinux
(which was not missing the delimiter unlike grub) in
ba6b9adeff
Gbp-Dch: Short
Closes: #775143
I believe that the `quiet` parameter is meant for d-i not the kernel and
thus should be given on the end after a delimiter, as done with syslinux.
Here we switch the order to move it to the end. The addition of the missing
delimiter will be done in a followup commit.
(See #775143)
Gbp-Dch: Short
Current splash makes it very difficult to read menu entries.
Black as a background color is actually interpreted as transparent,
so switching to something else so the highlighted menu entry can be
read more easily.
Gbp-Dch: Short
When building grub2 menu entries the quiet param (meant for d-i)
was excluded from the rescue menu entries instead of expert.
This is the opposite to what is done in the following:
- Menu entries seen in official debian 7.7 disc images (grub2 and syslinux configs)
- Menu entries created for grub (legacy)
- Menu entries created for syslinux
The evidence strongly suggests that the grub2 menu creation was in the wrong!
(See #775143)
Gbp-Dch: Short
thus for some reason if one is connected to a tty and the other a file,
we still get colour in the tty by default.
in terms of options, --color and --no-color override both, no granular
ones added since it's not worth it imo.
this is backwards compatible with custom configs setting `_COLOR`.
it could be argued that setting $_COLOR to "false" for the auto non-tty
cases is redundant, which it is, but it doesn't hurt to do so; it ensures
that if anything (inc. 3rd-party hooks and such) rely on it that it
remains correct; and ensures that if anything in the future mistakenly
uses $_COLOR instead of $_COLOR_OUT|$_COLOR_ERR that at least that will
only be broken for the use case of only one of stdout|sdterr being a tty.
Gbp-Dch: Ignore
...when stdout+stderr connected to a tty (as opposed for example to being
piped to a log file)
very helpful to have colour such that the red/yellow of errors/warnings
can draw the eye to problems.
Gbp-Dch: Short
`DI_PACKAGES` does not need to include `DI_REQ_PACKAGES` so long as
we pass the latter to apt in the one case where it was not already
being given it.
in fact with it including that sub-list meant that in the other
case where it was being given to apt, it actually just resulted in
duplication.
Gbp-Dch: Short
the chown command needed running within the chroot, since apt-get is being
run within the chroot and _apt might have a different UID there than on
the host.
Gbp-Dch: Short
Closes: #953957
when building within a home directory, as /proc, /sys, etc are mounted
and unmounted into the chroot at various points in the build, corresponding
entries appear and disappear within the side panel of nautilus.
this is obviously undesirable.
use of `-o x-gvfs-hide` resolves this for the most part. i still see items
occasionally pop up and having spent some time experimenting, i'm putting
it down to buggy behaviour on the part of nautilus. (aside from those
appearing when debootstrap is running - debootstrap also needs this fix).
Gbp-Dch: Short
Combine the check+create done in each script. (The original functions
are still callable as before, but a new combined `Aquire_lockfile`
function can be called instead, as now used).
Note, a further simplification could be done in removing the passing of
the lock filename in as a parameter since every use of the functions is
with ".lock". The lock functions already have a fallback to ".build/lock"
though. Checking the history, the fallback used to be for a system wide
lock, which was then replaced with this config-tree specific one. As long
as that is not used implicitly by 3rd-party hooks then surely we are free
to change the fallback to ".lock" and further remove passing in a name as
a param...?
history:
db5d2b0dcd0aa8289a37
Gbp-Dch: Short
Closes: #952918
previously this was white+bold. the white aspect was dropped since this
would not be sensible for users with a white background for their terminal.
bold however does not have any effect for me at least so effectively there
is no highlighting at all.
here we reintroduce a colour, one that will work for both black and white
backgrounds of course. purple looks good to me - significantly different
to that used for errors and warnings, and works well with command
highlighting (as enabled separately).
if a script exits due to a failure and `set -e`, we should ensure that an
error message is printed to be clear to the user that something actually
went wrong.
similarly it would be good to print a suitable message should the user
cancel with ctrl+c for instance.
Gbp-Dch: Short
theres no point in creation of stagefiles being kept within a
conditional block of work. if the script completes with success
then it should create its stagefile to thus avoid repeating any
work that it might have done should it get re-run without being
forced.
Gbp-Dch: Short
(part of never completed side-by-side multi archi support)
Several scripts make a call to a function called Check_multiarchitectures,
the purpose of which is to adjust the target directory that certain 'live'
and 'install' files are located in. The idea is that a script sets up
'DESTDIR', 'DESTDIR_LIVE' and 'DESTDIR_INSTALL' as appropriate and then
the script appends a suitable arch dependant postfix to the directory
name, depending upon the arch currently being targetted. This would allow
the script to be run multiple times, each for a different architecture.
This is a part of an implementation of allowing multiple architectures to
sit side by side within the same live image, selectable from the
bootloader menus. (As opposed to multiple architectures mixed within the
same userland).
This is evidently the case both from the fact that:
1) The arch specific postfix chosen in that function depends on a var
called LB_CURRENT_ARCHITECTURE, which is never set. In fact going
back through the git history to the introduction of the function in
0d5ff4ca75, the var (even considering
var name changes) has never been set by anything. So effectively the
call to the function has been entirely redundant all this time.
2) The major build stages do not perform multiple executions of substages
per arch. Thus from this perspective it seems that the support was
never fully implemented.
3) If any doubt remained, there is an old branch called 'tmp-multiarch'
which has a couple of commits making progress with completing support,
such as implementing the above missing pieces.
The above mentioned branch is 10 years old and can be considered abandoned.
It is not clear whether the original author ever intended to complete and
merge this; nor is it at all clear at what stage of completion it was at.
At any rate, imo it is not at all particularly useful to have extra code
and complexity in order to be able to cram multiple environments side by
side in one image, not when CDs/DVDs and even to some extent USB pen drives
are so cheap. And who really needs more than one environment so
desperately on just one such medium.
If this was not enough to justify removal, then there is also the fact that
the support that was implemented has become completely broken over the
years with scripts diverging in terms of the variable names the function
modifies such that they are incompatible with it.
A quick assessment of the state of this latter aspect:
good:
- grub-legacy uses the correct var names so is fine
- memtest similarly good
- installer_debian-installer looks okay
questionable:
- binary_linux-image uses the correct vars but might not select the
right kernel and initrd files to copy (seems to copy all)
bad:
- grub-pc is making a redundant call, after functionality was moved
to the loopback script
- loopback is using the wrong vars (INITFS instead of DESTDIR +
DESTDIR_INSTALL + DESTDIR_LIVE), plus is doing its own amd64+i686
thing anyway, so the function call would achieve nothing anyway.
- syslinux is also using the wrong var names so would not work with
it and is not even making the necessary function call. Also the
install paths are fixed in the hard coded cfg files anyway so this
would need addressing with placeholders and sed replacement, but
then it is not entirely clear how things should work with respect
to install entries and multi-arch anyway, are we having multiple
copies of the installer, one for each target arch and then multiple
copies of the install menus, perhaps under different submenus?
So, this removes the artefacts of this never completed feature.
Gbp-Dch: Short
all echo helpers are used as logging functions with output to go to the
terminal. when used in functions that are designed to return a string
though the message printed would get incorrectly captured.
the previous fix done in e3a987d977 was
stupidly flawed; somehow my testing led me to mistakenly believe that
was adequate, but retesting proves that it was not.
here we create a new FD #3 linked to stdout to output the messages on,
which testing shows works as I had actually intended it.
e.g. here:
```
Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; }
```
we get:
```
~$ Foo a
foo
~$ Foo b
error
~$ XX="$(Foo a)"
~$ echo "${XX}"
foo
~$ XX="$(Foo b)"
~$ echo "${XX}"
error
```
and as demonstrated, "error" got incorrectly captured by in the variable
whereas here:
```
exec 3>&1
Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; }
```
it is different in the last case:
```
~$ XX="$(Foo b)"
error
~$ echo "${XX}"
```
the error successfully makes it to the terminal, and the variable is an
empty string (with a newline automatically printed).
Gbp-Dch: Short
I asked for such a switch to be added in debootstrap back at the start of
2015 in #775454 as part of a review I undertook of its security. A slightly
modified patch was merged a few months later and made it into version
1.0.69.
A patch was never merged into live-build to make use of it however. Let's
do that now.
The benefit of this, as explained in #775454, is that if we want strong
security (LB_APT_SECURE=true) then should debootstrap not be able to find
the GPG key to verify things with, it will abort with an error instead of
falling back to just https downloads with a warning. Such a warning would
be easy to miss in the log output, and security could potentially be
compromised if this were to happen.
Gbp-Dch: Short
Instances of:
if [ $(which <command> ]
have been replaced with:
if command -v <command> >/dev/null
which is considered to be more robust in a range of environments.
scripts/build/chroot_archives: line 259:
if [ "${LB_APT}" = "aptitude" ] && [ ! $(Chroot chroot "which aptitude") ]
has been left untouched because the chroot might require a more complex command
which would need more testing.
manpages/Makefile: line 42:
@if [ ! -x "$$(which po4a 2>/dev/null)" ]; \
has been left untouched because I am not sufficiently familiar with makefiles.
commit f811656150 enabled the grub-efi
bootloader by default for amd64|i386 architectures, but failed to
recognise the this bootloader is not supported for hdd|netboot images.
this meants that if a user tried to build such an image without explicitly
specifying the bootloader, excluding grub-efi, their build would fail
with an error in the binary_grub-efi stage.
this fixes the problem by only enabling grub-efi by default on supported
image builds.
677415f6d7 (2007) in v1.0~a2-1 added a hack
relating to the loop-aes-utils package and losetup. this commit bundled
a bunch of changes, it was not specific to the hack, and so info about the
hack is limited to a brief comment included within the related change in
defaults:
```
# Workaround for loop-aes-utils divertion
# (loop-aes-utils' losetup lacks features).
```
though it is very similar to the removed fdisk hack in that it seems that
one package may replace a binary from another, moving the original to a
new location, and this hack gives the user the opportunity to select the
original instead of the one put in its place, for use in LB.
the comment mentions a package called loop-aes-utils as being the package
that performs such a diversion, and that the need for the hack was that
losetup itself lacked features, presumably encryption support, and it is
clear that it is the losetup binary that is the focus of the diversion.
looking into the history of loop-aes-utils a little, this package was
dropped from debian back in 2012 (#680748), favouring encrytion support of
dm-crypt/cryptsetup.
double checking file contents of packages, only the mount package carries
an /sbin/losetup file, so presumably this means that dm-setup/cryptsetup
do not perform such a diversion of losetup (i.e. their use is exclusively
done directly).
since the possible diversion is simply gone, that completely removes any
point in having the hack of giving users choice between losetup and the
diverted one. so let's remove this obsolete hack...
8321653cb3 (from 2007) introduced a hack to
work around bug #445304 in gnu-fdisk for users who may have replaced fdisk
with the classic gnu version. the hack allowed users to select an alternate
fdisk binary to use to work around the buggy binary.
bug #445304 is marked as found in v1.0-1 and fixed in v1.2-1, though may
have been fixe din v1.1. it was marked fixed in 2009.
checking the package archive, gnu-fdisk does not actually exist anymore
in debian, with one exception - it is available for arm64 on sid via
debports, and that version is 1.3 so thus includes the necessary fix
anyway.
it is thus pointless now that we still carry this hack.
Gbp-Dch: Short
I'd mistook the copyright here to apply to the apt package, but did not
look close enough, it's clearly referring to copyright of the files which
we've just amended to have a "The Debian Live team" notice, which this
should thus surely also have.
Gbp-Dch: Short
Current versions of the project files are built upon versions published
and licensed by Daniel Baumann, but are modified copies of those files and
thus need to be marked as such per licensing requirements (afaik he did
not pass along ownership / licensing rights to anyone when he left the
project). We should also be careful to not be misrepresenting such
modified copies as being attributed to Daniel.
Adding a new copyright line referring to "The Debian Live team" should
suffice for this.
The authorship block in man pages has also similarly been updated.
Notes:
- tweaked a copy of daniel copyright lines stating 2014 instead of 2015.
both of these cases were in files that i had personally introduced in
some of my past merged commits that moved some code around. i don't know
why they stated 2014.
- binary_onie was introduced in 2018, so that has a 2018 date instead of
2016 unlike the rest.
- 'efi-image' is a 3rd-party (Canonical Ltd) work that we bundle, but it
has been modified by 674794a8f4 and
36a3ba7634 so I similarly added a
debian live copyright line.
- 'grub-cpmodules' is similar. it was only changed by the indentation fix
of 36a3ba7634 but modification is
modification, and this does help cover any possible future changes that
might be made.
Prefer downloading the version of the source package that actually
corresponds to the version of the binary. Should apt-update be
run and a package updated, we do not really want to fetch a newer
copy of the source than that of the binary, we want the exact
corresponding version (kinda the whole point of compiling a source
disc that they correspond). If the exact version is no longer
available then it is surely preferable to list it in the missing
list than end up with a newer version.
Gbp-Dch: Short
Closes: #952932
if you execute the bootstrap stage with no internet connection, you get
the following output:
```
[2020-03-10 19:18:46] lb bootstrap
P: Setting up clean exit handler
[2020-03-10 19:18:46] lb bootstrap_cache restore
[2020-03-10 19:18:46] lb bootstrap_debootstrap
P: Begin bootstrapping system...
P: If the following stage fails, the most likely cause of the problem is with your mirror configuration or a caching proxy.
P: Running debootstrap (download-only)...
I: Retrieving InRelease
I: Retrieving Release
E: Failed getting release file http://deb.debian.org/debian/dists/buster/Release
P: Begin unmounting filesystems...
P: Saving caches...
chroot: failed to run command ‘/usr/bin/env’: No such file or directory
```
the last line looked suspicious. investigating it turns out that there was
a deficiency in the exit handler.
when debootstrap fails to download what it needs due to lack of a
connection, that failure due to `set -e` causes the Exit() handler to kick
in. Part of this includes outputting the "Saving caches..." line, before
then making a call to Save_package_cache(). That in turn runs the following
command:
```
Chroot chroot "apt-get autoclean" || true
```
The Chroot() function includes a line starting with:
```
${_LINUX32} chroot "${CHROOT}" /usr/bin/env
```
which is the source of the last output line.
the reason we see this unexpected output is that with bootstrapping having
failed, there is no /usr/bin/env within the chroot so it is bound to fail.
the fact is, the exit handler has no business trying to pretty much
anything that it does if the bootstrap_debootstrap stage has not
completed.
this implements such a restriction and thus resolves the problem of this
unexpected and confusing output in the described situation.
we will now see:
```
[2020-03-10 19:18:46] lb bootstrap
P: Setting up clean exit handler
[2020-03-10 19:18:46] lb bootstrap_cache restore
[2020-03-10 19:18:46] lb bootstrap_debootstrap
P: Begin bootstrapping system...
P: If the following stage fails, the most likely cause of the problem is with your mirror configuration or a caching proxy.
P: Running debootstrap (download-only)...
I: Retrieving InRelease
I: Retrieving Release
E: Failed getting release file http://deb.debian.org/debian/dists/buster/Release
```
the source stage emitted the following output for each packages downloaded.
note the troubling warning at the end.
```
Reading package lists... Done
NOTICE: 'grep' packaging is maintained in the 'Git' version control system at:
https://salsa.debian.org/debian/grep.git
Please use:
git clone https://salsa.debian.org/debian/grep.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 1579 kB of source archives.
Get:1 http://deb.debian.org/debian buster/main grep 3.3-1 (dsc) [2038 B]
Get:2 http://deb.debian.org/debian buster/main grep 3.3-1 (tar) [1473 kB]
Get:3 http://deb.debian.org/debian buster/main grep 3.3-1 (diff) [104 kB]
Fetched 1579 kB in 1s (1293 kB/s)
Download complete and in download only mode
W: Download is performed unsandboxed as root as file 'grep_3.3-1.dsc' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
```
this occurred because the '_apt' user did not have permission to write to
the destination directory and so was falling back to downloading as root
in order to do its work.
prior to 158950b873 all source packages were
downloaded directly to the root of the chroot. that commit changed this to
save them into a new clean directory within it instead. thus to fix the
problem we can simply set the ownership of this new directory to '_apt'.
Gbp-Dch: Short
the check for existence of debootstrap here was completely redundant since
there is a check at the beginning of the file which already outputs an
appropriate error and exists if missing.
the cache restore/save script is not a chroot modification script unlike
the rest of the scripts that it was bunched up with. It is an actual
component part of the chroot build stage.
let's bring clarity to this with improved documentation.
Gbp-Dch: Short
LB_APT_SOURCE_ARCHIVES determines whether or not deb-src entries are
desired to be included in apt's sources.list. here, instead of excuding
them we always include them but commented out where they would previously
have been excluded. this means that if a user later changes their mind and
wants to make use of them all they have to do is uncomment them rather
than add the necessary lines.
Gbp-Dch: Short
Closes: #952929
all scripts use `set -e` which means that if getop fails, the subsequent
error check that would print an error in addition to any printed by getopt
itself would never actually be reached.
the first though here would be to remove the pointless error check, but
getopt does not include the word "error" with an unrecognised option
failure, nor does it use colour to highlight problems, both of which mean
that it is a little lacking in terms of highlighting problems to users.
thus we properly capture and use the exit code here and output an
appropriate message per invalid argument vs getopt internal error.
also, removed the redundant stderr redirection which is already done
by Echo_error().
Gbp-Dch: Short
white is not going to work well on a terminal with a white background,
obviously. We should keep the standard colour and just try applying the
bold.
or do we want to consider a non black/white colour? like blue...?
Gbp-Dch: Short
instead of conditionally writing deb-src lines, it is **much** neater if
we use sed to optionally removed them at the end.
Gbp-Dch: Short
Closes: #952928
- prefer using `which` over hard coded paths
- it is redundant to check that the bin pointed to the return of
`which` exists and is executable, `which` already gives us
assurance of that if it returns true!
- the redirection of output (`2>/dev/null`) seems to be
unnecessary from my testing.
the instances relatnig to fdisk and losetup in functions/defaults.sh have
been left as they are since they get executed by `lb config` which can run
without sudo elevation unlike `lb build` and in that case `which` would
fail to find these binaries resulting in error.
this also fixes a bug showing an error for missing debootstrap - this tool
requires sudo privileges to run and thus is not found via a none elevated
which search.
Gbp-Dch: Short
Closes: #952927
commit d74f2102a0 added a validation check
to chroot_archives for its 'pass' parameter. this was based upon finding
an instance where the wrong value was being submitted to the script and
wanting to ensure such mistakes would be caught.
unfortunately it seems that I made a mistake in misremembering the facts
surrounding the latter issue when constructing the validation check and
failed to double check with testing until it was already merged. a
correction is needed. the set of valid values is not limited to only
'source|binary' but actually 'source|binary|chroot'. I'd misremembered
'chroot' as being a completely invalid value.
the existing logic for obtaining a list of firmware packages always
downloaded a fresh copy of the archive content file, deleting the file
already in the cache. here we move to actually making use of the cache.
this helps when building multiple times, at least for the same distro. the
package list obtained is rarely going to change after all. it could of
course differ between distros, but the cache is per-distro, as it has
always been.
we of course here switch to caching each of the archive-area files
individually rather than having one file that gets overwritten (or
appended to in the case of when we kept the decompressed file).
Gbp-Dch: Short
Closes: #952911
the existing logic was to decompress the contents file from the downloaded
archive to disk, then process it to obtain a package list. the largest
one by far is for 'main'; 'non-free' and 'contrib' are tiny in comparison.
for sid-amd64 currently, the archive file is 37 MB, while the decompressed
file it contains is 592.3 MB.
we always delete the files and download afresh (currently), and a previous
commit optimised by deleting the files once we're done with them to avoid
wasting disk space leaving them behind.
here we switch to storing the downloaded compressed file to disk instead,
reducing disk space usage (and IO) by hundreds of megabytes; piping the
decompression directly into awk instead of having awk read from the stored
file.
this moves the appending of new items into the list back within the archive
area loop, which is fine since we're replacing the file for each loop now
so the previous issue relating to appending is of no concern.
Gbp-Dch: Short
Closes: #952910
addressing an old fixme, should distro and parent-distro be identical (in
a derivative build) we want to avoid wasting effort downloading and
processing the same content files twice.
since parent and non-parent have separate archive-area lists though we
should perhaps not just assume that they are identical or ignore any
differences; thus here in such a situation we ensure that we handle any
archive areas not already done for parent-distro handling in such a case,
while skipping those already done.
i notice that the fixme actually also refers to avoiding actual
overlapping of the cached files, however the cached files are (currently)
always ignored anyway, so this is of no concern. reusing the cached files
is an entirely separate issue.
Gbp-Dch: Short
Closes: #952909
the 'manually add firmware-linux package' bit was stuck inbetween the
parent and non-parent logic, which was especially unhelpful before we
de-duplicated the logic into a common function.
Gbp-Dch: Short
Edit: There were four copies of the same logic to keep in sync;
Originally this patch deduplicated each file, but leaving a copy of
the new function in each, thus reducing the duplication but not
eliminating it. A later patch moved it into a shared function file
following further enhancements to the code in question. This has
since been revised to have the function moved to a shared file here,
which simplifies and gives a cleaner diff.
Gbp-Dch: Short
Closes: #952908
the archive content file downloaded to obtain a list of firmware packages
is always deleted and downloaded afresh currently. it may not be ideal that
we do not make use of the cache here, however while that remains
unaddressed, we might as well delete the file after we've used it in order
to not pointlessly waste disk space.
note that this file is ~613 MB for sid-amd64 currently.
Gbp-Dch: Short
Closes: #952907
where multiple archive areas are used, the code here on each loop is:
1) fetching the archive area contents file (compressed)
2) **appending** the output to that of the previous loop
3) searching the file for firmware references, adding to the list
since it appends rather than replaces, entries found in each loop get
re-added on each subsequent loop, resulting in duplication in the
resulting list
below I evaluate the possible solutions to explain why I chose the one
I chose, however the reader should not waste too much time worrying about
whether one of the other solution would have actually been better because
things are changed significantly in further commits shortly!
possible solutions:
a) switching to output (>) rather than append (>>), but this might fail
against an existing file
b) removing the file on each loop, but this will complicate any future
caching improvements that might be made here (currently the files are
always deleted and thus downloaded fresh)
c) allow the appending, evaluating the complete file after the loop
solution C warrants consideration of disk space consumption; currently the
compressed 'main' archive (for sid on amd64) expands to 592.3 MB (feb-2020),
'contrib' is 3.1 MB, and 'non-free' is 18.5 MB.
solution C was chosen here; the difference of accumulated file size vs.
max-single was minor enough to not be of particular concern (~613 vs.
~592 MB).
Gbp-Dch: Short
Closes: #952906
These functions are specific to handling packages stored in the
cache, not other files. They are also always used with the same
`cache/packages.` prefix to the path.
Gbp-Dch: Short
Closes: #952916
instead of trying all from derived mirror then falling back to parent upon
failure, which as pointed out by a message printed out can result in a
load of spurious 404 errors; actually get each udeb from the mirror it is
supposed to be retrieved from.
Partial fix for #952914, this is the last commit for it so closes it
Gbp-Dch: Short
Closes: #952914
the existing logic just bundled the entire parent and derived udeb lists
together, ignoring the fact that there might thus be two instances of some
packages, and relying upon getting derived ones first and checking file
existence to avoid handling the overridden parent instances.
here we now actually filter the list of parent udebs to exclude packages
that are to be obtained from the derivative.
this enables avoiding the file existence checking
Partial fix for #952914
Gbp-Dch: Short
move the code that checks whether a version of a given package has already
been obtained (to account for parent and derived both listing the same
package) to guard the copy from cache action also, not just the download
action.
in rare but possible scenarios it would have been possible to end up with
both the parent and derived copies of a package included.
Partial fix for #952914
Gbp-Dch: Short
this script outputs a series of progressive dots as progress is made,
finally terminated with ' done.'. however if an error occurs then the
error would end up being printed directly on the end of this instead of
on a new line since newlines are not printed after each dot. this fixes
this oversight.
Gbp-Dch: Short
Closes: #952883
the '.' progress stuff has been left as is. perhaps that should be removed
since its use is inconsistent compared to other scripts?
Gbp-Dch: Short
Closes: #952882
only a couple were in use and only by unused echo helpers which have now
themselves been removed, so nothing in this file is needed.
Partial fix for #952880
Gbp-Dch: Short
Closes: #952880
all of these echo helpers are essentially 'logging' functions with output
always intended for stdout/stderr. lack of explicit stdout/stderr direction
means that their output could be captured unintentionally should they be
used within a function designed to construct a string.
Gbp-Dch: Short
Closes: #952879
lack of stderr directed output for the `E:` prefix meant that it would
not appear alongside the message in some use cases
Gbp-Dch: Short
Closes: #952878
Avoid all of the duplication for each installer case
Note, what is done for the netboot case (which was previously missing)
still needs addressing
Gbp-Dch: Short
Closes: #952865
LB_DEBIAN_INSTALLER_GUI defines whether or not to provide the graphical
installer. the installer_debian-installer script pays attention to it and
does not download it if not wanted. the actual bootloaders however
(both grub2/loopback and syslinux) ignore it, which leaves broken and
unwanted menu entries. this fixes that.
Gbp-Dch: Short
Closes: #952890
available values currently are memtest86+|memtest86|none; "false" is
presumably handled for backwards compatibility
there is no need to handle this in individual scripts. the right place
to handle it is in Set_Defaults as now done
Gbp-Dch: Short
Closes: #952866
`false` and `none` make no sense as choices for this option. Here we
replace `false` with `none`, and remove `true`.
Note that `true` was treated as an alias for netinst (see the changes to
source_disk and and binary_disk).
For backwards compatibility we still allow `true` and `false` by converting
them to `netinst` and `none` respectively, whilst printing a warning to
encourage users to move to `netinst`/`none`.
Gbp-Dch: Short
Closes: #952864
including:
- spaces replaced with tabs for consistency
- alignment of `;;` in some case statements changed for consistency
Gbp-Dch: Short
Closes: #952857
`lb build` is a top level command and the one most users will want. listing
the secondary component build stages alongside it just confuses things.
here we clarify things by moving the second-level build stages to a
separate list.
Gbp-Dch: Short
The specifics of what whould be done for it, beyond the disk info
label, needs addressing. (fixme comment left). (#952854).
Partial fix for #952846
Gbp-Dch: Short
Closes: #952846
update feb-2020: the bug report is marked as fixed in version 5.0-a7-1,
however there is no such patch merged for that tagged release, nor at all
in master, so this properly closes it.
Gbp-Dch: Short
Closes: #776532
Update feb-2020:
Both grub2 and syslinux were affected by this issue. Someone else's
patch fixing syslinux only just recently got merged in
2735f3bd38 but grub2 was still
affected. I had made patches for both in 2015 which never got
merged. This is the grub2 one.
Gbp-Dch: Short
Closes: #952843
I do this to manually add the bug closure for #952834 and #952834
since they were merged with an invalid bug closure syntax. Same
for #952839 which also was tagged with "Gbp-Dch: Ignore" thus not
generating any changelog entry... a changelog entry is required
to be able to close a bug!
all uses of this script pass in a suitable 'pass' param, and a previous
commit added a validation check. Having a fallback to 'binary' should a
param not be supplied is completely unnecessary.
fyi, this script is only ever called from the bootstrap stage and with
'binary' as the param, thus supporting being called with 'source' and
indeed having a 'pass' param at all is surely utterly pointless in itself.
Gbp-Dch: Ignore
18e0a2f325 "rebranded live sources" which
included renaming `source_debian-live` to `source_live` but accidentally
left the old file in place.
(Closes#952834)
apt-ftparchive is not able to differentiate between .deb and .udeb so
we have to install them in different pool directories so that we can
regenerate the Packages files without having the .udeb show up
unexpectedly.
Since binary_package-lists can overwrite the Packages files generated
in installer_debian-installer we have to ensure that it also updates
the Release file created formerly.
Ideally we should find a way to avoid the duplication of this logic.
Gbp-Dch: Full
In the binary stage, chroot is restored from cache/bootstrap, which contains
neither custom repo lists, nor keys. If local packages are present,
chroot_archives will call 'Apt chroot update' after adding custom repo lists
without adding keys. apt-get will then fail instead of warn as of apt version
1.5.
Closes: #941691
This makes it possible to build an image against a first distribution
(--distribution-chroot) and have the resulting image point to another
distribution (--distribution-binary). We can use this to build against a
snapshot and have the result use the original distribution that was
snapshotted.
Closes: #888507
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"
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.
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.
When using Secure Boot, grub2 as built by Debian will now load a config
file from EFI/$VENDOR instead of having EFI/debian hardcoded.
$VENDOR comes from dpkg-vendor or from the user building grub2.
The vendor string is stored in the control metadata as Efi-Vendor, so
retrieve it when building the EFI image.
Only gnupgv is part of the deboostrap set these days, but apt-key needs
the full gpg (with gpg-agent) which is just a recommends.
Instead just drop the key with an .asc suffix in /etc/apt/trusted.gpg.d
which is supported since apt version 1.4
live-build supports preseeding configuration, but the configuration has
to be installed after bootstrapping since it needs the debconf tools to
be applied. But packages that have already been installed and configured
in the bootstrap step will then ignore those preseeded configs.
After applying each preseed file, parse the package list and manually
reconfigure the relevant package(s) so that the configuration will be
applied.
Check_package will just add a missing dependency to the LB_PACKAGES
todo list if it doesn't find it, when build-with-chroot is true, even if
the check was not for the chroot.
Instead error out if the check is not done for the chroot, e.g.
Check_package host /bin/foo foo
The binary_onie script works on the host, not in the chroot (if used),
so don't check that the required packages for the script are installed
in the chroot (if present) as they won't be useful.
Check instead on the host.
Instead of hard-coding the decompression and compression formats,
detect them at runtime.
Install the required dependencies as well - they were mistakenly left
out.
Gbp-Dch: Ignore
The apt-secure option does not work anymore when building a sid image,
as with apt 1.6 the existing options are no longer enough to get apt
to accept an unsigned repository, which is necessary when using a
local cached repository (offline build).
Pass Acquire::AllowInsecureRepositories "true"; together with the
other options when --apt-secure false is used to fix the issue.
Open Network Install Environment is an open image format used by
networking vendor to ship a standardised image for networking white
box switches.
ONIE hardware takes this image at boot and a script to chain load
into the final environment via kexec. We can support Debian and
derivatives on such systems by packing an ISO which then gets
unpacked, kexec'ed and live-booted.
A base ONIE system can be tested in QEMU by building a VM following
these instrunctions:
https://github.com/opencomputeproject/onie/blob/master/machine/kvm_x86_64/INSTALL
Once built, boot onie-recovery-x86_64-kvm_x86_64-r0.iso in QEMU/libvirt
and on the console there will be the terminal prompt. Check the IP
assigned by libvirt and then scp the live image (ssh access is enabled
as root without password...). Then the .bin can be booted with:
ONIE-RECOVERY:/ # onie-nos-install /tmp/live.hybrid.iso-ONIE.bin
The implementation is inspired by ONIE's own scripts that can be found
at:
https://github.com/opencomputeproject/onie/blob/master/contrib/debian-iso/cook-bits.sh
A new option, --onie (false by default) can be set to true to enable
building this new format in addition to an ISO.
An additional option, --onie-kernel-cmdline can be used to specify
additional options that the ONIE system should use when kexec'ing the
final image.
Note that only iso or hybrid-iso formats are supported.
For more information about the ONIE ecosystem see:
http://onie.org
Signed-off-by: Erik Ziegenbalg <eziegenb@Brocade.com>
Signed-off-by: Luca Boccassi <bluca@debian.org>
The Tianocore reference UEFI implementation, used for example by Qemu,
wants the EFI directory name to be uppercase in the fat32 partition
when Secure Boot is enabled, and will fail to load otherwise.
Support for UEFI Secure Boot is modelled after how it currently works
in Ubuntu and on how it is going to work on Debian.
A minimal bootloader, shim, is used as the first-stage and it then
loads grub. Both have to be signed.
shim-signed is already available in Debian so the filenames are
already established, and the grub2 repository and packaging is common
between the 2 distros so we can already be reasonably sure of what it
is going to be.
So if both are available, copy /usr/lib/shim/shim[x64|aa64].efi.signed
as boot[x64|aa64].efi so that UEFI loads it first, and copy
/usr/lib/grub/[x86_64|arm64]-efi-signed/grub[x64|aa64].efi.signed as
grub[x64|aa64].efi.
This grub2 EFI monolithic image is currently hard-coded in grub2's
repository to look for a config file in efi/debian, so make a copy
of the previously added minimal grub.cfg that loads the real one in
that directory in both the fat32 and ISO 9660 partitions.
The new option --uefi-secure-boot can be set to auto (default,
enable or disable.
In auto, the lack of the signed EFI binaries is intentionally left as a
soft failure - live-build will simply fallback to using the locally
generated non-signed grub2 monolithic EFI binary as the only
bootloader. Given the difficulties surrounding the Secure Boot
signing infrastructure this approach gives the most flexibility and
makes sure things will "just work" once the packages are available,
without the need to change anything in the configuration.
This will also greatly help downstream distributions and users who
want to do self-signing.
The enable or disable options work as expected.
Closes: #821084
On some UEFI implementations, like the AMI found in the Supermicro
X10SDV-TP8F development board, the fat32 partition will be loaded
first and so Grub will set it the root, and then drop to the console
as it cannot find any config on it.
Add a minimal grub.cfg that allows Grub to find the main config on
the ISO 9660 partition and load it.
Closes: #892406
Machines tend to become unresponsive during the mksquashfs step.
Avoid this by lowering the priority of the process.
Thanks: Ronny Standtke for the patch.
Closes: #867539
Commit a15b579652 (#775989) dropped an early exit from the
chroot_archives remove step in case the parent mirror chroot and binary
parameters are the same and introduced a regression, as with the
following live-build now fails when the parent mirror is using a file:/
local apt repository (for example when the build worker is offline and
uses a pre-built cache of packages).
Example config:
lb config --mirror-bootstrap "file:/pkgs" \
--mirror-chroot "file:/pkgs/" \
--mirror-binary "file:/pkgs" \
--parent-mirror-bootstrap "file:/pkgs" \
--parent-mirror-chroot "file:/pkgs/" \
--parent-mirror-binary "file:/pkgs" \
...
with /pkgs being a directory with the packages for the installation and
the apt metadata (Packages/Sources/Release).
The problem is that, with such a setup, the /pkgs directory is bind
mounted inside the chroot as an optimisation in the install step,
and umounted as one of the first actions in the remove step for
chroot_archives.
Before that fix, the script terminated immediately. But now it
progresses and at the end it tries to run apt update inside the chroot
which will fail since the repository directory has been umounted, and
thus the packages and the apt metadata are no longer available, while
still being listed in /etc/apt/sources.list.
The proposed solution is to umount the local directory at the end of
the remove step, rather than at the beginning.
Closes: #891206
Now grub.cfg shows all the kernel options. Before this patch when you
had more than two kernels it only showed the auto option.
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
To generate an hdd image, binary_hdd first estimates the needed size of
the image using du. By default, when du finds multiple hardlinked copies
of a file, it counts them only once. However, when the target filesystem
is FAT, which does not support hardlinks, these files will take up more
space when finally copying the contents, breaking the build:
P: Copying binary contents into image...
cp: error writing 'chroot/binary.tmp/live/initrd.img-4.9.0-3-amd64': No space left on device
cp: error writing 'chroot/binary.tmp/efi/boot/bootx64.efi': No space left on device
cp: error writing 'chroot/binary.tmp/efi/boot/bootia32.efi': No space left on device
cp: cannot create directory 'chroot/binary.tmp/boot/grub': No space left on device
cp: cannot create directory 'chroot/binary.tmp/isolinux': No space left on device
To fix this, pass --count-links to du when the target is FAT, to make
the space estimation correct.
This problem is exposed by commit 9c974b26b (Instead of renaming kernel
for syslinux, create hardlinks), which might need to be separately fixed
(to not waste space on FAT targets), but binary_hdd should at least
handle hardlinks more gracefully.
Since commit fdc9250bc (Changing package dependency checks within chroot
to work outside as well), Check_package automatically checks for
LB_BUILD_WITH_CHROOT and works inside as well as outside of the chroot,
so no need to check LB_BUILD_WITH_CHROOT before calling them.
Install_package and Remove_package are just a no-op when building
without chroot, so they can also be called unconditionally.
Restore_cache and Save_cache do not check LB_BUILD_WITH_CHROOT but it
it should not hurt to call them when not needed (which already happened
in some cases).
This commit makes all Check_package calls unconditional on
LB_BUILD_WITH_CHROOT.
For binary_syslinux, this fixes the check (which used outdated paths
outside the chroot since 7b6dfd9d1), for binary_grub-efi,
binary_package-lists and chroot_package-lists this simplifies the code
(but also causes the check to become package-based instead of file-based
on apt-based systems), and for binary_loadlin and binary_win32-loader
this adds the check outside the chroot which was previously missing.
Previously, Check_package would only show an error when host packages
are missing on a non-apt system. On apt system, the packages would be
added to _LB_PACKAGES, which causes them to be installed in the chroot,
not in the host (or not at all if Install_package is not called). This
behaviour could break the build.
This applies to either packages that must be present in the host (as
checked with `Check_package host ...`), as well as packages that can be
either in the chroot or host (as checked with `Check_package chroot`)
when LB_BUILD_WITH_CHROOT=false.
Recent versions of Linux, parted or some other bit of software cause
partition devices, like /dev/loop0p1 to be created when running parted
mkpart. However, these devices are not cleaned up when running
losetup -d to remove /dev/loop0 later, so they linger around and confuse
mkfs (which refuses to make a filesystem, thinking there are partitions):
mkfs.fat 4.1 (2017-01-24)
mkfs.vfat: Partitions or virtual mappings on device '/dev/loop0', not making filesystem (use -I to override)
To prevent this behaviour, pass --partscan to losetup when adding a new
partition, to clean up any lingering partitions. It seems losetup does not
accept --partscan when deleting a loop device, to clean up at that point, but
since binary_hdd mounts the partition last, there should not be any lingering
partition devices after live-build is done.
The --partscan option is available since util-linux 2.21 (released in 2012), so
it should be fairly safe to pass it unconditionally.
* Use only long kernel names.
* Put advanced options in a submenu.
* Use distro-agnostic labels.
* Don't generate entries with kernel version when we have a single
version.
This option lets you use an alternate bootstrap script when running
debootstrap. Thanks to Sjoerd Simons <sjoerd@debian.org> for the initial
patch.
Closes: #790033
Commit e24e4b in debootstrap fixed setup_available to work in the
--foreign case (iotw at the second stage). Unfortunately this breaks
things if components aren't passed to the second stage _and_ your main
component isn't called main.
To fix this, pass --components to both the first and second stage
debootstrap when needed.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Up to now we created a temporary GPG key that we registered with apt-key
but with the switch to GnuPG 2 by default, this code broke. Now we stop
doing that but we add the “trusted=yes“ attribute in sources.list so
that APT knows that the repository can be trusted even if it's unsigned.
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
This work is based on debian-cd team work and uses,
as much as possible, the same mkisofs options
than the Debian Installation CD disk does.
It assumes that /boot/grub/grub.cfg (and other design items)
is generated by: binary_loopback_cfg .
It relies on efi-image and grub-cpmodules being setup
as build scripts on live-build package.
In the future event of these two files being moved
to a binary package (they are originally from:
src: live-installer) the binary_grub-efi script would have
to be rewritten to take the new paths into account.
These two scripts simplify the creation of efi images based on grub-efi.
I have decided to simply steal them. If I had to include them thanks to a source package that would have mean that an src repo would have to be defined by default.
TODO: Ask in a bug a RFE so that these two scripts are put into a binary that could be consumed by both live-installer and live-build packages.
The binary parts of grub-pc are left for the original binary_grub-pc.
As a consequence both /boot/grub/grub.cfg and /boot/grub/loopback.cfg files will be present in any Debian Live CD.
This might be useful to be reused from binary_grub-* bootloaders.
* Added: functions/bootloaders.sh . This file adds bootloader functions that are heavily used in efi scenarios where a bootloader can act as a first or an extra bootloader.
Since the introduction of the new switch:
--bootloaders
you can setup it like this:
--bootloaders=syslinux,grub-efi
.
This means that syslinux is the first bootloader and grub-efi is the extra bootloader.
* Added new bootloader functions: Check_Non_First_Bootloader and Check_Non_Extra_Bootloader.
These functions let each one of the bootloaders abort the build because
they cannot perform a role either as a first bootloader or as an extra bootloader.
* Added bootloader functions: Check_First_Bootloader_Role, Check_Extra_Bootloader_Role and Check_Any_Bootloader_Role
These functions let bootloaders to force their default role in a single line.
At the same time many binary bootloaders were rewritten to make use of the new bootloader role functions explained above.
These roles were enforced:
binary_grub-legacy : First bootloader
binary_grub-pc : Either first or extra bootloader
binary_syslinux : Either first or extra bootloader
If a bootloader is tried to be used in a role that it's not meant to be used then the build fails because that might lead to a non-bootable system.
The fix in a294a46fb9 was not enough.
This should finally resolve the problem when a package list ends
up empty (most notably due to #if evaluating to false).
Sponsored-By: Offensive Security
Some BIOSes dont't boot from partitions starting at sector 1024.
Some are even more peculiar and only start from sector 63.
This patch adds an option for the binary_hdd target to manually
configure the partition start.
Development details
--------------------
* This patch has been based originally on: binary_grub2 . It has been
improved thanks to some binary_syslinux bits.
* This patch ensures that binary_loopback_cfg needs is run
before binary_syslinux is run.
The reason is that it reuses some code from binary_syslinux to avoid
problems when binary_syslinux renames the kernel filenames.
* This patch already supports CPU detection
* I haven't tested all the possible scenarios for the script (with the
latest version). When amd64 and 486 Gnu/Linux flavours is used and the
bootloader is syslinux it works ok.
* I have not implemented a disable switch for not generating it.
Usually you always want loopback.cfg to be there.
* Compared to binary_grub2 script I have removed the installation
entries because I did not see any of them in binary_syslinux.
How to test
-----------
These are some steps to easily test if Looback cfg support is working ok.
0) We assume you have generated an iso
1) Make sure you have a partition that Grub understands. Plain ext4 or
vfat should do it.
2) Create directory: /boot/boot-isos/
3) Put the iso file into that directory making sure it has an ISO or iso
extension.
4) Setup your computer to boot from cdrom and use: Super Grub2 Disk
2.00s2 (Hybrid version recommended)
5) Choose Boot manually...
6) Choose Bootable ISOs (in /boot- ... )
7) Choose (the detected) GRUB Loopback Config
(hdN,msodsN)/boot/boot-ios/name-of-the.iso
8) You will be presented your loopback.cfg. Choose anyone of the entries
(unless it does not match your cpu architecture of course).
9) You should boot into your Debian Live without problems (thanks to
findiso boot parametre).
If you ever wanted to test from your grub2 installation instead from
Super Grub2 Disk check: http://www.supergrubdisk.org/wiki/Loopback.cfg
for an example.
Note: OLDIFS use makes IFS to be reset to "" instead to it being unset.
Either we need to detect if old IFS was unset to unset it
or we need a proper way of setting it as a local variable.
Even more IFS it's not currently used in
Check_package (which it's called from: binary_hdd).
we should have a clean way of resetting/unsetting IFS when calling Check_package.
The other approach it's to explicitly define IFS with its default value in the
places inside live-build code where we implicitly suppose that it's going to have
its default value.
# A bug report with patch is available at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982607
# This script duplicates that patch
# Don't run if mdadm is not installed
if [ ! -e /usr/share/mdadm/mkconf ];
then
exit 0
fi
# If mkconf already contains references to SOURCE_DATE_EPOCH, there is no need to patch the file
if grep -q SOURCE_DATE_EPOCH /usr/share/mdadm/mkconf;
then
exit 0
fi
sed -i -e '/# This configuration was auto-generated on/cif [ -z $SOURCE_DATE_EPOCH ]; then\n echo "# This configuration was auto-generated on $(date -R) by mkconf"\nelse\n echo "# This configuration was auto-generated on $(date -R --utc -d@$SOURCE_DATE_EPOCH) by mkconf"\nfi' /usr/share/mdadm/mkconf
echo "P: $(basename $0) Reproducible hook has been applied"
# Ugly hack: remove the hyphenation exceptions -> fixes 3
# This results in incorrect hyphenation, but it is a work-around until the function 'exception_strings' has been adjusted
sed -i -e '/as-so-ciate/d;/as-so-ciates/d;/dec-li-na-tion/d;/oblig-a-tory/d;/phil-an-thropic/d;/present/d;/presents/d;/project/d;/projects/d;/reci-procity/d;/re-cog-ni-zance/d;/ref-or-ma-tion/d;/ret-ri-bu-tion/d;/ta-ble/d' /usr/share/texlive/texmf-dist/tex/generic/hyphen/hyphen.tex
echo "P: $(basename $0) Reproducible hack has been applied: hyphenation of some words will be incorrect"
fi
rm -f md5sum.luahbtex
# Rebuild all .fmt and .log files in /var/lib/texmf/web2c
fmtutil --sys --all
# Use faketime to enforce a timestamp -> fixes 4
# NB: hooks don't know about the apt/aptitude selection, so use 'apt-get'
if Find_files config/debian-installer/*.cfg &&[ ! -e config/debian-installer/preseed.cfg ]
then
Echo_warning "You have placed some preseeding files into config/debian-installer but you didn't specify the default preseeding file through LB_DEBIAN_INSTALLER_PRESEEDFILE. This means that debian-installer will not take up a preseeding file by default."
if ! In_list "bootstrap"${LB_CACHE_STAGES}||["${LB_CACHE}" !="true"]||["${LB_CACHE_PACKAGES}" !="true"]
then
Echo_warning "You have selected values of LB_CACHE, LB_CACHE_PACKAGES, LB_CACHE_STAGES and LB_DEBIAN_INSTALLER which will result in 'bootstrap' packages not being cached. This configuration is potentially unsafe as the bootstrap packages are re-used when integrating the Debian Installer."
fi
fi
if In_list "syslinux"$LB_BOOTLOADERS;then
# syslinux + fat or ntfs, or extlinux + ext[234] or btrfs
Echo_warning "You have selected values of LB_BOOTLOADERS and LB_BINARY_FILESYSTEM which are incompatible - the syslinux family only support FAT, NTFS, ext[234] or btrfs filesystems."
fi
fi
if In_list "grub-pc"${LB_BOOTLOADERS}|| In_list "grub-efi"${LB_BOOTLOADERS}|| In_list "grub-legacy"${LB_BOOTLOADERS};then
if In_list "${LB_IMAGE_TYPE}" hdd netboot;then
Echo_error "You have selected an invalid combination of bootloaders and live image type; the grub-* bootloaders are not compatible with hdd and netboot types."
exit1
fi
fi
Validate_http_proxy
}
# Retrieve the proxy settings from the host. Check whether conflicts are present with the command line arguments
Validate_http_proxy ()
{
localHOST_AUTO_APT_PROXY=""
localHOST_AUTO_APT_PROXY_LEGACY=""
localHOST_FIXED_APT_PROXY=""
# Fetch the proxy, using the various ways the http proxy can be set in apt
ifcommand -v apt-config >/dev/null;then
local APT_CONFIG_OPTIONS
# apt-config only understands --option (-o) and --config-file (-c) of ${APT_OPTIONS}
# Don't report errors when additional options are provided and don't add additional quotes
# The apt configuration `Acquire::http::Proxy-Auto-Detect` (and the legacy `Acquire::http::ProxyAutoDetect`)
# If the script fails, or the result of the script is `DIRECT` or an empty line, it is considered to be not set (https://sources.debian.org/src/apt/2.3.9/apt-pkg/contrib/proxy.cc/)
Validate_http_proxy_source "command line option --apt-http-proxy""${LB_APT_HTTP_PROXY}"
# This is the value to use for the other scripts in live-build
exporthttp_proxy="${LAST_SEEN_PROXY_VALUE}"
if[ ! -z "${http_proxy}"];then
Echo_message "Using http proxy: ${http_proxy}"
fi
}
# Check whether a proxy setting conflicts with a previously set proxy setting
Validate_http_proxy_source ()
{
localNAME="${1}"
localVALUE="${2}"
if[ ! -z "${VALUE}"];then
if[ ! -z "${LAST_SEEN_PROXY_VALUE}"];then
if["${VALUE}" !="${LAST_SEEN_PROXY_VALUE}"];then
Echo_error "Inconsistent proxy configuration: the value for ${NAME} (${VALUE}) differs from the value for ${LAST_SEEN_PROXY_NAME} (${LAST_SEEN_PROXY_VALUE})"
if Find_files config/debian-installer/*.cfg &&[ ! -e config/debian-installer/preseed.cfg ]
then
Echo_warning "You have placed some preseeding files into config/debian-installer but you didn't specify the default preseeding file through LB_DEBIAN_INSTALLER_PRESEEDFILE. This means that debian-installer will not take up a preseeding file by default."
Echo_error "This config tree is too old for live-build (${VERSION})."
Echo_error "Aborting build, please update the configuration."
exit1
else
Echo_warning "This configuration does not specify a version or has a unknown version."
Echo_warning "Continuing build, please correct the configuration."
fi
fi
fi
fi
case"${LB_BINARY_FILESYSTEM}" in
ntfs)
if[ ! -x "$(which ntfs-3g 2>/dev/null)"]
then
Echo_error "Using ntfs as the binary filesystem is currently only supported"
Echo_error "if ntfs-3g is installed on the host system."
exit1
fi
;;
esac
ifecho${LB_HDD_LABEL}| grep -qs ' '
then
Echo_error "There are currently no whitespaces supported in hdd labels."
exit1
fi
if["${LB_DEBIAN_INSTALLER}" !="false"]
then
# d-i true, no caching
if ! echo${LB_CACHE_STAGES}| grep -qs "bootstrap\b"||["${LB_CACHE}" !="true"]||["${LB_CACHE_PACKAGES}" !="true"]
then
Echo_warning "You have selected values of LB_CACHE, LB_CACHE_PACKAGES, LB_CACHE_STAGES and LB_DEBIAN_INSTALLER which will result in 'bootstrap' packages not being cached. This configuration is potentially unsafe as the bootstrap packages are re-used when integrating the Debian Installer."
fi
fi
if["${LB_BOOTLOADER}"="syslinux"]
then
# syslinux + fat or ntfs, or extlinux + ext[234] or btrfs
case"${LB_BINARY_FILESYSTEM}" in
fat*|ntfs|ext[234]|btrfs)
;;
*)
Echo_warning "You have selected values of LB_BOOTLOADER and LB_BINARY_FILESYSTEM which are incompatible - the syslinux family only support FAT, NTFS, ext[234] or btrfs filesystems."
;;
esac
fi
case"${LIVE_IMAGE_TYPE}" in
hdd*)
case"${LB_BOOTLOADER}" in
grub)
Echo_error "You have selected a combination of bootloader and image type that is currently not supported by live-build. Please use either another bootloader or a different image type."
## Copyright (C) 2006-2015 Daniel Baumann <mail@daniel-baumann.ch>
##
## This program comes with ABSOLUTELY NO WARRANTY; for details see COPYING.
## This is free software, and you are welcome to redistribute it
## under certain conditions; see COPYING for details.
exec 3>&1
Echo ()
{
STRING="${1}"
localSTRING="${1}"
shift
printf"${STRING}\n""${@}"
printf"${STRING}\n""${@}" >&3
}
Echo_debug ()
{
if["${_DEBUG}"="true"]
then
STRING="${1}"
if["${_DEBUG}"="true"];then
localSTRING="${1}"
shift
printf"D: ${STRING}\n""${@}"
fi
}
Echo_debug_running ()
{
if["${_DEBUG}"="true"]
then
STRING="${1}"
shift
printf"D: ${STRING}""${@}"
if["${_COLOR}"="false"]
then
printf"..."
else
printf"... ${YELLOW}${BLINK}running${NO_COLOR}"
fi
printf"D: ${STRING}\n""${@}" >&3
fi
}
Echo_error ()
{
STRING="${1}"
localSTRING="${1}"
shift
if["${_COLOR}"="false"]
then
printf"E:"
else
printf"${RED}E${NO_COLOR}:"
localPREFIX="${RED}E${NO_COLOR}"
if["${_COLOR_ERR}"="false"];then
PREFIX="E"
fi
printf"${STRING}\n""${@}" >&2
printf"${PREFIX}: ${STRING}\n""${@}" >&2
}
Echo_message ()
{
if["${_QUIET}" !="true"]
then
STRING="${1}"
localSTRING="${1}"
shift
if["${_COLOR}"="false"]
then
printf"P:"
else
printf"${WHITE}P${NO_COLOR}:"
localPREFIX="${PURPLE}P${NO_COLOR}"
if["${_COLOR_OUT}"="false"];then
PREFIX="P"
fi
printf"${STRING}\n""${@}"
fi
}
Echo_message_running ()
{
if["${_QUIET}" !="true"]
then
STRING="${1}"
shift
if["${_COLOR}"="false"]
then
printf"P:"
else
printf"${WHITE}P${NO_COLOR}:"
fi
printf"${STRING}""${@}"
if["${_COLOR}"="true"]
then
printf"... ${YELLOW}${BLINK}running${NO_COLOR}"
else
printf"..."
fi
printf"${PREFIX}: ${STRING}\n""${@}" >&3
fi
}
Echo_verbose ()
{
if["${_VERBOSE}"="true"]
then
STRING="${1}"
if["${_VERBOSE}"="true"];then
localSTRING="${1}"
shift
printf"I: ${STRING}\n""${@}"
fi
}
Echo_verbose_running ()
{
if["${_VERBOSE}" !="true"]
then
STRING="${1}"
shift
printf"I: ${STRING}""${@}"
if["${_COLOR}"="true"]
then
printf"... ${YELLOW}${BLINK}running${NO_COLOR}"
else
printf"..."
fi
printf"I: ${STRING}\n""${@}" >&3
fi
}
Echo_warning ()
{
STRING="${1}"
localSTRING="${1}"
shift
if["${_COLOR}"="false"]
then
printf"W:"
else
printf"${YELLOW}W${NO_COLOR}:"
localPREFIX="${YELLOW}W${NO_COLOR}"
if["${_COLOR_ERR}"="false"];then
PREFIX="W"
fi
printf"${STRING}\n""${@}"
}
Echo_status ()
{
__RETURN="${?}"
if["${_COLOR}"="false"]
then
if["${__RETURN}"="0"]
then
printf" done.\n"
else
printf" failed.\n"
fi
else
Cursor_columns_backward 8
if["${__RETURN}"="0"]
then
printf"${GREEN}done${NO_COLOR}. \n"
else
printf"${RED}failed${NO_COLOR}.\n"
fi
fi
}
Echo_done ()
{
if["${_COLOR}"="false"]
then
printf" already done.\n"
else
Cursor_columns_backward 8
printf"${GREEN}already done${NO_COLOR}.\n"
fi
printf"${PREFIX}: ${STRING}\n""${@}" >&2
}
Echo_file ()
{
whileread LINE
local LINE
whileread -r LINE
do
echo"${1}: ${LINE}"
echo"${1}: ${LINE}" >&3
done < "${1}"
}
Echo_breakage ()
{
case"${LB_PARENT_DISTRIBUTION}" in
sid)
Echo_message "If the following stage fails, the most likely cause of the problem is with your mirror configuration, a caching proxy or the sid distribution."
;;
*)
Echo_message "If the following stage fails, the most likely cause of the problem is with your mirror configuration or a caching proxy."
.THLIVE\-BUILD12015\-05\-045.0~a6-1"Live Systems Project"
.THLIVE\-BUILD12020\-03\-301:20191222"Debian Live Project"
.SHNAME
\fBlb\fR\- wrapper for live\-build programs
.SHSYNOPSIS
\fBlb\fR COMMAND [COMMAND_OPTIONS]
\fBlb\fR\fICOMMAND\fR [\fICOMMAND_OPTIONS\fR]
.PP
\fBlb\fR [\fIlive\-build\ options\fR]
\fBlb\fR [\fIOPTIONS\fR]
.SHDESCRIPTION
\fBlb\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the live systems tool suite.
.PP
.\" FIXME
\fBlb\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.SHOPTIONS
\fBlb\fR has no specific options but understands all generic live\-build options. See \fIlive\-build\fR(7) for a complete list of all generic live\-build options.
@ -25,10 +23,10 @@
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Live Systems project can be found on the homepage at <\fIhttp://live-systems.org/\fR> and in the manual at <\fIhttp://live-systems.org/manual/\fR>.
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Live Systems mailing list at <\fIdebian-live@lists.debian.org\fR>.
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>.
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
.THLIVE\-BUILD12015\-05\-045.0~a6-1"Live Systems Project"
.THLIVE\-BUILD12020\-03\-301:20191222"Debian Live Project"
.SHNAME
\fBlbbinary\fR\- Complete the binary stage
\fBlb_binary\fR\- Complete the binary stage
.SHSYNOPSIS
\fBlb binary\fR [\fIlive\-build options\fR]
\fBlb binary\fR [\fIOPTIONS\fR]
.SHDESCRIPTION
\fBlb binary\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the live systems tool suite.
\fBlb binary\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.PP
\fBlb binary\fR calls all necessary live\-build programs in the correct order to complete the binary stage.
@ -23,10 +23,10 @@
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Live Systems project can be found on the homepage at <\fIhttp://live-systems.org/\fR> and in the manual at <\fIhttp://live-systems.org/manual/\fR>.
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Live Systems mailing list at <\fIdebian-live@lists.debian.org\fR>.
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>.
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
.THLIVE\-BUILD12015\-05\-045.0~a6-1"Live Systems Project"
.THLIVE\-BUILD12020\-03\-301:20191222"Debian Live Project"
.SHNAME
\fBlbbootstrap\fR\- Complete the bootstrap stage
\fBlb_bootstrap\fR\- Complete the bootstrap stage
.SHSYNOPSIS
\fBlb bootstrap\fR [\fIlive\-build options\fR]
\fBlb bootstrap\fR [\fIOPTIONS\fR]
.SHDESCRIPTION
\fBlb bootstrap\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the live systems tool suite.
\fBlb bootstrap\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.PP
\fBlb bootstrap\fR calls all necessary live\-build programs in the correct order to complete the bootstrap stage.
@ -23,10 +23,10 @@
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Live Systems project can be found on the homepage at <\fIhttp://live-systems.org/\fR> and in the manual at <\fIhttp://live-systems.org/manual/\fR>.
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Live Systems mailing list at <\fIdebian-live@lists.debian.org\fR>.
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>.
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
.THLIVE\-BUILD12015\-05\-045.0~a6-1"Live Systems Project"
.THLIVE\-BUILD12020\-03\-301:20191222"Debian Live Project"
.SHNAME
\fBlbbuild\fR\- Complete the bootstrap, chroot, binary, and source stages
\fBlb_build\fR\- Complete the bootstrap, chroot, installer, binary, and source stages
.SHSYNOPSIS
\fBlb build\fR [\fIlive\-build options\fR]
\fBlb build\fR [\fIOPTIONS\fR]
.SHDESCRIPTION
\fBlb build\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the live systems tool suite.
\fBlb build\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.PP
\fBlb build\fR calls all necessary live\-build programs in the correct order to complete the bootstrap, chroot, binary, and source stages.
\fBlb build\fR calls all necessary live\-build programs in the correct order to complete the bootstrap, chroot, installer, binary, and source stages.
.SHOPTIONS
\fBlb build\fR has no specific options but understands all generic live\-build options. See \fIlive\-build\fR(7) for a complete list of all generic live\-build options.
.SHFILES
.\" FIXME
.IP"\fBauto/build\fR"4
.\" FIXME
.SHSEEALSO
\fIlive\-build\fR(7)
@ -25,10 +23,10 @@
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Live Systems project can be found on the homepage at <\fIhttp://live-systems.org/\fR> and in the manual at <\fIhttp://live-systems.org/manual/\fR>.
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Live Systems mailing list at <\fIdebian-live@lists.debian.org\fR>.
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>.
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
.THLIVE\-BUILD12015\-05\-045.0~a6-1"Live Systems Project"
.THLIVE\-BUILD12020\-03\-301:20191222"Debian Live Project"
.SHNAME
\fBlbchroot\fR\- Complete the chroot stage
\fBlb_chroot\fR\- Complete the chroot stage
.SHSYNOPSIS
\fBlb chroot\fR [\fIlive\-build options\fR]
\fBlb chroot\fR [\fIOPTIONS\fR]
.SHDESCRIPTION
\fBlb chroot\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the live systems tool suite.
\fBlb chroot\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.PP
\fBlb chroot\fR calls all necessary live\-build programs in the correct order to complete the chroot stage.
@ -23,10 +23,10 @@
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Live Systems project can be found on the homepage at <\fIhttp://live-systems.org/\fR> and in the manual at <\fIhttp://live-systems.org/manual/\fR>.
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Live Systems mailing list at <\fIdebian-live@lists.debian.org\fR>.
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>.
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
.THLIVE\-BUILD12015\-05\-045.0~a6-1"Live Systems Project"
.THLIVE\-BUILD12020\-03\-301:20191222"Debian Live Project"
.SHNAME
\fBlbclean\fR\- Clean build directory
\fBlb_clean\fR\- Clean build directory
.SHSYNOPSIS
\fBlb clean\fR [\fIlive\-build options\fR]
\fBlb clean\fR [\fIOPTIONS\fR]
.SHDESCRIPTION
\fBlb clean\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the live systems tool suite.
\fBlb clean\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.PP
.\" FIXME
\fBlb clean\fR is responsible for cleaning up after a system is built. It removes the build directories, and removes some other files including stage files, and any detritus left behind by other live\-build commands.
.\" FIXME
.SHOPTIONS
In addition to its specific options \fBlb clean\fR understands all generic live\-build options. See \fIlive\-build\fR(7) for a complete list of all generic live\-build options.
.PP
.\" FIXME
.IP"\fB\-\-all\fR"4
removes chroot, binary, stage, and source. The cache directory is kept. This is the default operation and will be performed if no argument is given.
.IP"\fB\-\-cache\fR"4
@ -33,12 +30,9 @@ removes everything, including package cache but not stage cache. The config dire
removes all stage files.
.IP"\fB\-\-source\fR"4
removes all source related caches, files, directories, and stage files.
.\" FIXME
.SHFILES
.\" FIXME
.IP"\fBauto/clean\fR"4
.\" FIXME
.SHSEEALSO
\fIlive\-build\fR(7)
@ -46,10 +40,10 @@ removes all source related caches, files, directories, and stage files.
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Live Systems project can be found on the homepage at <\fIhttp://live-systems.org/\fR> and in the manual at <\fIhttp://live-systems.org/manual/\fR>.
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Live Systems mailing list at <\fIdebian-live@lists.debian.org\fR>.
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>.
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
\fBlb config\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the live systems tool suite.
\fBlb config\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.PP
.\" FIXME
\fBlb config\fR populates the configuration directory for live\-build. By default, this directory is named 'config' and is created in the current directory where \fBlb config\fR was executed.
\fBlb config\fR populates the configuration directory for live\-build. This directory is named 'config' and is created in the current directory where \fBlb config\fR was executed.
.PP
Note: Currently \fBlb config\fR tries to be smart and sets defaults for some options depending on the setting of other options (e.g. which linux packages to be used depending on if a wheezy system gets build or not). This means that when generating a new configuration, you should call \fBlb config\fR only once with all options specified. Calling it several times with only a subset of the options each can result in non working configurations. This is also caused by the fact that \fBlb config\fR called with one option only changes that option, and leaves everything else as is unless its not defined. However, \fBlb config\fR does warn about know impossible or likely impossible combinations that would lead to non working live systems. If unsure, remove config/{binary,bootstrap,chroot,common,source} and call \fBlb config\fR again.
.\" FIXME
Note: \fBlb config\fR tries to be smart and sets defaults for some options depending upon the settings of others. However, this only typically happens when no existing saved config exists, because values are only automatically set when not already defined (and running \fBlb config\fR involves loading any existing config). This means that when generating a new configuration, you should typically first ensure that any existing saved config files are removed (by deletion of \fBconfig/{binary,bootstrap,chroot,common,source}\fR), before then calling \fBlb config\fR just once with \fBall\fR necessary options specified. Calling it when an existing saved config exists risks ending up with a non\-working configuration, depending on the options changed, since in doing so other options may end up with different values than they otherwise might have had had automatic setting of them not been blocked by an existing saved value. In some cases invalid combinations will be noticed and reported as an error or warning, but this is not always the case and should not be relied upon.
.SHOPTIONS
In addition to its specific options \fBlb config\fR understands all generic live\-build options. See \fIlive\-build\fR(7) for a complete list of all generic live\-build options.
.PP
.\" FIXME
.IP"\fB\-\-apt\fR apt|aptitude"4
.IP"\fB\-\-apt\fR apt|apt-get|aptitude"4
defines if apt\-get or aptitude is used to install packages when building the image. The default is apt.
.IP"\fB\-\-apt\-ftp\-proxy\fR \fIURL\fR"4
sets the ftp proxy to be used by apt. By default, this is empty. Note that this variable is only for the proxy that gets used by apt internally within the chroot, it is not used for anything else.
.IP"\fB\-\-apt\-http\-proxy\fR \fIURL\fR"4
sets the http proxy to be used by apt. By default, this is empty. Note that this variable is only for the proxy that gets used by apt internally within the chroot, it is not used for anything else.
.IP"\fB\-\-apt\-indices\fR true|false|none" 4
defines if the resulting images should have apt indices or not and defaults to true. If set to none, no indices are included at all.
sets the proxy for HTTP connections. By default, this is empty. It is recommended to use the environment variable \fBhttp_proxy\fR instead.
.IP"\fB\-\-apt\-indices\fR true|false" 4
defines if the resulting images should have apt indices or not and defaults to true.
defines the default options that will be appended to every apt call that is made inside chroot during the building of the image. By default, this is set to \-\-yes to allow non-interactive installation of packages.
defines the default options that will be appended to every aptitude call that is made inside chroot during building of the image. By default, this is set to \-\-assume\-yes to allow non-interactive installation of packages.
defines the default options that will be appended to every apt call that is made inside chroot during the building of the image. By default, this is set to '\-\-yes' to allow non-interactive installation of packages.
.IP"\fB\-\-apt\-pipeline\fR \fIDEPTH\fR"4
sets the depth of the apt/aptitude pipeline. In cases where the remote server is not RFC conforming or buggy (such as Squid 2.0.2) this option can be a value from 0 to 5 indicating how many outstanding requests APT should send. A value of zero MUST be specified if the remote host does not properly linger on TCP connections \- otherwise data corruption will occur. Hosts which require this are in violation of RFC 2068. By default, live\-build does not set this option.
sets the depth of the apt/aptitude pipeline. In cases where the remote server is not RFC conforming or buggy (such as Squid 2.0.2) this option can be a value from 0 to 5 indicating how many outstanding requests apt should send. A value of zero MUST be specified if the remote host does not properly linger on TCP connections \- otherwise data corruption will occur. Hosts which require this are in violation of RFC 2068. By default, live\-build does not set this option.
.IP"\fB\-\-apt\-recommends\fR true|false"4
defines if apt should install recommended packages automatically. By default, this is true.
.IP"\fB\-\-apt\-secure\fR true|false"4
defines if apt should check repository signatures. This is true by default.
.IP"\fB\-\-apt\-source\-archives\fR true|false"4
defines if deb-src entries should be included in the resulting live image or not, defaults to true.
defines the architecture of the to be build image. By default, this is set to the host architecture. Note that you cannot crossbuild for another architecture if your host system is not able to execute binaries for the target architecture natively. For example, building amd64 images on i386 and vice versa is possible if you have a 64bit capable i386 processor and the right kernel. But building powerpc images on an i386 system is not possible.
defines the image type to build. By default, for images using syslinux this is set to iso\-hybrid to build CD/DVD images that may also be used like hdd images, for non\-syslinux images, it defaults to iso.
defines the filesystem to be used in the image type. This only has an effect if the selected binary image type does allow to choose a filesystem. For example, when selection iso the resulting CD/DVD has always the filesystem ISO9660. When building hdd images for usb sticks, this is active. Note that it defaults to fat16 on all architectures except sparc where it defaults to ext4. Also note that if you choose fat16 and your resulting binary image gets bigger than 2GB, the binary filesystem automatically gets switched to fat32.
defines if deb-src entries should be included in the resulting live image's apt sources.list or not, defaults to true.
defines the default options that will be appended to every aptitude call that is made inside chroot during building of the image. By default, this is set to '\-\-assume\-yes' to allow non-interactive installation of packages.
defines the architecture of the to be built image. By default, this is set to the host architecture. Note that you cannot crossbuild for another architecture if your host system is not able to execute binaries for the target architecture natively. For example, building amd64 images on i386 and vice versa is possible if you have a 64bit capable i386 processor and the right kernel. But building powerpc images on an i386 system is not possible.
defines which package archive areas (a comma or space separated list) of a debian package archive should be used for configured debian package mirrors. By default, this is set to main only. Remember to check the licenses of each package with respect to their redistributability in your juristiction when enabling contrib or non\-free with this mechanism.
.IP"\fB\-\-backports\fR true|false"4
defines if debian backports package archives should be included in the image or not.
defines the filesystem to be used in the image type. This only has an effect if the selected binary image type lets you choose a filesystem. For example, for the ISO image type the resulting CD/DVD always has the filesystem ISO9660. When building HDD images for USB sticks, multiple filesystem formats are supported, thus this becomes applicable to allow selection. Note that it defaults to 'fat32' on all architectures. Also note that if you choose 'fat16' and your resulting binary image gets bigger than 2GB, the binary filesystem automatically gets switched to 'fat32'.
defines the image type to build. By default, for images using syslinux, this is set to 'iso\-hybrid' to build CD/DVD images that may also be used like HDD images, for non\-syslinux images, it defaults to 'iso'.
sets boot parameters specific to debian\-live. A complete list of boot parameters can be found in the \fIlive\-boot\fR(7) and \fIlive\-config\fR(7) manual pages.
.IP"\fB\-\-bootloader\fR grub|grub2|syslinux"4
defines which bootloader is being used in the generated image. This has only an effect if the selected binary image type does allow to choose the bootloader. For example, if you build a iso, always syslinux (or more precise, isolinux) is being used. Also note that some combinations of binary images types and bootloaders may be possible but live\-build does not support them yet. \fBlb config\fR will fail to create such a not yet supported configuration and give a explanation about it. For hdd images on amd64 and i386, the default is syslinux.
.IP"\fB\-\-cache\fR true|false"4
defines globally if any cache should be used at all. Different caches can be controlled through the their own options.
.IP"\fB\-\-cache\-indices\fR true|false"4
defines if downloaded package indices and lists should be cached which is false by default. Enabling it would allow to rebuild an image completely offline, however, you would not get updates anymore then.
.IP"\fB\-\-cache\-packages\fR true|false"4
defines if downloaded packages files should be cached which is true by default. Disabling it does save space consumption in your build directory, but remember that you will cause much unnecessary traffic if you do a couple of rebuilds. In general you should always leave it true, however, in some particular rare build setups, it can be faster to refetch packages from the local network mirror rather than to utilize the local disk.
sets which stages should be cached. By default set to bootstrap. As an exception to the normal stage names, also rootfs can be used here which does only cache the generated root filesystem in filesystem.{dir,ext*,squashfs}. This is useful during development if you want to rebuild the binary stage but not regenerate the root filesystem all the time.
.IP"\fB\-\-checksums\fR md5|sha1|sha256|none"4
defines if the binary image should contain a file called md5sums.txt, sha1sums.txt and/or sha256sums.txt. These lists all files on the image together with their checksums. This in turn can be used by live\-boot's built\-in integrity\-check to verify the medium if specified at boot prompt. In general, this should not be false and is an important feature of live system released to the public. However, during development of very big images it can save some time by not calculating the checksums.
.IP"\fB\-\-compression\fR bzip2|gzip|lzip|none"4
defines the compression program to be used to compress tarballs. Defaults to gzip.
sets boot parameters specific to debian\-live failsafe boot entries. A complete list of boot parameters can be found in the \fIlive\-boot\fR(7) and \fIlive\-config\fR(7) manual pages.
defines which bootloaders to use in the generated image. This only has an effect if the selected binary image type lets you choose the bootloader. For example, if you build an ISO then syslinux (or more precise, isolinux) is always used. Also note that not all combinations of binary image types and bootloaders are supported (\fBlb config\fR will fail to create such an unsupported configuration and will give a explanation about it). For HDD images on amd64 and i386, the default is 'syslinux'. This option supports more than one bootloader to be specified (space or comma separated) in order to allow for both BIOS and EFI bootloaders to be included, though note that only one of each type can be used (i.e. do not try to use two BIOS bootloaders).
.IP"\fB\-\-bootstrap\-qemu\-arch\fR \fIARCH\fR"4
sets the architecture to use for foreign bootstrap. Defaults to empty.
sets the static qemu binary for foreign bootstrap. Defaults to empty.
.IP"\fB\-\-breakpoints\fR"4
inserts pauses during the generation of the image, where breakpoints have been placed, if any (development oriented).
.IP"\fB\-\-build\-with\-chroot\fR true|false"4
defines whether live\-build should use the tools from within the chroot to build the binary image or not by using and including the host system's tools. This is a very dangerous option, using the tools of the host system can lead to tainted and even non-bootable images if the host systems version of the required tools (mainly these are the bootloaders such as syslinux and grub, and the auxiliary tools such as dosfstools, xorriso, squashfs-tools and others) do not \fBexactly\fR match what is present at build-time in the target distribution. Never do disable this option unless you are \fBexactly\fR sure what you are doing and have \fBcompletely\fI understood its consequences.
defines which filesystem type should be used for the root filesystem image. If you use none, then no filesystem image is created and the root filesystem content is copied on the binary image filesystem as flat files. Depending on what binary filesystem you have chosen, it may not be possible to build with such a plain root filesystem, e.g. fat16/fat32 will not work as linux does not support to run directly on them.
defines whether live\-build should use the tools from within the chroot to build the binary image or not by using and including the host system's tools. This is a very dangerous option, using the tools of the host system can lead to tainted and even non-bootable images if the host systems version of the required tools (mainly these are the bootloaders such as syslinux and grub, and the auxiliary tools such as dosfstools, xorriso, squashfs-tools and others) do not \fBexactly\fR match what is present at build-time in the target distribution. Never disable this option unless you are \fBexactly\fR sure what you are doing and have \fBcompletely\fR understood its consequences.
.IP"\fB\-\-cache\fR true|false"4
defines globally if any cache should be used at all. Different caches can be controlled through their own options.
.IP"\fB\-\-cache\-indices\fR true|false"4
defines if downloaded package indices and lists should be cached. This is false by default. Enabling it lets you rebuild an image completely offline, however, you would not get updates anymore then.
.IP"\fB\-\-cache\-packages\fR true|false"4
defines if downloaded packages files should be cached. This is true by default. Disabling it does save space consumption in your build directory, but remember that you will cause much unnecessary traffic if you do a couple of rebuilds. In general you should always leave it true, however, in some particular rare build setups, it can be faster to refetch packages from the network mirror, if using a local one, rather than to utilize the local disk.
sets which stages should be cached (a comma or space separated list). By default this is set to 'bootstrap'. As an exception to the normal stage names, 'rootfs' can also be used here which means only cache the generated root filesystem in filesystem.{dir,ext*,squashfs}. This is useful during development if you want to rebuild the binary stage but not regenerate the root filesystem all the time.
defines if the binary image should contain a file called XXXsums.txt, where XXX is one of the mentioned checksum types. This file lists all files on the image together with their checksums. This in turn can be used by \fIlive\-boot\fR(7)'s built\-in integrity\-check to verify the medium if specified at boot prompt. In general, this should not be 'none' and is an important feature of live system released to the public. However, during development of very big images it can save some time by not calculating the checksums.
defines which filesystem type should be used for the root filesystem image. If you use 'none' or 'plain', then no filesystem image is created and the root filesystem content is copied on the binary image filesystem as flat files. Depending on what binary filesystem you have chosen, it may not be possible to build with such a plain root filesystem, e.g. fat16/fat32 will not work as linux does not support running directly on them.
defines the compression level that is used for the root filesystem image if squashfs is used. Each compression algorithm supports different levels (or none). You can look them up in the \fImksquashfs\fR help. Defaults to the default setting in \fImksquashfs\fR.
defines what value the debconf frontend should be set to inside the chroot. Note that setting it to anything but noninteractive, which is the default, makes your build asking questions during the build.
defines what value the debconf frontend should be set to inside the chroot. Note that setting it to anything but 'noninteractive', which is the default, makes your build asking questions during the build.
defines what value the debconf priority should be set to inside the chroot. By default, it is set to critical, which means that almost no questions are displayed. Note that this only has an effect if you use any debconf frontend different from noninteractive.
defines which type, if any, of the debian\-installer should be included in the resulting binary image. By default, no installer is included. All available flavours except live are the identical configurations used on the installer media produced by regular debian\-cd. When live is chosen, the live\-installer udeb is included so that debian\-installer will behave different than usual \- instead of installing the debian system from packages from the medium or the network, it installs the live system to the disk.
defines the distribution where the debian\-installer files should be taken out from. Normally, this should be set to the same distribution as the live system. However, some times, one wants to use a newer or even daily built installer.
defines the distribution where the debian\-installer files should be taken out from. Normally, this should be set to the same distribution as the live system. However, sometimes, one wants to use a newer or even either the \fIdaily\fR built installer or the installer rebuilt from its \fIgit\fR repository.
.IP"\fB\-\-debian\-installer\-gui\fR true|false"4
defines whether the graphical version of the debian\-installer should be provided alongside the text based one. This defaults to true.
sets the filename or URL for an optionally used and included preseeding file for debian\-installer. If config/binary_debian\-installer/preseed.cfg exists, it will be used by default.
.IP"\fB\-\-debian\-installer\-gui\fR true|false"4
defines if the debian\-installer graphical GTK interface should be true or not. In Debian mode and for most versions of Ubuntu, this option is true, whereas otherwise false, by default.
defines the distribution used to build the live system (defaults to the value set in \fB\-\-distribution\fR)
.IP"\fB\-\-dm\-verity\fR"4
Enables dm\-verity support for root file system. Only squashfs, ext2, ext3 and ext4 are supported. For more information see \fIlive\-boot\fR(7).
.IP"\fB\-\-dm\-verity\-fec\fR \fINB_ROOTS\fR"4
Enables forward error correction for dm-verity. \fINB_ROOTS\fR is the number of error correction roots thas should be used. The value can be between 2 and 24. Android uses 2 by default.
Sign root hash of dm-verity device. Script takes two arguments: the root hash and a file to output the signature to.
.IP"\fB\-\-dump\fR"4
prepares a report of the currently present live system configuration and the version of live\-build used. This is useful to provide if you submit bug reports, we do get all informations required for us to locate and replicate an error.
.IP"\fB\-\-fdisk\fR fdisk|fdisk.dist"4
sets the filename of the fdisk binary from the host system that should be used. This is autodetected and does generally not need any customization.
prepares a report of the currently present live system configuration and the version of live\-build used. This is useful to provide if you submit bug reports, helping to provide basic useful information required for us to locate and replicate an error.
.IP"\fB\-\-firmware\-binary\fR true|false"4
includes firmware packages in debian-installer. Defaults to true.
.IP"\fB\-\-firmware\-chroot\fR true|false"4
includes firmware packages in the live image. Defaults to true. Beware that some firmware packages are non-free and will only be included if the non-free archive area is included in \fB\-\-archive\-areas\fR (and \fB\-\-parent\-archive\-areas\fR). This is particularly relevant if you want working wifi for instance.
.IP"\fB\-\-force\fR"4
forces re\-execution of already run stages. Use only if you know what you are doing. It is generally safer to use \fBlb clean\fR to clean up before re\-executing \fBlb build\fR.
.IP"\fB\-\-grub\-splash\fR \fIFILE\fR"4
defines the name of an optional to be included splash screen graphic for the grub bootloader.
defines the default options that will be appended to (almost) every gzip call during the building of the image. By default, this is set to \-\-best to use highest (but slowest) compression. Dynamically, if the host system supports it, also \-\-rsyncable is added.
.IP"\fB\-\-hooks\fR \fIFILE\fR"4
defines which hooks available in /usr/share/live/build/examples/hooks should be activated. Normally, there are no hooks executed. Make sure you know and understood the hook before you enable it.
defines the default options that will be appended to (almost) every gzip call during the building of the image. By default, this is set to '\-\-best' to use highest (but slowest) compression. Dynamically, if the host system supports it, also '\-\-rsyncable' is added.
.IP"\fB\-\-hdd\-label\fR \fILABEL\fR"4
defines the label for the HDD target. Defaults to 'DEBIAN_LIVE'.
.IP"\fB\-\-hdd\-partition\-start\fR \fISTART\fR"4
sets the start of the partition for the HDD target for BIOSes that expect a specific boot partition start (e.g. "63s"). If empty, use optimal layout. Defaults to empty.
.IP"\fB\-\-hdd\-size\fR \fISIZE\fR"4
defines the size for the HDD target. The unit is MiB. Defaults to 'auto', which generates the smallest possible image.
.IP"\fB\-\-ignore\-system\-defaults\fR"4
\fBlb config\fR by default reads system defaults from \fI/etc/live/build.conf\fR and \fI/etc/live/build/*\fR when generating a new live system config directory. This is useful if you want to set global settings, such as mirror locations, and don't want to specify them all of the time.
sets the name of package that contains the live system specific initramfs modification. By default, auto is used, which means that at build time of the image rather than on configuration time, the value will be expanded to casper when building ubuntu systems, to live\-boot for all other systems. Using 'none' is useful if the resulting system image should not be a live image (experimental).
defines the compression program to be used to compress the initramfs. Defaults to gzip.
.IP"\fB\-\-interactive\fR shell"4
defines if after the chroot stage and before the beginning of the binary stage, a interactive shell login should be spawned in the chroot in order to allow you to do manual customizations. Once you close the shell with logout or exit, the build will continue as usual. Note that it's strongly discouraged to use this for anything else than testing. Modifications that should be present in all builds of a live system should be properly made through hooks. Everything else destroys the beauty of being able to completely automatise the build process and making it non interactive. By default, this is of course false.
\fBlb config\fR by default reads system defaults from \fI/etc/live/build.conf\fR and \fI/etc/live/build/*\fR when generating a new live system config directory. This is useful if you want to set global settings, such as mirror locations, and don't want to specify them all of the time. This option allows you to ignore such global settings.
.IP"\fB\-\-image\-name\fR \fINAME\fR"4
sets the base name of the image. Defaults to live-image.
sets the name of the package that contains the live system specific initramfs modification and defaults to live\-boot. Using 'none' is useful if the resulting system image should not be a live image (experimental). Note that dracut requires the CD label in the kernel command line, so you might want to set \fB\-\-iso\-volume\fR explicitly.
defines if after the chroot stage and before the beginning of the binary stage, an interactive shell login should be spawned in the chroot in order to allow you to do manual customizations, or as an alternative to 'true' and 'false' a specific shell to use (note that 'true' corresponds to a value of 'shell'). Once you close the shell with logout or exit, the build will continue as usual. Note that it's strongly discouraged to use this for anything else than testing. Modifications that should be present in all builds of a live system should be properly made through hooks. Everything else destroys the beauty of being able to completely automate the build process and making it non-interactive. By default, this is of course 'false'.
.IP"\fB\-\-iso\-application\fR \fINAME\fR"4
sets the APPLICATION field in the header of a resulting CD/DVD image and defaults to "Debian Live" in debian mode, and "Ubuntu Live" in ubuntu mode.
sets the APPLICATION field in the header of a resulting CD/DVD image and defaults to "Debian Live".
.IP"\fB\-\-iso\-preparer\fR \fINAME\fR"4
sets the PREPARER field in the header of a resulting CD/DVD image. By default this is set to "live\-build \fIVERSION\fR; http://packages.qa.debian.org/live\-build", where VERSION is expanded to the version of live\-build that was used to build the image.
sets the PREPARER field in the header of a resulting CD/DVD image. By default this is set to "live\-build \fIVERSION\fR; https://salsa.debian.org/live-team/live-build", where VERSION is expanded to the version of live\-build that was used to build the image.
.IP"\fB\-\-iso\-publisher\fR \fINAME\fR"4
sets the PUBLISHED field in the header of a resulting CD/DVD image. By default, this is set to 'Live Systems project; http:/live-systems.org/; debian\-live@lists.debian.org'. Remember to change this to the appropriate values at latest when you distributing custom and unofficial images.
sets the PUBLISHED field in the header of a resulting CD/DVD image. By default, this is set to 'Debian Live project; https://wiki.debian.org/DebianLive; debian\-live@lists.debian.org'. Remember to change this to the appropriate value when distributing custom and unofficial images.
.IP"\fB\-\-iso\-volume\fR \fINAME\fR"4
sets the VOLUME field in the header of a resulting CD/DVD and defaults to '(\fIMODE\fR) (\fIDISTRIBUTION\fR) (\fIDATE\fR)' whereas MODE is expanded to the name of the mode in use, DISTRIBUTION the distribution name, and DATE with the current date and time of the generation.
sets the VOLUME field in the header of a resulting CD/DVD and defaults to 'Debian (\fIDISTRIBUTION\fR) (\fIDATE\fR)' where DISTRIBUTION is replaced with the distribution name, and DATE with the current date and time of the generation.
.IP"\fB\-\-jffs2\-eraseblock\fR \fISIZE\fR"4
sets the eraseblock size for a JFFS2 (Second Journaling Flash File System) filesystem. The default is 64 KiB. If you use an erase block size different than the erase block size of the target MTD device, JFFS2 may not perform optimally. If the SIZE specified is below 4096, the units are assumed to be KiB.
sets the kernel flavours to be installed. Note that in case you specify more than that the first will be configured the default kernel that gets booted.
sets the internal name of the kernel packages naming scheme. If you use debian kernel packages, you will not have to adjust it. If you decide to use custom kernel packages that do not follow the debian naming scheme, remember to set this option to the stub of the packages only (for debian this is linux\-image\-2.6), so that \fISTUB\fR-\fIFLAVOUR\fR results in a valid package name (for debian e.g. linux\-image\-586). Preferably you use the meta package name, if any, for the stub, so that your configuration is ABI independent. Also don't forget that you have to include stubs of the binary modules packages for unionfs or aufs, and squashfs if you built them out-of-tree.
.IP"\fB\-\-losetup\fR losetup|losetup.orig" 4
sets the filename of the losetup binary from the host system that should be used. This is autodetected and does generally not need any customization.
sets the kernel flavours to be installed (a space separated list). Note that in case you specify more than one the first will be configured as the default kernel that gets booted. Optionally you can use an architecture qualifier, e.g. amd64:amd64. Given an i386 system you can enable amd64 foreign architecture thanks to the commands: "dpkg \-\-add\-architecture amd64 ; apt\-get update". This enables you to use "686 amd64:amd64" as a linux flavour. The amd64 kernel will be installed alongside the i386's 686 kernel.
defines a space separated list of partial kernel package names. For each name given and for each flavour in \fBLB_LINUX_FLAVOURS_WITH_ARCH\fR (\fB\-\-linux-flavours\fR), '\-FLAVOUR' will be appended to the name to get the names of kernel packages to be included. By default this is 'linux\-image'. So for instance if this is set to "linux\-image linux\-headers" and \fBLB_LINUX_FLAVOURS_WITH_ARCH\fR is "i386 amd64:amd64" then you will get the four packages "linux\-image\-i386", "linux\-image\-amd64:amd64", "linux\-headers\-i386" and "linux\-headers\-amd64:amd64". You can specify "none" to disable the kernel installation step.
.IP"\fB\-\-loadlin\fR true|false" 4
sets loadlin. Defaults to false, except when the debian-installer is included for x86_64 or i386.
.IP"\fB\-\-memtest\fR memtest86+|memtest86|none"4
defines if memtest, memtest86+ or no memory tester at all should be included as secondary bootloader configuration. This is only available on amd64 and i386 and defaults to memtest86+.
sets the location of the debian package mirror that should be used to bootstrap from. This defaults to http://ftp.de.debian.org/debian/ which may not be a good default if you live outside of Europe.
.IP"\fB\-\-parent\-mirror\-chroot\fR \fIURL\fR"4
sets the location of the debian package mirror that will be used to fetch the packages in order to build the live system. By default, this is set to the value of \-\-parent\-mirror\-bootstrap.
sets the location of the debian security package mirror that will be used to fetch the packages in order to build the live system. By default, this points to http://security.debian.org/debian/.
sets the location of the debian updates package mirror that will be used to fetch packages in order to build the live system. By default, this is set to the value of \-\-parent\-mirror\-chroot.
sets the location of the debian backports package mirror that will be used to fetch packages in order to build the live system. By default, this points to http://backports.debian.org/debian-backports/.
.IP"\fB\-\-parent\-mirror\-binary\fR \fIURL\fR"4
sets the location of the debian package mirror that should end up configured in the final image and which is the one a user would see and use. This has not necessarily to be the same that is used to build the image, e.g. if you use a local mirror but want to have an official mirror in the image. By default, 'http://http.debian.net/debian/' is used.
sets the location of the debian security package mirror that should end up configured in the final image. By default, 'http://security.debian.org/' is used.
sets the location of the debian updates package mirror that should end up configured in the final image. By default, the value of \-\-parent\-mirror\-binary is used.
sets the location of the debian backports package mirror that should end up configured in the final image. By default, 'http://backports.debian.org/debian-backports/' is used.
sets the location of the mirror that will be used to fetch the debian installer images. By default, this points to the same mirror used to build the live system, i.e. the value of \-\-parent\-mirror\-bootstrap.
.IP"\fB\-\-mirror\-bootstrap\fR \fIURL\fR"4
sets the location of the debian package mirror that should be used to bootstrap the derivative from. This defaults to http://ftp.de.debian.org/debian/ which may not be a good default if you live outside of Europe.
.IP"\fB\-\-mirror\-chroot\fR \fIURL\fR"4
sets the location of the debian package mirror that will be used to fetch the packages of the derivative in order to build the live system. By default, this is set to the value of \-\-mirror\-bootstrap.
sets the location of the debian security package mirror that will be used to fetch the packages of the derivative in order to build the live system. By default, this points to http://security.debian.org/debian/.
.IP"\fB\-\-mirror\-chroot\-updates\fR \fIURL\fR"4
sets the location of the debian updates package mirror that will be used to fetch packages of the derivative in order to build the live system. By default, this is set to the value of \-\-mirror\-chroot.
sets the location of the debian backports package mirror that will be used to fetch packages of the derivative in order to build the live system. By default, this points to http://backports.debian.org/debian-backports/.
defines if memtest, memtest86+ or no memory tester at all should be included (available as a bootloader menu entry). This is only available on amd64 and i386 and defaults to memtest86+.
.IP"\fB\-\-mirror\-binary\fR \fIURL\fR"4
sets the location of the derivative package mirror that should end up configured in the final image and which is the one a user would see and use. This has not necessarily to be the same that is used to build the image, e.g. if you use a local mirror but want to have an official mirror in the image.
sets the location of the derivative package mirror that should end up configured in the final image and which is the one a user would see and use. This has not necessarily to be the same that is used to build the image, e.g. if you use a local mirror but want to have an official mirror in the image. This defaults to 'http://deb.debian.org/debian/'.
sets the location of the derivatives backports package mirror that should end up configured in the final image.
sets the location of the derivatives security package mirror that should end up configured in the final image. This defaults to 'http://security.debian.org/'.
.IP"\fB\-\-mirror\-bootstrap\fR \fIURL\fR"4
sets the location of the debian package mirror that should be used to bootstrap the derivative from. This defaults to 'http://deb.debian.org/debian/'.
.IP"\fB\-\-mirror\-chroot\fR \fIURL\fR"4
sets the location of the debian package mirror that will be used to fetch the packages of the derivative in order to build the live system. By default, this is set to the value of \fB\-\-mirror\-bootstrap\fR.
sets the location of the debian security package mirror that will be used to fetch the packages of the derivative in order to build the live system. By default, this points to 'http://security.debian.org/'.
sets the location of the mirror that will be used to fetch the debian installer images of the derivative. By default, this points to the same mirror used to build the live system, i.e. the value of \-\-mirror\-bootstrap.
.IP"\fB\-\-mode\fR debian|progress|ubuntu" 4
sets the location of the mirror that will be used to fetch the debian installer images of the derivative. By default, this points to the same mirror used to build the live system, i.e. the value of \fB\-\-mirror\-chroot\fR.
.IP"\fB\-\-mode\fR debian"4
defines a global mode to load project specific defaults. By default this is set to debian.
.IP"\fB\-\-system\fR live|normal"4
defines if the resulting system image should a live system or a normal, non-live system.
.IP"\fB\-\-net\-root\-filesystem\fR nfs|cfs"4
defines the filesystem that will be configured in the bootloader configuration for your netboot image. This defaults to nfs.
sets additional options for mounting the root filesystem in netboot images and is by default empty.
.IP"\fB\-\-net\-root\-path\fR \fIPATH\fR"4
sets the file path that will be configured in the bootloader configuration for your netboot image. This defaults to /srv/debian\-live in debian mode, and /srv/ubuntu-live when in ubuntu mode.
sets the IP or hostname that will be configured in the bootloader configuration for the root filesystem of your netboot image. This defaults to 192.168.1.1.
.IP"\fB\-\-net\-cow\-filesystem\fR nfs|cfs"4
defines the filesystem type for the copy\-on\-write layer and defaults to nfs.
sets additional options for mounting the copy\-on\-write layer in netboot images and is by default empty.
.IP"\fB\-\-net\-cow\-path\fR \fIPATH\fR"4
defines the path to client writable filesystem. Anywhere that \fIclient_mac_address\fR is specified in the path live\-boot will substitute the MAC address of the client delimited with hyphens.
sets the IP or hostname that will be configured in the bootloader configuration for the copy\-on\-write filesystem of your netboot image and is by default empty.
.IP"\fB\-\-net\-tarball\fR true|false"4
defines if a compressed tarball should be created. Disabling this options leads to no tarball at all, the plain binary directory is considered the output in this case. Default is true.
defines if a compressed tarball should be created. If disabled, the plain binary directory is considered the output. Default is true.
.IP"\fB\-\-no\-color\fR"4
turns off color in the messages.
.IP"\fB\-\-onie\fR true|false"4
defines if an ONIE.bin image is generated. ONIE binaries can be loaded by supported systems, and will in turn boot the live image. Note that ISO or hybrid-iso are the only formats supported. For more information visit <\fIhttp://onie.org/\fR>. Default is false.
defines the derivative's parent distribution used to build the live system.
.IP"\fB\-\-parent\-mirror\-binary\fR \fIURL\fR"4
sets the location of the debian package mirror that should end up configured in the final image and which is the one a user would see and use. This has not necessarily to be the same that is used to build the image, e.g. if you use a local mirror but want to have an official mirror in the image. This defaults to the value of \fB\-\-mirror\-binary\fR.
sets the location of the debian security package mirror that should end up configured in the final image. This defaults to the value of \fB\-\-mirror\-binary\-security\fR.
sets the location of the debian package mirror that should be used to bootstrap from. This defaults to the value of \fB\-\-mirror\-bootstrap\fR.
.IP"\fB\-\-parent\-mirror\-chroot\fR \fIURL\fR"4
sets the location of the debian package mirror that will be used to fetch the packages in order to build the live system. This defaults to the value of \fB\-\-parent\-mirror\-bootstrap\fR.
sets the location of the debian security package mirror that will be used to fetch the packages in order to build the live system. This defaults to the value of \fB\-\-mirror\-chroot\-security\fR.
sets the location of the mirror that will be used to fetch the debian installer images. This defaults to the value of \fB\-\-parent\-mirror\-chroot\fR.
.IP"\fB\-\-quiet\fR"4
reduces the verbosity of messages output by \fBlb build\fR.
defines which package archive areas of a debian packages archive should be used for configured debian package mirrors. By default, this is set to main. Remember to check the licenses of each packages with respect to their redistributability in your juristiction when enabling contrib or non\-free with this mechanism.
defines the archive areas for derivatives of the resulting live system.
.IP"\fB\-\-security\fR true|false"4
defines if the security repositories specified in the security mirror options should be used or not.
.IP"\fB\-\-source\fR true|false"4
defines if a corresponding source image to the binary image should be build. By default this is false because most people do not require this and would require to download quite a few source packages. However, once you start distributing your live image, you should make sure you build it with a source image alongside.
defines the image type for the source image. Default is tar.
.IP"\fB\-\-firmware\-binary\fR true|false"4
defines if firmware packages should be automatically included into the binary pool for debian\-installer. Note that only firmware packages available within the configured archive areas are included, e.g. an image with packages from main only will not automatically include firmware from non\-free. This option does not interfere with explicitly listed packages in binary package lists.
.IP"\fB\-\-firmware\-chroot\fR true|false"4
defines if firmware packages should be automatically included into the live image. Note that only firmware packages available within the configured archive areas are included, e.g. an image with packages from main only will not automatically include firmware from non\-free. This option does not interfere with explicitly listed packages in chroot package lists.
defines if a corresponding source image to the binary image should be built. By default this is false because most people do not require this and it involves downloading quite a few source packages. However, if you distribute your live image to others, you should make sure you build it with a source image alongside to help enable you to comply with licensing terms.
defines the image type for the source image. Default is tar. More than one can be specified (a comma or space separated list).
.IP"\fB\-\-swap\-file\-path\fR \fIPATH\fR"4
defines the path to a swap file to create in the binary image. Default is not to create a swap file.
.IP"\fB\-\-swap\-file\-size\fR \fIMB\fR"4
defines what size in megabytes the swap file should be, if one is to be created. Default is 512MB.
.IP"\fB\-\-tasksel\fR apt|aptitude|tasksel"4
selects which program is used to install tasks. By default, this is set to tasksel.
.IP"\fB\-\-templates\fR \fIPATH\fR"4
sets the path to the templates that live\-build is going to use, e.g. for bootloaders. By default, this is set to /usr/share/live/build/templates/.
.IP"\fB\-\-hdd\-size\fR MB"4
defines what size the hdd image should be. Note that although the default is set to 10000 (= 10GB), it will not need 10GB space on your harddisk as the files are created as sparse files.
.IP"\fB\-\-system\fR live|normal"4
defines if the resulting system image should be a live system or a normal, non-live system. Defaults to live.
enables or disables Secure Boot support when using grub-efi, by installing signed shim and grub-efi packages. By default, this is set to auto, which means if the packages are available they will be installed, but if not only a warning will be printed and the normal non-signed grub-efi will be used.
.IP"\fB\-\-updates\fR true|false"4
defines if debian updates package archives should be included in the image or not.
.IP"\fB\-\-backports\fR true|false"4
defines if debian backports package archives should be included in the image or not.
.IP"\fB\-\-utc\-time\fR true|false"4
defines if timestamps should be UTC. Default is false, unless SOURCE_DATE_EPOCH is set. Note, this does not affect the build log which remains local time.
.IP"\fB\-\-validate\fR"4
requests that the config be validated only, not changed, thus after the validation check the script ends rather than writing an updated config. Please note that at the time of writing, many options do not have corresponding validation checks.
.IP"\fB\-\-verbose\fR"4
increases the verbosity of messages output by \fBlb build\fR.
.IP"\fB\-\-win32\-loader true|false" 4
.IP"\fB\-\-win32\-loader\fR true|false" 4
defines if win32\-loader should be included in the binary image or not.
.\" FIXME
.IP"\fB\-\-zsync\fR true|false"4
defines whether a file for distributing the image in \fIzsync\fR(1) format will be generated. Defaults to false.
.SHENVIRONMENT
.\" FIXME
Currently, command line switches can also be specified through the corresponding environment variable. However, this generally should not be relied upon, as it is an implementation detail that is subject to change in future releases. For options applying directly to live\-build, environment variables are named LB_FOO, meaning, e.g. \fB\-\-apt\-ftp\-proxy\fR becomes LB_APT_FTP_PROXY (the exception being internal options such as \fB\-\-debug\fR). For options passed to another program, as in APT_OPTIONS or GZIP_OPTIONS, no LB_ prefix is used.
\" FIXME
Currently, command line switches can also be specified through the corresponding environment variable. However, this generally should not be relied upon, as it is an implementation detail that is subject to change in future releases. For options applying directly to live\-build, environment variables are named LB_FOO, meaning, e.g. \fB\-\-apt\-http\-proxy\fR becomes \fBLB_APT_HTTP_PROXY\fR (the exception being internal options such as \fB\-\-debug\fR). For options passed to another program, as in APT_OPTIONS or GZIP_OPTIONS, no LB_ prefix is used.
An optional, global configuration file for \fBlb config\fR variables. It is useful to specify a few system wide defaults, like LB_PARENT_MIRROR_BOOTSTRAP. This feature can be false by specifying the \fB\-\-ignore\-system\-defaults\fR option.
.\" FIXME
An optional, global configuration file for \fBlb config\fR variables. It is useful to specify a few system wide defaults, like \fBLB_PARENT_MIRROR_BOOTSTRAP\fR. This feature can be disabled by using the \fB\-\-ignore\-system\-defaults\fR option.
.SHSEEALSO
\fIlive\-build\fR(7)
@ -476,10 +481,10 @@ An optional, global configuration file for \fBlb config\fR variables. It is usef
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Live Systems project can be found on the homepage at <\fIhttp://live-systems.org/\fR> and in the manual at <\fIhttp://live-systems.org/manual/\fR>.
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Live Systems mailing list at <\fIdebian-live@lists.debian.org\fR>.
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>.
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
.THLIVE\-BUILD12020\-03\-301:20191222"Debian Live Project"
.SHNAME
\fBlb_installer\fR\- Complete the installer stage
.SHSYNOPSIS
\fBlb installer\fR [\fIOPTIONS\fR]
.SHDESCRIPTION
\fBlb installer\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.PP
\fBlb installer\fR calls all necessary live\-build programs in the correct order to complete the installer stage.
.SHOPTIONS
\fBlb installer\fR has no specific options but understands all generic live\-build options. See \fIlive\-build\fR(7) for a complete list of all generic live\-build options.
.SHFILES
.IP"\fBnone\fR"4
.SHSEEALSO
\fIlive\-build\fR(7)
.PP
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bug report for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
.THLIVE\-BUILD12015\-05\-045.0~a6-1"Live Systems Project"
.THLIVE\-BUILD12020\-03\-301:20191222"Debian Live Project"
.SHNAME
\fBlbsource\fR\- Complete the source stage
\fBlb_source\fR\- Complete the source stage
.SHSYNOPSIS
\fBlb source\fR [\fIlive\-build options\fR]
\fBlb source\fR [\fIOPTIONS\fR]
.SHDESCRIPTION
\fBlb source\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the live systems tool suite.
\fBlb source\fR is a high\-level command (porcelain) of \fIlive\-build\fR(7), the Debian Live tool suite.
.PP
\fBlb source\fR calls all necessary live\-build programs in the correct order to complete the source stage.
@ -23,10 +23,10 @@
This program is a part of live\-build.
.SHHOMEPAGE
More information about live\-build and the Live Systems project can be found on the homepage at <\fIhttp://live-systems.org/\fR> and in the manual at <\fIhttp://live-systems.org/manual/\fR>.
More information about live\-build and the Debian Live project can be found on the homepage at <\fIhttps://wiki.debian.org/DebianLive\fR>.
.SHBUGS
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Live Systems mailing list at <\fIdebian-live@lists.debian.org\fR>.
Bugs can be reported by submitting a bugreport for the live\-build package in the Bug Tracking System at <\fIhttp://bugs.debian.org/\fR> or by writing a mail to the Debian Live mailing list at <\fIdebian-live@lists.debian.org\fR>.
.SHAUTHOR
live\-build was written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>.
live\-build was originally written by Daniel Baumann <\fImail@daniel-baumann.ch\fR>. Since 2016 development has been continued by the Debian Live team.
Some files were not shown because too many files have changed in this diff
Show More
Roland Clobus
Aaron Rainbolt
Nick Brown
Emanuele Rocca
Luca Boccassi
Helmut Grohne
Marcel Partap
Patrick Schleizer
Unit 193
Arnaud Rebillout
jfliu
David Hewitt
Thore Sommer
Jonathan Carter
Patrice Duroux
Raphaël Hertzog
snip
Ryan Finnie
Olivier BLIN
Rob Shearman
Philip Hands
Michał Prochera
Sophie Brun
Luca Boccassi
Unit 193
Raphaël Hertzog
Steev Klimaszewski
Jan Kot
Matthijs Kooijman
Victor Gavro
Lyndon Brown
johnraff
adrian15
Steven Shiau
John Estabrook
Ronny Standtke
Adrian Gibanel Lopez
Hideki Yamane
Steven Shiau
Rohan Garg
Steve McIntyre
Balint Reczey
Sjoerd Simons
Sophie Brun
Kristian Klausen
Iain R. Learmonth
Ben Armstrong
trebmuh
Carlos Zuferri
Maximilian Mehnert
Daniel Baumann
Daniel Reichelt
Raphaël Hertzog