With linux-image-cloud-amd64 we only need ~96MB of disk space, whereas
the corresponding linux-image-amd64 takes about 317MB of disk space.
Also there's usually no need to install linux-headers and firmware
packages inside a VM, so skip those as well.

Closes: grml/grml-debootstrap#178

Fixes: d88d27d7 ("drop enabled config variables from config file and use defaults")

This follows up on commit 9ae6b12a ("Avoid installation of os-proper in
VM environments"). *os-prober* is recommended by *grub-pc*, so do not
list it explicitly, in case alternatives arise, and the recommended
packages of *grub-pc* are adapted.

Follow commit 01b5b0ff ("Support F2FS in VMs by including f2fs driver in
grub-mkimage") to support XFS. I’d say, open-coding three entries is
alright but for more entries a generic solution would be nice.

Fixes: 01b5b0ff ("Support F2FS in VMs by including f2fs driver in grub-mkimage")

CONFIG_EFI_VARS is no longer available since
https://salsa.debian.org/kernel-team/linux/-/commit/20146398c4599147244ed3ffc54f38d07fb8dea3
(tagged initially as debian/5.10.1-1_exp1 + shipped with kernel package
5.10.1-1~exp1 and newer, incl. 5.10.38-1 as present in current
Debian/unstable). Therefore the kernel module efivars is no longer
available on more recent Debian kernel systems.

Quoting from https://wiki.debian.org/UEFI:

| The older interface was efivars, showing files under
| /sys/firmware/efi/vars, and this is what was used by default in both
| Wheezy and Jessie.
|
| The new interface is efivarfs, which will expose things in a slightly
| different format under /sys/firmware/efi/efivars. This is the new
| preferred way of using UEFI configuration variables, and Debian switched
| to it by default from Stretch onwards.

CONFIG_EFI_VARS is no longer required, instead efivarfs seems to be
available starting with kernel v3.10 and newer (see linux.git):

| commit a9499fa7cd3fd4824a7202d00c766b269fa3bda6
| Author: Tom Gundersen <teg@jklm.no>
| Date:   Fri Feb 8 15:37:06 2013 +0000
|
|     efi: split efisubsystem from efivars
|
|     This registers /sys/firmware/efi/{,systab,efivars/} whenever EFI is enabled
|     and the system is booted with EFI.
|
|     This allows
|      *) userspace to check for the existence of /sys/firmware/efi as a way
|         to determine whether or it is running on an EFI system.
|      *) 'mount -t efivarfs none /sys/firmware/efi/efivars' without manually
|         loading any modules.
|
|     [ Also, move the efivar API into vars.c and unconditionally compile it.
|       This allows us to move efivars.c, which now only contains the sysfs
|       variable code, into the firmware/efi directory. Note that the efivars.c
|       filename is kept to maintain backwards compatability with the old
|       efivars.ko module. With this patch it is now possible for efivarfs
|       to be built without CONFIG_EFI_VARS - Matt ]

and:

| commit d68772b7c83f4b518be15ae96f4827c8ed02f684
| Author: Matt Fleming <matt.fleming@intel.com>
| Date:   Fri Feb 8 16:27:24 2013 +0000
|
|     efivarfs: Move to fs/efivarfs
|
|     Now that efivarfs uses the efivar API, move it out of efivars.c and
|     into fs/efivarfs where it belongs. This move will eventually allow us
|     to enable the efivarfs code without having to also enable
|     CONFIG_EFI_VARS built, and vice versa.
|
|     Furthermore, things like,
|
|         mount -t efivarfs none /sys/firmware/efi/efivars
|
|     will now work if efivarfs is built as a module without requiring the
|     use of MODULE_ALIAS(), which would have been necessary when the
|     efivarfs code was part of efivars.c.

Thanks to Volodymyr Fedorov + Manuel Montecelo for spotting this

os-prober is known to cause problems in certain environments,
and might cause update-grub in the chroot to hang. The os-proper
package is a recommends of the grub-common package, so let's
install grub-pc by disabling recommends.

As reported on IRC by Paul Menzel.

If `dpkg --print-architecture` isn't available for detecting the current
architecture (e.g. on non-Debian), and neither $ARCH is set nor `--arch
...` was specified, abort and inform user about it.

Closes: grml/grml-debootstrap#173

This includes recent changes as integrated at
https://github.com/sipwise/deployment-iso



Makefile:

- Fix gcc argument order: newer gcc versions have become more picky on
  their argument order, due to the --as-needed default, and require the
  libraries to be linked to, to be passed after the code/objects that
  use them, otherwise they will get dropped as unused. This change is
  required for compiling with gcc v10.2.1-6 as present on
  Debian/bullseye (otherwise fails to execute with `undefined symbol:
  dlsym`)
- Add `make check` target to run some basic tests
- Also get rid of *.o *.so files in clean target, adjust targets
  accordingly to always clean and then build fake-uname.so afterwards
- Mark as serial-only via .NOTPARALLEL

fake-uname.c:

- Use hidden visibility by default, and export the symbol explicitly.
- Resolve real_uname() only once.
- Return early if the real_uname() fails, to avoid acting on bogus data.
- Call dlerror() before dlsym() to clear any previous errors.
- Compute the release member size from the utsname struct instead of
  hard-coding it.
- Always NUL-terminate the relese buffer, so protect against very long
  environment strings.
- Make various variables into const.

Acked-by: Guillem Jover <gjover@sipwise.com>
Thanks: Guillem Jover

As present in current Debian/unstable

This used to work fine until dosfstools 4.1:

| root@grml ~ # mkfs.fat -F32 -n "EFI System Partition" /dev/loop1
| mkfs.fat 4.1 (2017-01-24)
| mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows

Now with dosfstools >=4.2 it's failing though:

| root@grml ~ # mkfs.fat -F32 -n "EFI System Partition" /dev/loop1
| mkfs.fat 4.2 (2021-01-31)
| mkfs.fat: Label can be no longer than 11 characters

So instead use "EFI" as filesystem label, to not fail with newer dosfstools.

Closes: #987014
Closes: grml/grml-debootstrap#168

Fixes:

| [   94.941005] F2FS-fs (sda1): Unrecognized mount option "errors=remount-ro" or missing value
| mount: /: mount point not mounted or bad option

Closes: grml/grml-debootstrap#163

Thanks: Paul Menzel for bugreport and bugfix
Closes: grml/grml-debootstrap#164

This avoids having output like follows in Jenkins console output:

| �[32;01m*�[0m grml-debootstrap [0.93] - Please recheck configuration before execution:

Closes: grml/grml-debootstrap#159

We want to use Debian/bullseye as default release within the
grml-debootstrap version that's going to be shipped with bullseye,
so let's be prepared for this.

FTR: *not* modifying the Travis CI related configuration files with this
change, as the unstable builds on Travis CI are known to be unreliable.
Travis CI also seems to be a dead end for us, so it's not worth putting
any further efforts into it, at least for the time being.

The packer template worked with packer v1.5.6, but fails
with more recent versions like v1.6.5.

Fixed via `packer fix debian64.json`, using packer v1.6.5.

Thanks: Darshaka Pathirana for reporting
Closes: grml/grml-debootstrap#162

If the configuration includes KEEP_SRC_LIST='no',
then it behaves as if it's set to 'yes', as we were
just checking whether it's set or not.

Closes: grml/grml-debootstrap#160

It might be possible that we can load the efivars module, while
/sys/firmware/efi still doesn't exist and efibootmgr then fails
to execute.

We noticed this on Hetzner's Dell PowerEdge™ R6515 DX181 server,
which was booted in BIOS mode via PXE, while the hardware itself
is EFI capable. Loading the efivars module worked there, but
invoking efibootmgr then fails, and the resulting system isn't
bootable.

Thanks: Darshaka Pathirana for reporting and feedback

Fixes:

|    mkdir -m 0700 -p "${AUTHORIZED_KEYS_TARGET}"
|          ^-- SC2174: When used with -p, -m only applies to the deepest directory.

Closes: #158

Fixes:

| ==> virtualbox-iso: bats warning: duplicate test name(s) in /tmp/debian64.bats: test_home_directory_for_user_vagrant

While at it, drop compression_level (it's set to level 6 by default
so let's use that unless we've a good reason to choose something
different), see https://www.packer.io/docs/post-processors/vagrant/

Quoting from https://packages.qa.debian.org/g/grml-debootstrap.html

| Issues preventing migration:
| Not built on buildd: arch all binaries uploaded by mika, a new source-only upload is needed to allow migration

Sigh...