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
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
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
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
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
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
...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
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
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
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
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
`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
Lyndon Brown
adrian15