| Age | Commit message (Collapse) | Author |
|---|
|
That way it becomes possible to customize grub-efi files.
Closes: #940846
|
|
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
|
|
Use a similar trick as for chroot_live-packages.
Relates to #944983.
|
|
Closes: #944983
|
|
Instead of emptying the file temporarily, just tell APT to use /dev/null
instead of /var/lib/dpkg/status. Relates to #944983
|
|
|
|
|
|
|
|
|
|
|
|
handling for ubuntu was dropped 2015-05-03
|
|
--hdd-partition-start
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in the command line get ignored. Adds a documentation line for the other
command line options as well.
|
|
-f was --filesystem
-l was --language
-p was --package-list
-e was --encryption
|
|
functionality was added 2008-11-01, but was not really active.
|
|
|
|
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.
|
|
not be ignored.
|
|
With the merged /usr feature now enabled in debootstrap, we have
/bin and /lib which are symlinks to /usr/bin and /usr/lib. If
the live-build configuration provides files in
config/includes.chroot/lib/ or config/includes.chroot/bin/ then
lb chroot_includes will replace the /lib or /bin symlink with real
directories having only the content provided in chroot.includes and
problems will follow... the build will usually fail later with a
cryptic error message (for example a hook failing to execute
/usr/bin/env).
Work around the issue by creating a tarball of the files to install
and by unpacking that tarball from within the chroot with appropriate
options.
|
|
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.
|
|
Gbp-Dch: Ignore
|
|
A very minimal build worker might not have it, so check for its
presence as well.
|
|
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
|
|
Closes: #885692
Fixes: !2
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
|
|
We already require qemu-user-static for this case, we might as well rely
on the qemu-debootstrap script that this package provides.
Closes: #847919
|
|
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 a15b579652e64 (#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
|
|
/sbin/mkfs.nfts -> /sbin/mkfs.ntfs
|
|
[hertzog@debian.org:
- Fix conflicts due to renamed variables
]
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
|
|
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>
|
|
old 486 one.
[hertzog@debian.org:
Also rename the variables for consistency.
]
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
|
|
Thanks to Daniel Reichelt <debian@nachtgeist.net> for the patch.
Closes: #881941
|
|
Signed-off-by: Raphaël Hertzog <hertzog@debian.org>
|
