Add debootstrap to Depends As of git rev d6d5fee3 we no longer depend on fai-server, though fai-client doesn't depend on debootstrap, so we need to track this on our own. Would be nice to be able to use mmdebstrap instead of debootstrap, but sadly FAI has this hardcoded, so until we got rid of FAI, we need to explicitly depend on debootstrap.
Initial arm64 / aarch64 support Relevant changes: * arm64 (ARM64 in terms of FAI class) is considered a valid and supported architecture within grml-live now; updated documentation, configuration files and zsh completion accordingly * arm64 was enabled as supported architecture in grml repositories * the architecture specific grml-scripts + grml-scripts-core packages got built for arm64 and uploaded to the grml-testing repository * memtest86+ + syslinux aren't available on arm64, therefore move memtest86+ to Recommends to avoid ending up with an `Arch: any` package, also depend on either syslinux or syslinux-efi * Software related changes in GRML* (other than the obvious linux-image-arm64 and further arm64 specific packages): * GRMLBASE: - grml2usb is I386 + AMD64 specific for now (if we want to use grml2usb on arm64 as well, we'd need to port it) - grub-efi-amd64-bin, grub-efi-ia32-bin + grub-pc as well as syslinux, syslinux-common + syslinux-utils all are also I386 + AMD64 specific * GRML_FULL: - cciss-vol-status, cmospwd, cpuid, grub-pc-bin + ltrace all are I386 + AMD64 specific (so not available for arm64) - grml-terminalserver is I386 + AMD64 specific for now (at least until we ported grml2usb for arm64) * /etc/grml/fai/config/scripts/GRMLBASE/44-grub: invocation of grub-mkimage is I386 + AMD64 specific (at least until we identify whether there's an actual use-case for our generated /boot/grub/core.img) * /etc/grml/fai/config/scripts/GRMLBASE/45-grub-images: we use /boot/bootaa64.efi for the EFI boot image name for arm64, though need to skip the unavailable efi_uga module and also skipt the i386-pc architecture, since grub on arm64 doesn't provide /usr/lib/grub/i386-efi Known TODOs: * decide official naming for Grml on arm64 (also keep e.g. `update-grml-rescueboot -t small -a 64` in mind!) * grml2usb isn't available for arm64 yet, and therefore also grml-terminalserver isn't available for arm64 * when booting the resulting ISO inside an arm64 / aarch64, the default terminal seems to start up as /dev/ttyAMA0 (instead of /dev/tty1, as expected and handled via our getty@tty1.service) * look into SecureBoot support Development sponsored by netcup GmbH
Drop depends on fai-server We don't seem to actually need the fai-server package, which ships the following binaries: * /usr/bin/fai-mirror/usr/bin/fai-mk-configspace * /usr/bin/fai-monitor-gui * /usr/sbin/dhcp-edit * /usr/sbin/fai-cd * /usr/sbin/fai-chboot * /usr/sbin/fai-diskimage * /usr/sbin/fai-make-nfsroot * /usr/sbin/fai-mk-network * /usr/sbin/fai-monitor * /usr/sbin/fai-new-mac * /usr/sbin/fai-setup Furthermore, fai-server ships the following configuration file: * /etc/fai/NFSROOT * /etc/fai/apt * /etc/fai/apt/sources.list * /etc/fai/apt/trusted.gpg.d * /etc/fai/apt/trusted.gpg.d/fai-project.gpg * /etc/fai/grub.cfg * /etc/fai/grub.cfg.autodiscover * /etc/fai/nfsroot.conf We might still need some variant of /etc/fai/nfsroot.conf via `${GRML_FAI_CONFIG}/nfsroot.conf` + `${GRML_FAI_CONFIG}/make-fai-nfsroot.conf`, though if we could finally get rid of also those, that would be certainly be nice. Thanks: AndrĂ¡s Korn
Bump Standards-Version to 4.6.2
Update Vcs-git header to use github.com We consider deprecating our git.grml.org service and also the git protocol is insecure and should be avoided, update debian/control accordingly.
Provide information how ISO was generated in file conf/buildinfo.json Relevant changes: * Depend on "jo" tool, used for generating the json output in conf/buildinfo.json * Do not rewrite $SQUASHFS_NAME content, instead handle its fixed output format via $fixed_squashfs_name * Same for $RELEASE_INFO content, handled via $fixed_squashfs_name now * Always set $SQUASHFS_BINARY if unset, to be able to log a proper command line, even if mksquashfs stage gets skipped FTR: the generated file is accessible on the live system under /run/live/medium/conf/buildinfo.json Closes: https://github.com/grml/grml-live/issues/44
Bump Standards-Version to 4.5.1
Execute 'wrap-and-sort -a -t -s' on debian/ This is much better for (code) reviews
Bump Debian compat version to 12, using debhelper-compat approach
Bump Standards-Version to 4.5.0
Bump Standards-Version to 4.3.0
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
Switch Homepage + Vcs-Browser headers from http to https
Bump Standards-Version to 4.2.1
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
Bump Standards-Version to 4.1.4
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
Bump Standards-Version to 4.0.1
Support EFI on 32-bit systems, increase EFI image size + switch from isohybrid to xorriso/isohybrid combination EFI on 32-bit systems is a requested feature for Grml-Forensic, since cheap tablets and notebooks (e.g. Intel Atom-based tablets) are out there with only 32-bit EFI support (and UEFI only, so no legacy BIOS support), quoting clairelyclaire from https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1341944: | As of now, Ubuntu and other major Linux distributions do not | support the use of a 32-bit EFI bootloader on UEFI machines. This | has become extremely problematic due to the popularity of Intel | Atom-based tablets and compact laptops. Atom-based devices are | generally limited in storage space (32GB or 64GB eMMC is common), | and as a result these devices almost universally ship with | Windows 8.1 32-bit installed (winsxs consumes a significant | amount of storage space in order to support 32-bit binaries in a | 64-bit environment). By design, UEFI must use the same | architecture used by the bootloader. | | While most modern computers indeed use a 64-bit UEFI | implementation due to the fact that new computers generally ship | with a 64-bit operating system (be it OS X or Windows 8.1), | Atom-based devices do *not* use a 64-bit operating system or UEFI | implementation. This is by design. | | Intel released a new Atom iteration (Bay Trail) in late 2013 and | has indicated that they will continue to develop and release Atom | CPUs due to consumer market demand. At the time of this filing | there are a number of Atom-based tablets and compact | laptops/netbooks being actively sold and marketed by major OEMs | including Dell, HP, ASUS, and Acer. None of these devices have | 64-bit UEFI firmware. It is also important to note that these | Atom CPUs are 64-bit, but explicitly require a 32-bit UEFI | bootloader. | | The current Linux kernel in Ubuntu 14.04 does support booting the | 64-bit signed kernel from a 32-bit Grub EFI bootloader. I can | confirm this on at least two 32-bit UEFI devices, the ASUS | Transformer T100TA and the Acer Aspire Switch 10. Increase EFI image size (previously automatically calculated on-demand, resulting in ~285KB) to 4MB, giving us more flexibility with what we're installing into the image (esp. useful with usage on USB drives). The isohybrid binary doesn't support 32-bit FI systems and fails hard when using `--uefi` on a 32-bit ISO. But xorriso with appropriate options for EFI usage (see $EFI_ARGS) and /usr/lib/ISOLINUX/isohdpfx.bin from the isolinux package seems to provide everything we need. Useful resources for further information: * http://www.syslinux.org/wiki/index.php?title=Isohybrid * https://fedoraproject.org/wiki/Using_UEFI_with_QEMU * https://wiki.archlinux.org/index.php/Remastering_the_Install_ISO For testing the resulting 32-bit ISO with EFI the OVMF.fd file from OVMF-IA32-r15214.zip available from https://sourceforge.net/projects/edk2/files/OVMF/ works via e.g.: | qemu-system-i386 -m 1024 -bios ./OVMF.fd -cdrom grml.iso
Drop grml-live-compat from Suggests, update code + comments accordingly grml-live-compat is no longer relevant, so let's get rid of it.