Unify copy_addon_file behavior #128
Comments
mika
added a commit
that referenced
this issue
Oct 16, 2023
If we try to copy the memtest86+.bin file as shipped with memtest86+
versions <=5.01-3.1, we either copy such an old file from the build
directory (grml_chroot), or if that doesn't exist (e.g. because the
memtest86+ package isn't installed), we might end up copying an old
memtest file from the build host system instead.
AS ${BUILD_OUTPUT}/boot/addons/memtest exists already then, we don't
update the file any longer (e.g. from a more recent memtest86+ package),
and therefore end up with an old and outdated memtest version in BIOS
boot, while EFI boot provides a more recent memtest version. This is
inconsistent and unexpected behavior.
So instead try to use the most recent version of memtest86* files first,
and only then fall back to the old memtest86+ <=5.01-3.1 file behavior.
While looking into this, I also noticed that until memtest86+ versions
<=6.10-2 it used to be named memtest86+x32.bin, while as of memtest86+
versions >=6.10-3 it's memtest86+ia32.bin instead. As we have version
6.10-4 in bookworm/stable and only pre-6 version 5.01-3.1 in e.g.
bullseye/oldstable, let's skip any backwards compatibility for
memtest86+x32.bin.
Furthermore while at it, drop duplicate execution of `copy_addon_file
memtest86+x64.bin /boot addons` and `copy_addon_file memtest86+x32.bin
/boot addons` to avoid ending up with further duplicate files on the
ISO. So related to #128, we now
ship /boot/addons/memtest on each of grml64 + grml32, and respectively
only /boot/addons/memtest86+x64.efi on grml64 only and
/boot/addons/memtest86+ia32.efi on grml32 only. To rename the files into
FAT16/8.3 compatible "/boot/addons/memtest", let's provide a proper
return code from within copy_addon_file() if we couldn't find any
matching file.
Related to #128
Closes: grml/grml#178
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Derived from grml/grml#178, we've a mixture of memtest binaries on our release ISOs, caused by files not used from the chroot but from the build system:
Being independent from specific build host is preferred and we should investigate if it's possible to get there.
As a start look into installing ipxe by default in our Grml ISOs (full vs. small might be annoying though as it's ~4MB of disk space:-/). Furthermore try to resolve the memtest confusion of ending up with 5 binaries on a ISO.
The text was updated successfully, but these errors were encountered: