| Age | Commit message (Collapse) | Author |
|---|
|
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"
|
|
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>
|
|
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
|
|
* Update the manual page with the missiong --bootappend-live-failsafe
option.
* Keep supporting the former --bootloader (without s).
|
|
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
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
|
|
Ubuntu switched to systemd too, no point in keeping
upstart support arround anymore.
|
|
Future live-build versions will still allow to use casper,
but its configuration will be done differently by a custom
config tree, rather than embedded and maintenance intensive
code in live-build itself.
|
|
Future live-build versions will still allow to use casper,
but its configuration will be done differently by hooks
in the config tree, rather than embedded and maintenance intensive
code in live-build itself.
|
|
Really soon live-build will support building non-live images out-of-the-box.
Therefore moving hooks into a live specific subdirectory.
|
|
|
|
|
|
|
|
debootstrap is the official tool to bootstrap debian,
cdebootstrap has had the one or other bug making it
broken for times during the release cycles.
The extra effort of supporting both debootstrap
and cdebootstrap is hardly worth it since the bootstrap
stage is cached anyway.
|
|
|
|
|
|
#769635).
|
|
from Rui Miguel P. Bernardo <rui.bernardo.pt@gmail.com> (Closes: #772522, #772651).
This however will still not work properly building upstart based
images but they have been broken/unsupported anyway since a long
time.
|
|
|
|
--clean, thanks to jnqnfe <jnqnfe@gmail.com> (Closes: #770637).
|
|
|
|
|
|
|
|
|
|
jessie+1 cycle rather than go with the current mixed code.
|
|
(Closes: #744365).
|
|
|
|
|
|
|
|
In the past, we had lb config for both creating a configuration directory
and updating settings in there. With the rewrite in Python, we're now
changing this finally to the more sane 'init' (create initial 'sample'
configuration directory tree, taking most arguments that lb config did)
and 'config' which will only be a get/set program to work on top of
an already initialized configuration tree.
|
|
config directory.
|
|
|
|
not a runtime thing and its logic should not be embedded in live-build but the config directory.
|
|
|
|
This might come back in future if there's demand for it
and the base is sufficiently cleaned up first.
|
|
develop-ment-version warning message.
|
|
the internal version.
|
|
|
|
/usr/share/live/build/archives (same as with packagelists, hidden archive 'magic' is gone now in favour of explicit config tree configuration).
|
|
|
|
|
|
up properly.
|
|
different defaults.
|
|
|
