Release new version 0.34.3

SW: replace vim-gtk with vim-gtk3

vim-gtk is a transitional/dummy package as of bullseye (current
Debian/testing), while vim-gtk3 is available since at least
stretch (current Debian/oldstable).

GRMLBASE/90-update-alternatives: support vim >=2:8.1.2136-1

vim 2:8.1.2136-1 moved /usr/bin/vim.* into /usr/libexec/vim/,
so we need to check for its base path.

Also vim-gtk became a transitional package for vim-gtk3 and
the binary is called vim.gtk3, add according additional check.

Fixes:

| Setting vim.gtk as editor using update-alternatives.
| update-alternatives: error: alternative /usr/bin/vim.gtk for editor not registered; not setting
| GRMLBASE/90-update-alternatives FAILED with exit code 2.

Release new version 0.34.2

Rebuild /var/lib/dpkg/available to install not-yet-installed packages in update runs

When executing grml-live in update mode (grml-live [...] -u) using an
existing grml_chroot, then script GRMLBASE/98-clean-chroot has emptied
/var/lib/dpkg/available in a previous run already.

Executing `apt-get update` does NOT re-generate the file. This leads to
FAI's install_packages with its mkpackagelist() and clean_pkg_list()
failing to install requested packages, but reporting all packages with:

| WARNING: These unknown packages are removed from the installation list: [...]

This is unexpected, as an update run shouldn't just update existing
packages, but also try to install any additionally requested packages
from the software selection (as a package might not have been installed
due to missing dependencies, that have been taken care of in the
meanwhile).

So if we'd detect an existing /var/lib/dpkg/available that is empty,
then we would have to rebuild it using /usr/lib/dpkg/methods/apt/update.
Since /usr/lib/dpkg/methods/apt/update essentially also executes
'apt-get update' underneath, there's no need to run 'apt-get update'
only with empty /var/lib/dpkg/available, instead let's always rely on
/usr/lib/dpkg/methods/apt/update.

SW: drop racoon from GRML_FULL

Quoting from https://packages.qa.debian.org/i/ipsec-tools/news/20190727T182520Z.html:

| ROM; dead upstream, alternatives available

Also see Debian bug #932144

README: set TEMPLATE_DIRECTORY instead of using -t cmdline option

Use same approach in docs and README, to make
it more consistent.

Prompted by Jay Lawrence (@jayjlawrence),
see commit 09137840c2 and
https://github.com/grml/grml-live/pull/76

Merge remote-tracking branch 'origin/github/pr/76'

SW: add efibootmgr to GRMLBASE

The grub-efi-amd64-bin package in Debian/stretch used to have efibootmgr in
its Depends:

| Package: grub-efi-amd64-bin
| Source: grub2
| Version: 2.02~beta3-5+deb9u1
| [...]
| Depends: grub-common (= 2.02~beta3-5+deb9u1), efibootmgr

... while the grub-efi-amd64-bin package in Debian buster and newer has
efibootmgr in its Recommends:

| Package: grub-efi-amd64-bin
| Source: grub2
| Version: 2.02+dfsg1-20
| [...]
| Depends: grub-common (= 2.02+dfsg1-20)
| Recommends: grub-efi-amd64-signed, efibootmgr

Therefore we're no longer pulling in efibootmgr via grub-efi-amd64-bin, while
it's certainly important to have it available, so add it to GRMLBASE.

Development sponsored by Sipwise GmbH, recorded as
TT#63652 in customers' ticket system.

Release new version 0.34.1

Sources list setup for security: switch from testing/updates to testing-security

Supposed to fix:

| E: Failed to fetch http://security.debian.org/dists/testing/updates/main/source/Sources  404  Not Found [IP: 2a04:4e42:9::204 80]

Nowadays only http://security-cdn.debian.org/dists/testing-security/ exists.
Quoting from https://lists.debian.org/debian-security/2019/06/msg00015.html:

| I would like to switch to *-security instead of */updates starting with
| bullseye.  There will likely be some complications, but they should be
| solvable by the time we will publish packages in bullseye-security.

SW: drop lilo from GRML_SMALL and GRML_FULL

I don't think that's relevant for anyone nowadays, otherwise
let's find out :)

Provide workaround for FAI bug, leaving /run/udev behind (see #928981)

Closes: https://github.com/grml/grml-live/issues/77

Need to set templates directory as well when running from git

Release new version 0.34.0

Bump Standards-Version to 4.3.0

Switch default mount point from /lib/live/mount/medium to /run/live/medium

In commit 0d878d3a679 of live-boot(-grml)
("Simplify mount point handling by using /run/live instead of /lib/live/mount")
the mountpath of /lib/live/mount/medium was moved towards /run/live/medium.

Commit c6a17c7b41b of live-boot(-grml) provides a backward compatibility
rbind mount, but occasionally there seems to be a regression somewhere
during boot (see https://github.com/grml/live-boot-grml/issues/10), and
the rbind mount will be deprecated and removed before the bullseye
(Debian 11) release.

Layout changes over time:

* /cdrom for old linuxrc approach
* /live/image for initramfs layout until December 2012
* /lib/live/mount/medium for initramfs layout since December 2012
* /run/live/medium for initramfs layout since December 2018

Drop support for everything but /run/live/medium and
/lib/live/mount/medium, while at it.

SW: add qemu-system-gui to GRML_FULL

Having the gtk interface available is certainly useful, and
requires only ~2MB of additional disk space.

Thanks: Iru Cai for the suggestion
Closes: grml/grml-live#71

SW: add dnsutils to GRML_FULL

It adds only ~1MB of additional disk space to GRML_FULL, since we have
all the relevant dependencies (except for libirs161) onboard already.

We ship ldnsutils (note the leading *l* in the package name) on
GRML_SMALL, since there we don't have libbind* & CO.

Release new version 0.33.6

SW: add aptitude to GRML_FULL

It's relevant for
/etc/grml/fai/config/scripts/GRMLBASE/95-package-information to identify
all packages from section non-free and creating the nonfree-licenses.txt
report.

Closes: grml/grml#112

Release new version 0.33.5

grml-cheatcodes + isolinux splashes: drop xkeyboard + lang=*-iso boot options

The xkeyboard boot option is no longer supported as such (see
relevant changes in grml-live commit 3a054970e and grml-autoconfig
commit fc67c1849a4), so longer announce it.

The lang=*-iso is supposed to disappear and no longer supported as
such, so don't announce it either.

Release new version 0.33.4

Set up Unicode/UTF8 and console fonts via console-setup

Our old approach with running loadkeys, setting console font and
invoking unicode_start via grml-autoconfig is incomplete for nowadays'
environments.

We tried to fix that by changing the order in which we set up the fonts,
runnning loadkeys and finally invoking unicode_start via grml-autoconfig
(see: grml/grml-autoconfig@c820a66). But this changed only the behavior
on tty1, the other consoles still had problems when trying to display
unicode characters (see e.g. `systemctl status` output).

The proper solution is to configure /etc/default/console-setup as needed
(doing this with this change) and rely on console-setup afterwards to do the right
thing (implemented within grml-autoconfig).

With this change we ship a default /etc/default/console-setup via
GRMLBASE, which can be customized as needed by users of grml-live
through separate FAI class files.

Explicitely added console-setup to GRMLBASE since we rely on it
nowadays.

Thanks: Michael Schierl (@schierlm) + @qlplq for feedback and Darshaka Pathirana for debugging this and providing a preliminary PR
Closes: grml/grml-autoconfig#9, grml/grml#50
Relates to: grml/grml#101

Release new version 0.33.3

Merge remote-tracking branch 'origin/github/pr/69'

README.md: Use HTTPS URLs

Ensure to properly remove deprecated serial-getty@ttyS0.service.d override file

This was forgotten to take care in git commit efd2447

Drop 'bootchart' from grml-cheatcodes.txt and isolinux labels

We don't ship the bootchart2 package in any of our ISOs,
so drop it accordingly from docs + isolinux configurations.

See https://github.com/grml/grml/issues/9

Thanks: Darshaka Pathirana for spotting

Release new version 0.33.2

Merge remote-tracking branch 'origin/github/pr/68'

Enable serial-getty with root autologin on every given device

With the kernel command line paramter / bootoption
`console=device,options`[1](https://www.kernel.org/doc/html/latest/admin-guide/serial-console.html)
it is possible to use a serial port as console.

So far we only enabled root autologin for the serial port ttyS0, but it
should be enabled on every given device as we do not have any password
set for any user, which meant that no login was possible at all (on a
serial port other than ttyS0).

The serial port ttyS1 can be tested with QEMU/KVM like this::

  kvm -m 512 -serial pty -serial pty -cdrom grml.iso

This adds two serial ports (ttyS0 and ttyS1) to the VM and redirect its
output to /dev/pts/*. On the Grml boot prompt then add "console=ttyS1"
to redirect the output to second serial console.

Thanks: @MichaelEischer for the bug report
Closes: grml/grml#104

Release new version 0.33.1

Disable Secure Boot support by default

We're seeing failing boots on some Dell servers and it seems
to be related to some EFI firmware situation. Until this is
resolved and we find a long-term strategy WRT Secure Boot
let's disable Secure Boot support in our ISOS by default.

Closes: https://github.com/grml/grml-live/issues/64

grml-cheatcodes.txt: don't mention "gmt" boot option, "utc" should be used

The "utc|gmt" might confuse users and the "gmt" is something which
shouldn't be even announced as such, people should use "utc".

Merge remote-tracking branch 'origin/github/pr/67'

Update cheatcodes to clarify hardware clock and timezone defaults

While debugging grml/grml#61, it was unclear for me what the expected
behavior should be. Grml defaults to LOCAL (in /etc/adjtime) which
means that Hardware Clock is expected to be set in local time (which is
usually the case on Windows only systems).

The time zone defaults to UTC.

Release new version 0.33.0

SW: drop deprecated cpufrequtils (+ drop scripts/GRMLBASE/36-cpufrequtils)

The cpufreq drivers are autoloaded and the powersave/ondemand driver
is mature enough. The linux-cpupower tools provide the binaries
as replacement for what cpufrequtils provided so far and we ship
them (with GRML_FULL) already.

Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877016

Thanks: Michael Biebl for the pointer
Closes: https://github.com/grml/grml/issues/51

Rework debian/, following current best practices

* Switch to minimal debhelper approach, Build-Depend on debhelper >= 10
* Switch from Priority 'extra' to 'optional' (deprecated as of Debian Policy v4.0.1)
* Drop unused GPL-2 section from debian/copyright
* Update copyright year information in debian/copyright
* Refresh lintian overrides
* Add postinst/postrm maintainer scripts for dpkg-maintscript-helper support

Drop symlink etc/grml/fai/config/config

This was annoying since its beginning and AFAICT it's
not strictly needed anymore.

Support BOOT_FILE variable for usage within secureboot templates

This is related to:

| commit 642e1b389347bcb8d6e44b483c327e45225427f4
| Author: Michael Prokop <mika@grml.org>
| Date:   Thu Nov 22 23:54:10 2018 +0100
|
|     Ensure GRUB finds the running ISO

By using the same approach for setting $root within GRUB
also for the Secure Boot GRUB configuration we ensure to
apply the same safety measures to Secure Boot mode.

GRUB: drop `insmod vbe`

When booting in EFI mode this error message is visible for a
very short period of time:

| error: file `/boot/grub/x86_64-efi/vbe.mod' not found

This is annoying, especially because it's hard to read and identify.

It's for sure not relevant within Secure Boot mode, as it's forbidden
there. Let's also disable it by default for Non-Secure-Boot-mode,
if it's relevant for anyone or on specific systems we'll find out.

Ensure GRUB finds the running ISO

Instead of relying on the presence of the /conf/bootid.txt file, which
might be present on several Grml ISOs, let's generate a unique filename
which GRUB then can search for.

JFTR: The redirection within the layers (scripts/GRMLBASE/45-grub-images
vs main grml-live script) is necessary, because the GRUB image is
generated from within the rootfs (grml_chroot), but the rootfs is
compressed within a squashfs file, while we can only access files
available directly inside the ISO (corresponding to the files inside
grml_cd, and not the files inside grml_chroot which
scripts/GRMLBASE/45-grub-images has access to).

Release new version 0.32.3

Switch Homepage + Vcs-Browser headers from http to https

Bump Standards-Version to 4.2.1

Merge remote-tracking branch 'origin/github/pr/66'

Remove genisoimage from dependencies

When running grml-live with genisoimage (9:1.1.11-3+b2) on Debian/stretch the
following error is shown:

  # ./grml-live -s sid -a amd64 -c GRMLBASE,GRML_SMALL,AMD64 -t $(pwd)/templates/ -o /dev/shm/grml-live
  [...]
    [*] Finished execution of stage 'squashfs'
    [*] Forcing rebuild of ISO because files on ISO have been modified.
    [*] Using genisoimage to build ISO.
  genisoimage: -i option no longer supported.
  stat: cannot stat '/dev/shm/grml-live/grml_isos/grml_0.0.1.iso': No such file or directory
    [!] Error: there was a critical error executing stage 'iso build

Closes: grml/grml-live#65

Merge remote-tracking branch 'origin/github/pr/58'

Update broken links

And while doing so change links to manpage to publicly available manpage
links, because the links to the manpage source is barely readable.

Thanks: David Prévot <taffit@debian.org> for the report
Closes: grml/grml-live#57

Release new version 0.32.2

EFI/BOOT: bring back files from Ubuntu 18.04

Bring back the state of EFI/BOOT files as of commit
bc4f02658ffa63a71ef1bc4f37ae3707ff580382 plus the config change with
commit c35a30b42bac4de7089f936d6917b246ade6d5c5, as this was the last
GRUB version that's known to be working with *unsigned* kernel files.

Otherwise SecureBoot fails to boot with:

| Loading kernel...
| error: /boot/grml/vmlinuz has invalid signature.
| Loading initrd...
| error: you need to load the kernel first.

when using grub2-signed (corresponding to Ubuntu's GRUB 2.02+dfsg1-5ubuntu7) with files e.g. from
http://de.archive.ubuntu.com/ubuntu/pool/main/s/shim-signed/shim-signed_1.38+15+1533136590.3beb971-0ubuntu1_amd64.deb +
http://de.archive.ubuntu.com/ubuntu/pool/main/g/grub2-signed/grub-efi-amd64-signed_1.109+2.02+dfsg1-5ubuntu7_amd64.deb

This might be related to the change introduced in:

| grub2-signed (1.93.4) bionic; urgency=medium
|
|   * Rebuild against grub2 2.02-2ubuntu8.3 and check kernel is signed on
|     amd64 EFI before installing grub (LP: #1786491).
|
|  -- Julian Andres Klode <juliank@ubuntu.com>  Mon, 13 Aug 2018 12:51:32 +0200

JFTR, as of 2018-10-17 we have in Ubuntu:

| % rmadison -u ubuntu grub-efi-amd64-signed
|  grub-efi-amd64-signed | 1.9~ubuntu12.04.10+1.99-21ubuntu3.19 | precise-security | amd64
|  grub-efi-amd64-signed | 1.9~ubuntu12.04.10+1.99-21ubuntu3.19 | precise-updates  | amd64
|  grub-efi-amd64-signed | 1.34+2.02~beta2-9                    | trusty           | amd64
|  grub-efi-amd64-signed | 1.34.7+2.02~beta2-9ubuntu1.6         | trusty-security  | amd64
|  grub-efi-amd64-signed | 1.34.17+2.02~beta2-9ubuntu1.15       | trusty-updates   | amd64
|  grub-efi-amd64-signed | 1.66+2.02~beta2-36ubuntu3            | xenial           | amd64
|  grub-efi-amd64-signed | 1.66.18+2.02~beta2-36ubuntu3.18      | xenial-updates   | amd64
|  grub-efi-amd64-signed | 1.93+2.02-2ubuntu8                   | bionic           | amd64
|  grub-efi-amd64-signed | 1.93.7+2.02-2ubuntu8.6               | bionic-updates   | amd64
|  grub-efi-amd64-signed | 1.93.8+2.02-2ubuntu8.7               | bionic-proposed  | amd64
|  grub-efi-amd64-signed | 1.109+2.02+dfsg1-5ubuntu7            | cosmic           | amd64

Note that EFI boot with ovmf 0~20161202.7bbe0b3e-1 with kvm/qemu on
Debian/stretch fails, resulting in a grub shell prompt of GRUB
2.02-2ubuntu8 (without any menu), e.g. when invoked via:

| % qemu-system-x86_64 -bios /usr/share/qemu/OVMF.fd -vga qxl -hda grml.iso -m 512

Both the ovmf versions from kraxel as well from current Debian/testing
AKA buster work though:

| % wget https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20180807.281.gc526dcd40f.noarch.rpm
| % rpm2cpio edk2.git-ovmf-x64-0-20180807.281.gc526dcd40f.noarch.rpm | cpio -idmv
| % qemu-system-x86_64 -bios ./usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd -vga qxl -hda grml.iso -m 512

+

| % wget http://ftp.de.debian.org/debian/pool/main/e/edk2/ovmf_0~20180812.cb5f4f45-1_all.deb
| % dpkg -x ovmf_0\~20180812.cb5f4f45-1_all.deb ovmf
| % qemu-system-x86_64 -bios ovmf/usr/share/ovmf/OVMF.fd -vga qxl -hda grml.iso -m 512

Closes: https://github.com/grml/grml/issues/105

and possibly also related to https://github.com/grml/grml-live/issues/59

EFI/BOOT/README: document file usage

Merge remote-tracking branch 'origin/github/pr/60'

templates/EFI: Use newer grubx64 from Ubuntu

Release new version 0.32.1

jessie-backports: use usb-modeswitch from jessie-backports

libudev1 + udev can be installed from jessie-backports
only if usb-modeswitch is also considered from
jessie-backports.

SW: Drop qemu-kvm (qemu-system-x86 being its replacement) from GRML_FULL

qemu-kvm is in `Section: oldlibs` and deborphan removes
the package anyway, even though we mark it as `--add-keep`.
There's no point in putting further effort into this,
as qemu-system-x86 provides everything what's needed nowadays.

SW: replace targetcli + python-urwid with targetcli-fb in GRML_FULL

targetcli exists only in wheezy + experimental nowadays.
Quoting the package description of targetcli-fb:

| The targetcli-fb package is a fork of the "targetcli" code
| written by RisingTide Systems. The "-fb" differentiates between
| the original and this version. Please ensure to use either all
| "fb" versions of the targetcli components -- targetcli, rtslib,
| and configshell, or stick with all non-fb versions, since they
| are no longer strictly compatible.

SW: drop alsa-base (no longer existing) from GRML_FULL

Used to be `ALSA driver configuration files` package until
wheezy, then became a dummy package with jessie and later
on longer exists at all.

SW: replace lynx-cur (transitional package) with lynx in GRML_FULL

SW: replace btrfs-tools (transitional package) with btrfs-progs in GRML_FULL

SW: add bcache-tools to GRML_FULL

Quoting from 2018-07-15 on IRC:

| 11:26 < suebal> Can't mount /dev/bcache0 using grml - I suppose there's no bache support. What can I do else?

SW: add dislocker to GRML_FULL

Thanks: f0
Closes grml/grml#60

SW: add qemu-guest-agent to GRML_FULL

With qemu-guest-agent service being present we support retrieving
network information from a VM, as supported with e.g. Proxmox
v5.2 (verified with qemu-guest-agent v1:2.8+dfsg-6 on grml64-full
2017.05).

Adding only to GRML_FULL as on GRML_SMALL it would pull in
libglib2.0-0 and add ~6MB of disk space, while on GRML_FULL
it's only ~1MB total.

Release new version 0.32.0

SW: add thin-provisioning-tools to GRML_FULL

Quoting from the bugreport:

| In order to activate lvm volumes which use lvm caching,
| /usr/sbin/cache_check (provided by thin-provisioning-tools) needs
| to be installed (see https://bugs.debian.org/773731). As grml
| currently does not include thin-provisioning-tools, volumes which
| use caching cannot be activated on startup (e.g. via the lvm boot
| option), not activated manually (naturally one can install
| thin-provisioning-tools via apt, but that doesn't help with
| activating on startup).

Closes grml/grml#81
Thanks: James Tocknell

Update GRUB test for Secure Boot support

cpuid with the recent Ubuntu GRUB no longer fails,
so instead let's invoke `probe` with an incomplete
command line, which returns fine in SecureBoot
boot environment while it fails in full GRUB
session with an error message.

templates/EFI: use files from Ubuntu 18.04

Currently, the shim cannot be loaded with TianoCore (using
/usr/share/edk2.git/ovmf-x64/OVMF-pure-efi.fd from
https://www.kraxel.org/repos/jenkins/edk2/edk2.git-ovmf-x64-0-20180508.84.g7cd8a57599.noarch.rpm)
and also fails on several systems like on the Dell XPS 13 9360 and 9370,
Dell r640 (see http://ml.grml.org/pipermail/grml/2018-May/011734.html)
and HP EliteBook 820 G3.

Error message during boot:

| Reloc 0 block size 2756420659 is invalid
| Relocation failed: Unsupported

Release new version 0.31.3

Bump Standards-Version to 4.1.4

add placeholder and explanation inviting local patches to isolinux.cfg

this closes grml/grml-live #45

This is unfortunately completely untested, since to multiple issues, one
of them being grml/grml-live #44 and grml/grml-live #46 are still
unaddressed, I cannot currently reliably build grml images. As it is a
comment-only patch, this can be safely applied and I'll happily test a
daily image afterwards.

Merge remote-tracking branch 'remotes/origin/github/pr/52'

Merge remote-tracking branch 'origin/github/pr/49'

SW: add restic

As suggested by Frank Terbeck <ft@grml.org>

Release new version 0.31.2

updatebase.GRMLBASE: no longer install aptitude

We sitched from aptitude to apt-get as package manager in FAI's
package list back in commit 121b3484e, so we shouldn't strictly
need aptitude any longer. The ongoing ncurses transition is
failing our builds currently, so that's a good chance to make
this change.

Replace /etc/apt/grml.key with /etc/apt/trusted.gpg.d/grml-archive-keyring.gpg

/etc/apt/grml.key was a PGP public key block Public-Key (old) and
required installation via apt-key.

By instead placing a `GPG key public ring` into
/etc/apt/trusted.gpg.d/grml-archive-keyring.gpg we don't need
this extra apt-key invocation any longer, which might actually
fail with:

| E: gnupg, gnupg2 and gnupg1 do not seem to be installed, but one of them is required for this operation

Installation of gnupg isn't enough though, since then we run
into:

| 10:45:56 Warning: apt-key output should not be parsed (stdout is not a terminal)
| 10:45:58 gpg: can't connect to the agent: IPC connect call failed

Drop old /etc/grml/fai/config/files/etc/apt/grml.key/GRMLBASE via maintscript

Thanks: Antoine Beaupré <anarcat@debian.org> for a related PR
in https://github.com/grml/grml-debian-keyring/pull/3

SW: replace iproute with iproute2

iproute is a transitional package for iproute2 since Debian/jessie
and no longer exists starting with Debian/buster.

SW: drop apt-transport-https from GRMLBASE

apt-transport-https is a transitional package starting with
Debian/buster, so the package is no longer relevant for builds
against Debian/testing + sid/unstable nowadays.

If someone needs this package in grml-live builds using
Debian/stretch or older Debian releases then the package should
be included in local configurations.

Use stretch-backports instead of jessie-backports for stable

GRMLBASE/98-clean-chroot: execute resolvconf workarounds also for systemd

/etc/resolvconf/resolv.conf.d/original leaks data from the environment
the ISO was built in, and /etc/resolv.conf should be empty and be filled
with data from DHCP.

Thanks: András Korn

Release new version 0.31.1

Do not handle lid switch

Fixes grml/grml#75.

ssh service: set RuntimeDirectory=sshd to work with recent openssh versions

We need to set RuntimeDirectory=sshd, otherwise /run/sshd doesn't
exist and service startup fails with:

| grml sshd[1845]: Missing privilege separation directory: /run/sshd

While at it sync our ssh service file with Debian's openssh
package 1:7.6p1-2 and drop the unused ssh-bootoption.service
file (we currently start ssh service via grml-autoconfig).

Also see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864190

Closes grml/grml#80

Thanks: sl0n for bugreport
Thanks: Darshaka Pathirana <dpat@grml.org> for feedback

GRMLBASE/93-update-usbids: test for new update-usbids location in /usr/sbin

"Recent" versions of usbutils ship the update-usbids
binary in /usr/sbin and no longer in /usr/bin.

GRMLBASE/91-update-pciids: test for new update-pciids location in /usr/sbin

Since pciutils v1:3.2.0-1 the update-pciids binary lives in
/usr/sbin and no longer in /usr/bin.

GRMLBASE/52-mdadm: fix path for 64-md-raid-assembly.rules

This should be /lib/udev/rules.d/64-md-raid-assembly.rules
and not /usr/lib/udev/rules.d/64-md-raid-assembly.rules

While at it use the same approach as for GRMLBASE/50-lvm
in the previous commit, by creating an empty file
instead of just removing it.

Generate empty /lib/udev/rules.d/69-lvm-metad.rules instead of removing the file

Since lvm2 2.02.176-4 initramfs generation fails if
neither /etc/udev/rules.d/69-lvm-metad.rules nor
/lib/udev/rules.d/69-lvm-metad.rules exists.
So instead of removing the file just create an empty one.

See http://bugs.debian.org/881916

SW: add ldnsutils to GRML_SMALL

dig would be nice to have, though pulls in ~41MB of disk space.
drill from ldnsutils is a nice alternative.

See grml/grml/#56

SW: add x11vnc to GRML_FULL to properly support vnc boot option

Closes grml/grml#62

Thanks: luke2261git for the bugreport

Fix a bunch of typos

s/and and/and/
s/simplier/simpler/
s/dependancy/dependency/
s/mesages/messages/
s/retreive/retrieve/
s/to to/to/
s/specifed/specified/

Release new version 0.31.0

scripts/generate_netboot_package.sh: use net.ifnames=0 as default boot option

Otherwise we end up with arbitrary network device names which
aren't properly supported (yet).

See grml/grml#65

Secure Boot GRUB template: be more dynamic + don't overwrite with empty variable

By searching for grmlenv.cfg we can make it more dynamic
instead of having to hardcode (hd0) which might be wrong
in the grml2usb situation.

There's also no need to set root/prefix multiple times, especially
since we depend on 'root=(hd0)' for the default ISO boot anyway.

Don't overwrite prefix if the grml_orig_prefix variable is empty.

Secure Boot enabled ISOs generated with grml-live >=0.31.0 are supported
with grml2usb >=0.16.0.

SW: add btrfs-progs to GRML_SMALL

Closes grml/grml#69

Secure Boot support

Thanks to the way the signed GRUB by Ubuntu works we seem to be
able to keep our common EFI GRUB configs working next to the new
Secure Boot related EFI GRUB configs. If Secure Boot is enabled
we get the same look and feel like with common EFI boot, though
with a Secure Boot specific boot menu (since e.g. the linux16
command isn't available under Secure Boot). If EFI is running
with Secure Boot *disabled* it continues to look like it used to
do so far. If this is working out as planned there's no visible
change from a user point of view on systems with Secure Boot
disabled.

With this change we also get rid of some magic with grml-live
relying on behavior of
/etc/grml/fai/config/scripts/GRMLBASE/45-grub-images, including
moving files around.

We also no longer skip the boot stage during rebuilds. This has
been a source of frustration and annoying debugging sessions when
files inside grml_cd/boot/ didn't receive changes during rebuilds
and the user in front of the system is ignoring the according
"skip" notice or forgot to remove grml_cd/boot.

While at it rewrite debian/copyright in
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

Thanks: Michael Schierl <schierlm@gmx.de> for help regarding the Secure Boot setup

SW: add whois to GRML_SMALL

It adds only 346kb of additional disk space.

Debian's mkpasswd is part of the whois package.
It's the mkpassword that can generate salted hashes suitable for /etc/shadow.

Thanks: Marc Haber for the suggestion
Closes grml/grml#66