From a user perspective it is valid to combine --vmefi with --arch arm64.
+ mkfs.fat -n EFI /dev/mapper/loop0p1
mkfs.fat 4.2 (2021-01-31)
+ MKFS_OPTS=' -F -L LINUX'
+ einfo 'Running mkfs.ext4 -F -L LINUX on /dev/mapper/loop0p3p3'
+ einfon 'Running mkfs.ext4 -F -L LINUX on /dev/mapper/loop0p3p3\n'
+ '[' '' '!=' yes ']'
+ '[' einfon = ebegin ']'
+ printf ' %s*%s Running mkfs.ext4 -F -L LINUX on /dev/mapper/loop0p3p3\n' 'e[32;01m' 'e[0m'
e[32;01m*e[0m Running mkfs.ext4 -F -L LINUX on /dev/mapper/loop0p3p3
+ LAST_E_CMD=einfon
+ return 0
+ return 0
+ mkfs.ext4 -F -L LINUX /dev/mapper/loop0p3p3
mke2fs 1.47.0 (5-Feb-2023)
The file /dev/mapper/loop0p3p3 does not exist and no size was specified.
In that case an unexpected code path will be used. if is if [ -n "$VMEFI" ]; then which means that code path will be used instead of the if [ "$ARCH" = 'arm64' ]; then code path.
It's awesome that grml-debootstrap recently learned VMEFI and ARM64 support. Now we can iterate based on that.
I don't think this should be solved on the command line parsing level, i.e. unset VMEFI if using --arch amd64? Seems better to refactor, simplify all the related code. But that seems a different request than fixing this. Therefore created a separate issue for that:
From a user perspective it is valid to combine
--vmefiwith--arch arm64.In that case an unexpected code path will be used.
ifisif [ -n "$VMEFI" ]; thenwhich means that code path will be used instead of theif [ "$ARCH" = 'arm64' ]; thencode path.It's awesome that grml-debootstrap recently learned VMEFI and ARM64 support. Now we can iterate based on that.
I don't think this should be solved on the command line parsing level, i.e. unset VMEFI if using
--arch amd64? Seems better to refactor, simplify all the related code. But that seems a different request than fixing this. Therefore created a separate issue for that: