We pass the requested --grub … device argument to the GRUB package
configuration, like:

| # debconf-show grub-pc | grep grub-pc/install_devices:
| * grub-pc/install_devices: /dev/sda

But the GRUB package tries to use /dev/disk/by-id/... for
install_devices setting (since 2010 and Debian/squeeze AFAICS), as can
be observed by reconfiguring the GRUB package (which then automatically
converts the /dev/sdX to the proper /dev/disk/by-id/... device when
being asked in the debconf prompt):

| # dpkg-reconfigure grub-pc
| grub-pc: Running grub-install ...
| [...]
| # debconf-show grub-pc | grep grub-pc/install_devices:
| * grub-pc/install_devices: /dev/disk/by-id/ata-VBOX_HARDDISK_VBf4f4391c-6316fa69

The available_ids() and device_to_id() helper functions are based on
code by Colin Watson <cjwatson@debian.org> in GRUB's postinst script
of the Debian package, see git commits 4830efd9e + ce2a43c85 at
https://salsa.debian.org/grub-team/grub.git.

Closes: https://github.com/grml/grml-debootstrap/issues/206

As of e2fsprogs v1.43 and Linux kernel v4.4 the ext4 file system supports
the new metadata_csum_seed feature (which allows the file system UUID to
be modified without needing to update all of the file system metadata).
Also see https://bugs.debian.org/1031325

Starting with e2fsprogs v1.47 this new metadata_csum_seed feature gets
enabled by default. When installing an older Debian release this might
cause problems because it's not fully supported yet, see e.g. the GRUB
failure documented as #866603.

To keep the behavior identical to Debian, we do not enable the
metadata_csum_seed feature for Debian releases before bookworm.  This is
relevant for us, as grml-debootstrap might be running from a more recent
Debian release (like a Debian testing/unstable based Grml live system).

We check for the e2fsprogs version as versions before 1.43 didn't support
the metadata_csum_seed option yet.

Closes: #1031416
Closes: https://github.com/grml/grml-debootstrap/issues/204

Avoid depending on git.grml.org service which we might deprecate

The git protocol is discouraged and insecure.

We consider deprecating our git.grml.org service and
also the git protocol is insecure and should be avoided,
update debian/control + debian/copyright accordingly.

There's no point in suggesting EOL releases in the dialog(1) dialog any
longer, so let's drop lenny, squeeze, wheezy, jessie + stretch there.
While at it switch from X.Y to X version schema as we always install
the latest Debian (point) release and not the displayed X.0 one.

Use bookworm as the new default release so we get grml-debootstrap
accordingly into the bookworm freeze (see
https://release.debian.org/testing/freeze_policy.html for details).

Update the docs regarding support releases.

If the --non-free option gets enabled packages like 'firmware-linux',
'firmware-linux-nonfree', 'firmware-misc-nonfree' should be available.
Starting with Debian/bookworm the firmware related packages got moved
from "non-free" to the new "non-free-firmware" component/repository though
(related to https://www.debian.org/vote/2022/vote_003).

Also XFS doesn't support the errors=remount-ro option, but instead of
disabling the option for file systems that don't support it, let's
only enable it for the once that support it (according to linux's
source).

Thanks: Chris Hofstaedtler for the bug report
Closes: https://github.com/grml/grml-debootstrap/issues/199

When installing to an XFS root partition, update-initramfs complains:

| update-initramfs: Generating /boot/initrd.img-5.10.0-19-amd64
| W: /sbin/fsck.xfs doesn't exist, can't install to initramfs

Let's make sure to have the according filesystem package available.

FTR, no need for handling ext* + e2fsprogs, as this is available anyways
due to `Priority: required`.

Also, the "--filesystem jfs" isn't supported by default (as mkfs.jfs
expects user input unless invoked with -q, something we might wanna
automate in the future?), but someone can prepare it manually and
install it to the mounted file system, so let's also handle this.

Thanks: Chris Hofstaedtler for the bug report
Closes: https://github.com/grml/grml-debootstrap/issues/200

FTR, grml_iso_checksum = sha1sum and we need to use
http://download.grml.org/devel/ as download directory,
as 2022.11-rc1 is not yet a stable release.

Our partition creation process inside VMs used parted with "mkpart
primary ext4 2M -1", which could end up with unaligned partitions (as
reported in #185):

| (parted) mkpart primary ext4 2M -1
| Warning: The resulting partition is not properly aligned for best performance: 3906s % 4096s != 0s

This depends on the I/O settings of the underlying storage.

The mkpart start at "2M" is interpreted as 2 Megabyte (2000000 bytes or
3906 sectors) from the disk start.  The end "-1" is interpreted as 1
Megabyte (1000000 bytes or 1953 sectors) before the disk end.

On the other hand, "2MiB" is interpreted as 2 Mebibyte (2097152 bytes or
4096 sectors) from the disk start, and "100%" is interpreted as the disk
end.

Quoting from https://www.gnu.org/software/parted/manual/html_node/unit.html:

| Parted will compute sensible ranges for the locations you specify (e.g.,
| a range of +/- 500 MB when you specify the location in “G”, and a range
| of +/- 500 KB when you specify the location in “M”) and will select the
| nearest location in this range from the one you wrote that satisfies
| constraints from both the operation, the filesystem being worked on, the
| disk label, other partitions and so on.
| [...]
| Note that as of parted-2.4, when you specify start and/or end values
| using IEC binary units like “MiB”, “GiB”, “TiB”, etc., parted treats
| those values as exact, and equivalent to the same number specified in
| bytes (i.e., with the “B” suffix), in that it provides no “helpful”
| range of sloppiness. Contrast that with a partition start request of
| “4GB”, which may actually resolve to some sector up to 500MB before or
| after that point. Thus, when creating a partition, you should prefer
| to specify units of bytes (“B”), sectors (“s”), or IEC binary units
| like “MiB”, but not “MB”, “GB”, etc.

Furthermore quoting from https://www.gnu.org/software/parted/manual/html_node/mkpart.html#FOOT2:

| Cheap flash drives will be with us for a long time to come, and, for
| them, 1MiB alignment is not enough. Use at least 4MiB-aligned
| partitions. For details, see Arnd Bergman’s article,
| http://lwn.net/Articles/428584/ and its many comments.

A better default should be usage of an IEC binary unit with a
4MiB-aligned partition, so let's switch to "4MiB 100%".

Thanks: David Gnedt for the bug report and analysis, Darshaka Pathirana and Chris Hofstaedtler for further information and feedback
Closes: grml/grml-debootstrap#185

More recent versions of apt no longer accept unsigned repositories, and fail with:

| The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 21E0CA38EA2EA4AB
| Reading package lists... Done
| W: GPG error: http://deb.grml.org grml-stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 21E0CA38EA2EA4AB
| E: The repository 'http://deb.grml.org grml-stable InRelease' is not signed.
| N: Updating from such a repository can't be done securely, and is therefore disabled by default.
| N: See apt-secure(8) manpage for repository creation and user configuration details.

By enabling the Acquire::AllowInsecureRepositories=1 option, we can avoid this failure:

| W: GPG error: http://deb.grml.org grml-stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 21E0CA38EA2EA4AB
| W: The repository 'http://deb.grml.org grml-stable InRelease' is not signed.
| N: Data from such a repository can't be authenticated and is therefore potentially dangerous to use.
| N: See apt-secure(8) manpage for repository creation and user configuration details.

While at it:

* simplify code
* don't check for "grml" inside /etc/apt/sources.list.d/grml.list,
  instead assume the file was set up as needed if it exists already
* improve apt pinning configuration:
  - no need to pin Grml *and* Debian repositories, instead let's
    set up only the Grml repository and reduce it to a pinning of 100
  - use /etc/apt/preferences.d/grml.pref instead of /etc/apt/preferences
* drop direct gpg usage, this is error prone (gpg keyservers known to be
  unavailable, we might not have gpg executable available, its code is
  fallback and untested,...)
* set up Grml's apt configuration with usage of
  "signed-by=/usr/share/keyrings/grml-archive-keyring.gpg"

Thanks: Karl Voit for the bug report
Closes: grml/grml-debootstrap#187

KEYRING is no longer relevant and a leftover from commit 06fc8bd2.
If someone wants to customize the keyring handling of debootstrap,
this can be achieved via --debopt / DEBOOTSTRAP_OPT.

Closes: grml/grml-debootstrap#184

We had to apply fixes due to efivars vs efivarfs in Debian kernel
versions >=5.10, and addressed them in commit d91d9f3e.

Those changes were incomplete though: while efibootmgr was invoked in
the according and expected environment, invocation of grub-install
doesn't reliably work (as at that time /sys/firmware/efi/efivars is no
longer accessible).

GRUB installation on EFI systems without /sys/firmware/efi/efivars
present warns with (also see https://sources.debian.org/src/grub2/2.04-20/debian/patches/efi-variable-storage-minimise-writes.patch/?hl=650#L650):

| EFI variables are not supported on this system

But it returns with exit code 0. This leaves us with an incomplete and
therefore not booting GRUB EFI environment. Fix it by unmounting
/sys/firmware/efi/efivars only from within our final stage.

Without dbus, several systemd features aren't available (e.g.
systemd-logind and its HandlePowerKey=poweroff doesn't have any effect).
We agreed to ship dbus by default, as people want usable, not minimal
systems most of the time.

Closes: grml/grml-debootstrap#102

When the working directory is a foreign git repository (other than
grml-debootstrap.git), and grml-debootstrap is invoked with the full
path pointing towards grml-debootstrap.git, then we're relying on `git
describe` output of the other (foreign) repository, which is failing and
reporting an unknown version.

Demonstration:

| % cd "$(mktemp -d)"
| % git init
| Initialized empty Git repository in /tmp/tmp.2TQO7PZPQX/.git/
| % ~/src/grml/grml-debootstrap/grml-debootstrap --version
| fatal: No names found, cannot describe anything.
|  * grml-debootstrap - version unknown
|  * Report bugs via https://github.com/grml/grml-debootstrap/ or https://grml.org/bugs/

... and also:

| % cd "$(mktemp -d)"
| % git init
| Initialized empty Git repository in /tmp/tmp.Y15j7wMMOn/.git/
| % echo foo > foo
| % git add foo ; git commit -m 'foo'
| [main (root-commit) 5d4357c] foo
|  1 file changed, 1 insertion(+)
|  create mode 100644 foo
| % git tag 0.42
| % ~/src/grml/grml-debootstrap/grml-debootstrap --version
| fatal: No annotated tags can describe '5d4357c0b5bb504e610265904619287be2c6718d'.
| However, there were unannotated tags: try --tags.
|  * grml-debootstrap - version unknown
|  * Report bugs via https://github.com/grml/grml-debootstrap/ or https://grml.org/bugs/

Thanks: Paul Menzel for the bugreport
Closes: grml/grml-debootstrap#183

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.