Bug#967920: debian-installer: ewq
Package: debian-installer
Severity: normal
X-Debbugs-Cc: diegoe@gnome.org
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Diego Escalante Urrelo <diegoe@gnome.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: debian-installer: EFI: Improve Apple/Mac experience with proper volume icon, label, description and selectability of installation media
Package: debian-installer
Severity: wishlist
X-Debbugs-Cc: diegoe@gnome.org
(Tested with the 20200726-21:15 snapshot)
On Apple hardware, the installer image has no specific label or icon, it
defaults to a "drive" icon and "EFI boot" as label, and the drive is
reported as broken by macOS (and thus can't be selected in the Startup
Disk settings panel (_in_ macOS)).
The above can be handled in the following ways:
- The icon can be provided in a .VolumeIcon.icns file, at the root of
the EFI partition
- The label is a custom data format next to the boot image, named
'.disk-label', which is basically a prerendered image of the desired
text
- Additionally, after fixing the disk detection in macOS, a description
can be provided in a SystemVersion.plist file, next to the boot image,
this is used by the Startup Disk panel in macOS setting
However, the above has some challenges too:
- libicns is outdated and does not know how to build .icns files that
contain and handle all the necessary resolutions that modern Apple
bootloaders expect, you will be limited to 128px icons. If you want a
"retina" .VolumeIcon.icns, you need to use `iconutil` on macOS[1]
- the .disk-label file is a simple but custom format that would need a
generator, or pre-rendering it on a macOS with `bless` (note the label
is not device or boot specific, it's literally just data)[0]
You don't really need to generate the .VolumeIcon.icns or .disk-label
again, they are literally images, so I don't know what would be the
stance on accepting said files as already generated since they would be
generated using proprietary tools (although bless has its sources
published -- not sure about iconutil).
Generating the label+(retina)icon on a 100% libre pipeline would require
a non-trivial update to the abandoned `libicns` and writing a new script
or program that can create the custom data format[0] for .disk-label.
- the current partition table of the image is broken on macOS and the
EFI partition is not mountable, thus, you can't choose it as your next
boot option
Apparently the GPT partition table is broken and macOS is reading the
FAT EFI partition as HFS:
```
macOS:
$ diskutil list
(...)
/dev/disk2 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: Apple_partition_scheme *4.0 GB disk2
1: Apple_partition_map 4.1 KB disk2s1
2: Apple_HFS 3.0 MB disk2s2
Linux:
$ fdisk -t mbr -l /dev/sdc
Disk /dev/sdc: 3,77 GiB, 4048551936 bytes, 7907328 sectors
Disk model: Transcend 4GB
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: 0x51196c91
Device Boot Start End Sectors Size Id Type
/dev/sdc1 * 0 704511 704512 344M 0 Empty
/dev/sdc2 3908 9827 5920 2,9M ef EFI (FAT-12/16/32)
$ fdisk -t gpt -l /dev/sdc
Disk /dev/sdc: 3,77 GiB, 4048551936 bytes, 7907328 sectors
Disk model: Transcend 4GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
```
Lookin in the graphical Disk Utility, the partition is labeled as type
"FAT-12", but it's impossible to mount it. This is likely just a bug in
how things are created for the image.
The SystemVersion file is a simple XML file.
---
I believe the above would enhance the installation experience, and
similar changes could be added to the _installed_ system too. Fedora
does something like this with a `mactel-boot` package[2] that drops the
right files in the right place (but note that they are limited to a
128px icon because of the libicns limitations[3]).
I can help provide the necessary files, if it's acceptable to use macOS'
`bless` and `iconutil` to generate them -- since I'm not interested in
becoming a new upstream for libicns :P :P :P.
Also happy to try to provide a patch that does the integration, perhaps
in the same vein as `mactel-boot`[2], if someone points me in the right
direction :) (where would this even go? d-i? a new package?).
0 - http://refit.sourceforge.net/info/vollabel.html
1 - https://github.com/diegoe/libreicns/
2 - https://src.fedoraproject.org/rpms/mactel-boot/tree/master
- https://src.fedoraproject.org/rpms/mactel-boot/blob/master/f/mactel-boot-setup
3 - https://pagure.io/generic-logos/blob/master/f/Makefile
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Reply to: