[Bug 1895131] Re: Groovy Desktop *BREAKS* the most common method of creating UEFI bootable drives for Ubuntu installation
Thomas Schmitt
1895131 at bugs.launchpad.net
Tue Oct 6 11:04:38 UTC 2020
Hi,
> https://launchpad.net/ubuntu/+source/cd-boot-images-amd64/7
Oh. This explains why there is still an invalid GPT in
http://cdimage.ubuntu.com/daily-live/current/groovy-desktop-amd64.iso
which i downloaded 2 days ago.
Above change has at its end:
+ echo 'xorriso -as mkisofs [...]
-append_partition 2 0xef images/boot/grub/efi.img [...]
-e --interval:appended_partition_2:all:: [...]
-part_like_isohybrid -isohybrid-gpt-basdat [...]' > xorriso-cmd.txt
To blame for the invalid GPT is "-part_like_isohybrid -isohybrid-gpt-
basdat".
------------------------------------------------------------------------
I downloaded a new groovy-desktop-amd64.iso and repacked it without these
options:
dd if=groovy-desktop-amd64.iso bs=512 count=1 \
of=groovy-desktop-amd64.mbr.img
dd if=groovy-desktop-amd64.iso bs=512 skip=5715872 count=9952 \
of=groovy-desktop-amd64.efi.img
xorriso -as mkisofs \
-o test.iso \
-J -joliet-long -l \
-b boot/grub/i386-pc/eltorito.img \
-no-emul-boot -boot-load-size 4 -boot-info-table --grub2-boot-info \
--grub2-mbr groovy-desktop-amd64.mbr.img \
-append_partition 2 0xef groovy-desktop-amd64.efi.img \
-eltorito-alt-boot \
-e --interval:appended_partition_2:all:: \
-no-emul-boot \
-partition_offset 16 -r \
/mnt/iso
The numbers 5715872 and 9952 can be obtained by "/sbin/fdisk -l" or by
xorriso inspection.
This inspection
iso=groovy-desktop-amd64.iso
xorriso -indev "$iso" -report_system_area plain -report_el_torito
plain
yields for the downloaded ISO, iso=groovy-desktop-amd64.iso :
Drive current: -indev 'groovy-desktop-amd64.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito , MBR grub2-mbr cyl-align-off GPT
Media summary: 1 session, 1431622 data blocks, 2796m data, 350g free
Volume id : 'Ubuntu 20.10 amd64'
System area options: 0x00004a00
System area summary: MBR grub2-mbr cyl-align-off GPT
ISO image size/512 : 5726488
Partition offset : 16
MBR heads per cyl : 0
MBR secs per head : 0
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0xcd 64 5715808
MBR partition : 2 0x00 0xef 5715872 9952
GPT : N Info
GPT disk GUID : 7631942462da4c4797ccfb75ca94a436
GPT entry array : 2 248 separated
GPT lba range : 64 5726424 5726487
GPT partition name : 1 490053004f004800790062007200690064003100
GPT partname local : 1 ISOHybrid1
GPT partition GUID : 1 7631942462da4c4797cdfb75ca94a436
GPT type GUID : 1 a2a0d0ebe5b9334487c068b6b72699c7
GPT partition flags: 1 0x1000000000000001
GPT start and size : 1 5715872 9952
El Torito catalog : 678 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 679
El Torito boot img : 2 UEFI y none 0x0000 0x00 9952 1428968
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
El Torito img opts : 1 boot-info-table grub2-boot-info
El Torito img blks : 2 2488
The new ISO yields:
Drive current: -indev 'test.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Boot record : El Torito , MBR grub2-mbr cyl-align-off
Media summary: 1 session, 1431606 data blocks, 2796m data, 347g free
Volume id : 'ISOIMAGE'
System area options: 0x00004a00
System area summary: MBR grub2-mbr cyl-align-off
ISO image size/512 : 5726424
Partition offset : 16
MBR heads per cyl : 0
MBR secs per head : 0
MBR partition table: N Status Type Start Blocks
MBR partition : 1 0x80 0xcd 64 5715808
MBR partition : 2 0x00 0xef 5715872 9952
El Torito catalog : 678 1
El Torito cat path : /boot.catalog
El Torito images : N Pltf B Emul Ld_seg Hdpt Ldsiz LBA
El Torito boot img : 1 BIOS y none 0x0000 0x00 4 679
El Torito boot img : 2 UEFI y none 0x0000 0x00 9952 1428968
El Torito img path : 1 /boot/grub/i386-pc/eltorito.img
El Torito img opts : 1 boot-info-table grub2-boot-info
El Torito img blks : 2 2488
which is what i proposed to debian-cd and debian-live a year ago.
The GPT of the original ISO is not valid because the MBR partition table
has two partitions. GPT would be valid only if there is a single MBR
partition of type 0xee, which covers the range from LBA 1 up to the ISO's
end.
Have a nice day :)
Thomas
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to casper in Ubuntu.
https://bugs.launchpad.net/bugs/1895131
Title:
Groovy Desktop *BREAKS* the most common method of creating UEFI
bootable drives for Ubuntu installation
Status in casper package in Ubuntu:
Fix Released
Bug description:
As opposed to 20.04, Groovy Desktop decided to do away with the EFI
boot files that used to reside in `/EFI/BOOT/` on the ISO, and instead
moved them away into a FAT image located at /boot/grub/efi.img.
While this works fine when writing the image in DD mode, it completely
**BREAKS** the common method, used by many many users on Windows,
MacOS and other platforms, of simply formatting a USB drive to FAT32
and then copying the whole ISO content there in order to create a UEFI
bootable Ubuntu installation media.
Please bear in mind that this method of creating UEFI boot media is favoured by many on account that:
* It doesn't require the installation of third party software like balenaEtcher or Rufus to create the media, especially on Windows
* It is less risky to use than dd, on account that it's less prone to making a mistake with regards to the target disk. Especially, not everyone has access to 'dd', or is familiar enough with it, or even wants to use it if there exists an alternative that lets them access the content of their drive (e.g. on Windows).
* It leverages the *NATIVE* ability of UEFI to pick a bootloader from /EFI/BOOT/ which was introduced precisely to make the creation of bootable media through third party utilities (including dd) a thing of the past.
So, let me start by giving a stern warning here:
UBUNTU PEOPLE, BY HIDING THE EFI BOOT FILES AWAY IN THE ISO, YOU ARE
**NOT** HELPING YOUR USERS. INSTEAD, YOU ARE ACTIVELY **DEGRADING**
THE USER INSTALLATION EXPERIENCE. PLEASE DON'T DO THAT!
My questions therefore are twofold:
1. What on earth was the rationale behind this move? What exactly is
to be gained here?? Ubuntu 20.4 was perfectly fine with the GRUB boot
files in /EFI/BOOT/ on the ISO file system structure, and, as pointed
out above, it's hard to see how hiding these files away in efi.img is
going to improve user experience when this breaks the simplest method
of creation of a UEFI bootable media. So what prompted this sudden
unwarranted change, and why didn't anybody realize that this would
make the Ubuntu media creation experience subpar in terms of UEFI
install?
2. Can this change please, please, **PLEASE**, be reverted? I know
that drinking the ISOHybrid kool-aid and putting your eggs into one
basket by declaring that `dd` is now the "one true way" of creating
UEFI bootable media is very seducing from a maintainer's perspective.
But don't remove features that helped foster the image of Ubuntu being
focused on user-friendliness, and that are **ACTUALLY** used by more
people than you realize. Else you may find that a move that actively
prevents people from installing Linux in a manner they've been using
for years, and that really has no reason to be broken because it's
what UEFI was designed for, will be percieved as a **STRONG
INDICATION** that Ubuntu is no longer caring about its users...
Thank you.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1895131/+subscriptions
More information about the foundations-bugs
mailing list