grml / grml-live Goto Github PK

i am not sure why the default output is /grml, but it seems a bit problematic to me. / is often quite tight in terms of space - it's not the place where there's the most storage, out of the box. in some cases, it's also readonly and may ring all sorts of alarm bells when ran.

better defaults could be:

• ./grml - assume the current directory is a sane location
• /srv/grml - similar to /grml but at least respects the FHS somehow, and /srv often has lots of storage
• /var/lib/grml - probably the most conformant location...

The default seems to be set in

My prefered option is ./grml, it's what i expected, not knowing much about the software.

firmware-ath9k-htc is missing in Debian/testing due to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997767. Its fix is stuck in open-ath9k-htc-firmware package in Debian's NEW queue since 5 months (see https://ftp-master.debian.org/new.html).

If no objects until release time, we should check whether we want to re-integrate it in Grml.

Running the command below with grml-live v0.32.0 on a Debian Sid/unstable system, the build fails with the error below.

$ sudo GRML_FAI_CONFIG=$(pwd)/etc/grml/fai SCRIPTS_DIRECTORY=$(pwd)/scripts LIVE_CONF=$(pwd)/etc/grml/grml-live.conf ./grml-live -s sid -a amd64 -c GRMLBASE,GRML_FULL,AMD64 -t $(pwd)/templates/
[…]
  [*] Finished execution of stage 'squashfs'
  [*] Forcing rebuild of ISO because files on ISO have been modified.
  [*] Using xorriso -as mkisofs to build ISO.
  [*] Enabling (U)EFI boot.
xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project.

Drive current: -outdev 'stdio:/home/joey/src/grml-live/grml//grml_isos/grml_0.0.1.iso'
Media current: stdio file, overwriteable
Media status : is blank
Media summary: 0 sessions, 0 data blocks, 0 data, 3365m free
xorriso : WARNING : -volid text problematic as automatic mount point name
xorriso : WARNING : -volid text does not comply to ISO 9660 / ECMA 119 rules
Added to ISO image: directory '/'='/home/joey/src/grml-live/grml/grml_cd'
xorriso : UPDATE :     954 files added in 1 seconds
xorriso : FAILURE : Given path does not exist on disk: -boot_image system_area='/usr/lib/ISOLINUX/isohdpfx.bin'
xorriso : UPDATE :     954 files added in 1 seconds
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
stat: cannot stat '/home/joey/src/grml-live/grml//grml_isos/grml_0.0.1.iso': No such file or directory
  [!] Error: there was a critical error executing stage 'iso build'

My aim was to find a tool to create customised debian and ubuntu based live CD environments from the same method. From the manual I see that grml can generate live system from debian.
Can it also generate live system from ubuntu easily in the same way

Hi,

I'm booting from an UEFI (and this is relevant) memorystick. I want to use the option partconf=. However, when using this USB with different servers the disk configuration is different: no HD, 1, 2... disks. So I can't use /dev/sdX.

Any alternative to "autosearch" for the USB primary partition (where all GRML files are)?

These both links are currently broken (Thanks to David Prevot [email protected] for the report):

We should research whether the way our ISOs are generated with xorriso, isohybrid etc are still all follow best practices of year 2020.

Thomas Schmitt wrote a great summary in https://lists.debian.org/debian-cd/2019/07/msg00007.html (restumbled upon it via a recent discussion in https://lists.debian.org/debian-live/2020/03/msg00213.html) and there's a reference also at https://wiki.debian.org/RepackBootableISO

What I'm also interested in is a nice way to make our ISOs more customization-friendly, especially when having the need to add further partition(s) to a USB stick when dd-ing the Grml ISO onto it (without having to use grml2usb and having to manually deal with the appropriate partition layout).

FTR: we're interested in amd64 and i386 architectures only, though would like to have the system boot on as many systems as possible out of the box (BIOS, EFI + SecureBoot).

Hi,

grml is still unable to find its ISO on an LV, forcing people who want grml as an option in the grub menu to have /boot on a regular partition. The current release candidate does have the tools on board to find the iso on an LV, since the LVM tools are available in the initrd. When I try booting this way, I end up in an emergency shell after two screenfuls of "unable to open '/dev/sda'". in that emergency shell, i can activate the VG, mount the LV, mount the .iso loopback to /live/medium.
Unfortunately, exiting the rescue shell does not result in a working grml even then.
It would be really nice if the grml release after 2017.05 would be able to boot from an LV.
Greetings
Marc

Included clonezilla image is outdated and is missing key features, i.e. specific ssd drive support. Request future versions of grml include the bionic version by default.

The wayback option -w doesn't yet respect the given date for bootstrapping the issue.
This can be worked around via providing a custom BASEFILE, though we should support the wayback option also during the automated debootstrap/mmdebstrap riun if no BASEFILE exists.

(Forwarding from customer, TT#69519 in customer's ticket system)

There is a very noticeable loud beep when reaching the menu of the ISO. Is there a way to disable this?

How many threads are used also depends on the compression level. At -6, I've seen it use 3-4 threads, which speeds up initramfs compression a lot. With -8, it always only uses one thread (although maybe it also depends on the amount of data being compressed; I don't know).

I suggest that the -8 in /etc/grml/fai/config/files/etc/initramfs-tools/conf.d/xz-compress/GRMLBASE be replaced with -6.

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'

Please add radvd (IPv6 Router Advertisement Daemon) to grml. radvd is needed to use grml as an IPv6 router. radvd was already part of grml about a decade ago (in grml_2008.11) but got removed shortly after without any explanation.

grml-live -A -V -s sid -c DEBORPHAN,GRMLBASE,GRML_FULL,RELEASE,AMD64,IGNORE,SNAPSHOT -r"lxtec20200328" -g grml64-full -o .

Errors were encountered while processing:
grml-etc
ERROR: 256 256
ERROR: chroot /source/grml-live/grml-live/grml_chroot dpkg --configure --pending return code 1
install_packages: executing chroot /source/grml-live/grml-live/grml_chroot dpkg -C
The following packages have been unpacked but not yet configured.
They must be configured using dpkg --configure or the configure
menu option in dselect for them to work:
grml-etc etcetera files for the Grml system

install_packages: executing chroot /source/grml-live/grml-live/grml_chroot apt-get clean
2 errors during executing of install_packages

This only needs to invoke the fwsetup tool

My computer does not support Framebuffer, I would like the system to start with VESA.

Forwarding from netbootxyz/netboot.xyz#154 (comment)

We should try to make sure that the netboot meny entry in Grml ISOs works in BIOS and (U)EFI mode.

Please use https://grml.org/grml-live/ in the GitHub description.

Forwarding bug report from IRC:

grml-live-remaster seems to be old and broken (still using aufs,
though everything was switched to overlayfs)

Reporting here to not forget about it.

isomd5sum provides two binaries: implantisomd5 to embed a checksum into an ISO, and checkisomd5 which then checks the MD5 checksum which was implanted by implantisomd5.

Its usage is as simple as:

implantisomd5 grml.iso

and:

checkisomd5 /dev/sr0

A customer of mine is using this and this seems to be useful and worth consideration inclusion and integration in grml-live.

Please apply layout changes made in 07181b4 to DEBIAN_STABLE

Is it possible to create deterministically reproducible grml iso images?

I followed the instuctions on https://grml.org/grml-live/#deploy-on-debian and wanted to build a minimal grml installation based on debian jessie with only GRMLBASE and AMD64. grml-live failed at executing GRMLBASE/16-depmod, GRMLBASE/45-grub-images and GRMLBASE/99-finish-grml-build.

grml-live.log

This is a reminder ticket for an issue that has been discussed on the mailing list to avoid that the issue gets forgotten.

I am trying rebuild a grml iso from within grml with
sudo grml-live -A -V -s sid -c DEBORPHAN,GRMLBASE,GRML_FULL,RELEASE,AMD64,IGNORE,SNAPSHOT -r "test20170915" -g
grml64 -o ~/grml-remaster/tmp
and having this fail with a message that /efi/boot/bootx64.efi is not found at the place where the script its looking for it, while the file is in /ilb/live/mount/medium.
mika has shown a pach on the mailing list, but that patch doesn'thelp.
Full thread reference is starting at http://ml.grml.org/pipermail/grml/2017-September/011696.html

Greetings
Marc

Hi,

The current Live support is very useful!
However, no every time you can boot with an IP network. So a Layer 2 network support (Ethernet) is interesting.

Fortunately some open source project has client/server support of the MAC-Telnet tool.
See the project here: https://github.com/haakonnessjoen/MAC-Telnet
It has systemd scripts and can run in any Debian based Linux.

So, my suggestion is to support grml mactelnet=password cheat code like for SSH server.
To achieve this you only need to add the package and enable the service mactelnetd. Futhermore I recommend to run the tool mndp as well for autodiscovering.

Using this technique you can boot a headless server and connect to it from another machine connected to the same Ethernet network even without any IP communication.

You agree?

Note: Using this MAC-Telnet and AoE it's possible to recover data from any headless server with only direct Ethernet wires. 😉

Hi,

The current ssh cheat code doesn't activate any option to discover the server in the network (it only prints in the console the message You can connect with SSH to: .... And that's useless with a headless machine.

However, the GRML Live has the AVAHI-DAEMON service!
So with these commands you can announce the server in the network:

cp /usr/share/doc/avahi-daemon/examples/ssh.service /etc/avahi/services
systemctl enable avahi-daemon.service
systemctl start avahi-daemon.service

So, I suggest to do this every time the ssh cheat code is used. It's free and easy to activate!

Futhermore, you can enhance it publising the password (as an option) in the Name of the server (now the default is grml; so you can use grml (pw:<password>)

I hope you aggree with this enhancement. It will simplifies the connection of a headless server booted with GRML Live.

Hi,

binwalk is helpful when unpacking one of those nifty new initrd images with microcode prepended. binwalk tells you how many bytes to skip at the beginning of initrd.img to find the beginning of the actual initrd.

Please consider including binwalk.

Usage example see http://unix.stackexchange.com/questions/163346/why-is-it-that-my-initrd-only-has-one-directory-namely-kernel

Greetings
MArc

ZFS comes fully supported starting with Ubuntu Xenial 16.04, it's also supported within Proxmox. I'm still uncertain about the license situation, but we should at least try to make usage of ZFS as easy as possible with Grml ISOs (and also provide support within grml-live to build ZFS-enabled Grml ISOs).

I tried to run grml-live script from the cloned location and I think some more env variable are missing in order to make it work in place.

root@test:/home/users/test/workspace/grml-live# export GRML_FAI_CONFIG=$(pwd)/etc/grml/fai
root@test:/home/users/test/workspace/grml-live# export SCRIPTS_DIRECTORY=$(pwd)/scripts
root@test:/home/users/test/workspace/grml-live# ./grml-live -s jessie -a amd64 -c GRMLBASE,GRML_FULL,AMD64 -t $(pwd)/templates/
  [x] Configuration file /etc/grml/grml-live.conf can not be read, ignoring

grml-live [***UNRELEASED***]: check your configuration (or use -F to force execution):

  FAI classes:       GRMLBASE,GRML_FULL,AMD64
  Config directory:  /home/users/test/workspace/grml-live/etc/grml/fai
  main directory:    /grml/grml-live
  Chroot target:     /grml/grml-live/grml_chroot
  Build target:      /grml/grml-live/grml_cd
  ISO target:        /grml/grml-live/grml_isos
  Grml name:         grml
  Release name:      grml-live rocks
  Build date:        2017-01-23
  Grml version:      0.0.1
  Debian suite:      jessie
  Architecture:      amd64
  Boot method:       isolinux
  Hybrid method:     isohybrid
  Template files:    /home/users/test/workspace/grml-live/templates/

Is this ok for you? [y/N

LIVE_CONF should also be exported? otherwise the configuration cannot be found!
/etc/grml/grml-live.conf can not be read, ignoring

In the Readme you mention some dependencies, could you make a list?

Hi,
to debug something, I would like to be able to build my own grml-full iso that is as close as possible to the official image. Please consider putting information about how an image was built into the iso. Minimum is the combination of fai classes that were used, I would love to have the exact grml-live command line.
Can you please give the combination of fai classes used for grml-{full|small}-2017.05 either in this ticket or in e-mail, so that I can continue with my debugging?
Greetings
Marc

We are aware of several systems (e.g. Dell servers) that fail to boot with our Secure Boot ISO, so we should disable Secure Boot on our stable release.

The grml-lang de and the grml-quickconfig function doesn't load the correct german nodeadkey layout.
You can't press ÖÄÜ for characters.
In the full version is all normal.

Noticed this during release time (quoting from https://jenkins.grml.org/job/grml64-full_Release/37/console):

11:18:18 Calling task_action
11:18:18 FAI_ACTION: softupdate
11:18:18 Calling task_softupdate
11:18:18 Performing FAI system update. All data may be overwritten!
11:18:18 Calling task_debconf
11:18:20 Adding debconf data from //etc/grml/fai/config/debconf/GRMLBASE
11:18:22 Reconfiguring package x11-common
11:18:22 update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
11:18:22 invoke-rc.d: could not determine current runlevel
11:18:22 Setting up X socket directories... /tmp/.X11-unix /tmp/.ICE-unix.
11:18:22 debconf: DbDriver "_ENV_stack": unable to save changes to: x11-common/xwrapper/allowed_users x11-common/xwrapper/actual_allowed_users
11:18:22 Calling task_repository
11:18:23 '/etc/resolv.conf' -> '/srv/jenkins/jobs/grml64-full_Release/workspace/grml_chroot/etc/resolv.conf'
11:18:23 cp: not writing through dangling symlink '/srv/jenkins/jobs/grml64-full_Release/workspace/grml_chroot/etc/resolv.conf'
11:18:23 fcopy: copied /etc/grml/fai/config/files/etc/hosts/GRMLBASE to /srv/jenkins/jobs/grml64-full_Release/workspace/grml_chroot/etc/hosts

Situation during build time:

# ls -la /srv/jenkins/jobs/grml64-full_Release/workspace/grml_chroot/etc/resolv.conf
lrwxrwxrwx 1 root root 27 Jun  6 11:17 /srv/jenkins/jobs/grml64-full_Release/workspace/grml_chroot/etc/resolv.conf -> /run/resolvconf/resolv.conf
# cat /srv/jenkins/jobs/grml64-full_Release/workspace/grml_chroot/etc/resolv.conf
cat: /srv/jenkins/jobs/grml64-full_Release/workspace/grml_chroot/etc/resolv.conf: No such file or directory

Unsure yet where this is coming from, though we should ensure it doesn't do any harm and also try to get rid of this message.

Already included in grml-full OOTB, consider integrating in grml-small as well (6 - 7 MB). Needs verification.

The patch in commit d473b06 (which has, unfortunately, not made its way into any release yet) is incomplete.

If /lib/udev/rules.d/69-lvm-metad.rules was removed by a prior run of the unpatched script, the patched script will fail to create the placeholder file.

Is there any harm in generating the placeholder unconditionally?

We have >134k entries like

depmod: WARNING: /lib/modules/5.10.0-4-amd64/kernel/arch/x86/events/rapl.ko needs unknown symbol x86_match_cpu

in FAI's shell.log, coming from etc/grml/fai/config/scripts/GRMLBASE/16-depmod and its $ROOTCMD depmod -ae -F /boot/System.map-"$kernelversion" "$kernelversion" call. We need to avoid this, as those ~16MB of shell.log are waste of space and time (if someone needs to go through logs).

Thanks all for this great Grml Live with such a small size compared to my Arch Live and the new Arch based SystemRescueCd.
I saw Grml has QEMU in it but without a GUI.
When I designed my Live CD (https://github.com/mytbk/gloriousarch), I thought QEMU can be useful for installing an operating system with KVM directly with an iso image without making a USB stick with the iso. For example, I can install Windows with sudo qemu-system-x86_64 -enable-kvm -m 4G -cdrom windows.iso -drive /dev/sda,format=raw -boot order=d.

I was a little disappointed to get to the wiki page for wlan and see it says it "works out of box" but then the whole page is just about drivers; no information about actually connecting (other than a broken external link to a README).

It would be nice if the grml image included a default wpa_supplicant.conf like:

# /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/run/wpa_supplicant
update_config=1

This would allow wpa_cli to connect and save the config; out of box.

The wiki could then include a basic example like:

To quickly connect, you can use the interactive wpa_cli command (which gives a > prompt). To connect to the network MYNETWORK with the password "itsasecret" do the following:

# wpa_cli
> scan
OK
<3>CTRL-EVENT-SCAN-STARTED
> scan_results
bssid / frequency / signal level / flags / ssid
11:22:33:44:55:66 5220 -41 [WPA2-PSK-CCMP][ESS] MYNETWORK
77:88:99:00:11:22 2437 -72 [WPA2-EAP-TKIP][WPA-EAP-CCMP] OTHERNETOWRK
...
> add_network
0
> set_network 0 ssid "MYNETWORK"
> set_network 0 psk "itsasecret"
> enable_network 0
<2>CTRL-EVENT-CONNECTED - Connection to 11:22:33:44:55:66 completed (reauth) [id=0 id_str=]
> save_config
OK
> quit
 # dhclient wlan0  # <-- to get an ip

If your network has no password, use set_network 0 key_mgmt NONE instead.
See man wpa_cli or type help from the > prompt for more info.

By default debootstrap creates systems with /usr being merged, leading to issues like the xfsdump issue we saw in #85.

It's possible to generate custom basefiles with debootstrap, but by default we should invoke debootstrap with the --no-merged-usr option, otherwise we might have different ISO layouts, depending on whether we use appropriate basefiles (as on jenkins.grml.org) vs. locally.

iptstate is gone from Debian/testing since 2021-10-14 due to https://bugs.debian.org/994193. I pinged the maintainer twice in the meanwhile but didn't get any feedback. It's preventing Debian/testing based daily Grml builds, so at least for the time being let's drop it.

Should be clarified for upcoming stable Grml release how to be handled.

While playing with/using grml-live, I noticed that it will modify make-fai-nfsroot.conf upon start. It seems to update FAI_DEBOOTSTRAP and FAI_DEBOOTSTRAP_OPTS from my (sometimes omitted) command line parameters.
I don't think this is cool:

• in Debian, /etc/grml/fai/make-fai-nfsroot.conf is a conffile, the app should never ever overwrite settings an admin made there
• even outside Debian: I may have set the file on purpose differently as my command line. I do not want my cli settings to be stored.

Looking at the code I am not sure whether the file is actually a conffile or rather some kind of state-file. If it's the latter, it shouldn't be in /etc, otherwise, it shouldn't be edited, IMHO.

With the daily Sid full image from today (MD5 sum b61c426af66ea5fdbd9d8becec29af8b), dd’ing that to a 64 GB USB 3 device results in an image dropping in a GRUB CLI with the partition with the GRUB configuration not visible.

The type of the first partition does not seem to get set.

$ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.31.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 58.4 GiB, 62746787840 bytes, 122552320 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1754a5eb

Device     Boot Start     End Sectors  Size Id Type
/dev/sdb1  *        0 1396735 1396736  682M  0 Empty
/dev/sdb2         580    8771    8192    4M ef EFI (FAT-12/16/32)

Command (m for help):

GNU parted also only detects one partition.

$ sudo parted /dev/sdb print
Model: SanDisk Extreme (scsi)
Disk /dev/sdb: 62.7GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start  End     Size    Type     File system  Flags
 2      297kB  4491kB  4194kB  primary               esp

memtest86+ doesn't support EFI boot, while https://github.com/martinwhitaker/pcmemtest claims to provide EFI support, though pcmtest is available in Debian testing + unstable only for now, though that might be worth giving it a try.

We have this:

root@jenkins ~ # mount  | grep grml_chroot
tmpfs on /srv/jenkins/jobs/grml32-full_sid/workspace_ws-cleanup_1557801826280/grml_chroot/run/udev type tmpfs (rw,nosuid,noexec,relatime,size=308412k,nr_inodes=385513,mode=755)
tmpfs on /srv/jenkins/jobs/grml32-small_sid/workspace_ws-cleanup_1557802690828/grml_chroot/run/udev type tmpfs (rw,nosuid,noexec,relatime,size=308412k,nr_inodes=385513,mode=755)
tmpfs on /srv/jenkins/jobs/grml64-small_sid/workspace_ws-cleanup_1557803622940/grml_chroot/run/udev type tmpfs (rw,nosuid,noexec,relatime,size=308412k,nr_inodes=385513,mode=755)
tmpfs on /srv/jenkins/jobs/grml32-full_testing/workspace_ws-cleanup_1557805587293/grml_chroot/run/udev type tmpfs (rw,nosuid,noexec,relatime,size=308412k,nr_inodes=385513,mode=755)
tmpfs on /srv/jenkins/jobs/grml32-small_testing/workspace_ws-cleanup_1557806397025/grml_chroot/run/udev type tmpfs (rw,nosuid,noexec,relatime,size=308412k,nr_inodes=385513,mode=755)
tmpfs on /srv/jenkins/jobs/grml64-full_sid/workspace_ws-cleanup_1557807717842/grml_chroot/run/udev type tmpfs (rw,nosuid,noexec,relatime,size=308412k,nr_inodes=385513,mode=755)
tmpfs on /srv/jenkins/jobs/grml64-full_testing/workspace_ws-cleanup_1557809899869/grml_chroot/run/udev type tmpfs (rw,nosuid,noexec,relatime,size=308412k,nr_inodes=385513,mode=755)
tmpfs on /srv/jenkins/jobs/grml64-small_testing/workspace_ws-cleanup_1557810887892/grml_chroot/run/udev type tmpfs (rw,nosuid,noexec,relatime,size=308412k,nr_inodes=385513,mode=755)

I think that's a side-effect of the following change:

grml-scripts (2.8.4) unstable; urgency=medium

  * [74367b9] grml-chroot: bind-mount /run/udev in target system as
    workaround for lvm2 issue #918590
[...]

Needs investigation.

Just noticed that grml-full generates 83 locales which consumes nearly 42MB:

root@grml ~ # grml-version 
grml64-full_testing build3165 Release Codename autobuild-build3165 [2020-06-24]
root@grml ~ # grep -v "^#" /etc/locale.gen | wc -l
83
root@grml ~ # l /usr/lib/locale 
total 40508
drwxr-xr-x 3 root root      236 Jun 24 04:04 C.UTF-8
-rw-r--r-- 1 root root 41479488 Jun 24 04:22 locale-archive

Removing all locales except en_US.UTF-8 drops the disk usage to about 3MB:

root@grml ~ # echo "en_US.UTF-8 UTF-8" > /etc/locale.gen
root@grml ~ # locale-gen 
Generating locales (this might take a while)...
  en_US.UTF-8... done
Generation complete.
root@grml ~ # l /usr/lib/locale     
total 2892
drwxr-xr-x 3 root root     236 Jun 24 04:04 C.UTF-8
-rw-r--r-- 1 root root 3035216 Jun 24 18:58 locale-archive

I believe GRMLBASE and GRMLFULL (in https://github.com/grml/grml-live/tree/master/etc/grml/fai/config/files/etc/locale.gen) should only provide en_US.UTF-8 as we use localepurge which is configured to remove all locales except en_US.UTF-8 and en.

I regularly use a grml USB stick in a server's USB port to have a rescue system that is independent of both local disk and network. Of course, the easiest way to have this is just dd'ing an grml iso to
the medium and then plugging it in without more ado. In the past, I had to build my own grml iso to have a non-graphical startup to be able to select the grml startup option, since that one is usually shown with a fancy graphical isolinux screen and doesn't work if the only thing one has is a serial port.

I would love to have the possibility to do a simple patch in an otherwise unchanged grml image so that my ProLiant grml is as close to "release" grml as possible. I would appreciate a hint if that is
already possible.

While I do understand that having a nice-looking selection screen is nice and important for user acceptance, this severely reduces grml's attractivity for the server jockey who usually doesn't have graphical access to the systems.

A possible implementation would be to include a longish placeholder comment into the isolinux configuration that can be used to patch in additional commands in an existing iso. I am not afraid of a hex editor, so I'm fine with doing that.

Greetings
Marc

While refreshing the grml-live-grml Debian source package (which builds the grml-live-addons Debian binary package), I noticed that we have several boot addons that are pretty much unmaintained nowadays.

Especially the bsd4grml (4.8MB), balder10.imz (1.2MB, FreeDOS based, see https://www.finnix.org/Balder) + allinone.img (1.5MB, see http://schierlm.users.sourceforge.net/bootdisk/index.html) are among the ones I tend to drop with the upcoming Grml release.

If anyone objects or has further suggestions, please let me/us know!

This never works for me and only raising an error message like error: disk hd0, 1' not found.`
We should just switch to usage of a simple 'exit' in GRUB nowadays.