Package: debian-installer Severity: normal X-Debbugs-Cc: die...@gnome.org Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Diego Escalante Urrelo <die...@gnome.org> To: Debian Bug Tracking System <sub...@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: die...@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