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
Lyndon Brown
adrian15
Luca Boccassi