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.
Raphaël Hertzog
Sjoerd Simons
Sophie Brun
Adrian Gibanel Lopez
Kristian Klausen
Iain R. Learmonth
Ben Armstrong
trebmuh
Carlos Zuferri
Maximilian Mehnert
Daniel Baumann