o7YDv
August 10, 2024, 4:38pm
21
I have now done the same again with a Fedora-Workstation-Live-x86_64-40-1.14.iso USB stick and have found that this USB stick has NOT been changed … it only happens with the mentioned QubesOS iso’s.
fedora_stick_before.txt:
=====================
fdisk output:
=====================
Disk /dev/sda: 28,48 GiB, 30579621888 bytes, 59725824 sectors
Disk model: Transcend 32GB
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: gpt
Disk identifier: BD0CE27D-A6E0-4C37-BEEC-AB4B6F9B6A73
First usable LBA: 64
Last usable LBA: 4484024
Alternative LBA: 4484087
Partition entries starting LBA: 2
Allocated partition entries: 248
Partition entries ending LBA: 63
Device Start End Sectors Type-UUID UUID Name Attrs
/dev/sda1 64 4457875 4457812 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 BD0CE27D-A6E0-4C37-BEED-AB4B6F9B6A73 ISO9660 RequiredPartition GUID:60
/dev/sda2 4457876 4483423 25548 C12A7328-F81F-11D2-BA4B-00A0C93EC93B BD0CE27D-A6E0-4C37-BEEE-AB4B6F9B6A73 Appended2
/dev/sda3 4483424 4484023 600 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 BD0CE27D-A6E0-4C37-BEEF-AB4B6F9B6A73 Gap1 RequiredPartition GUID:60
=====================
hash values:
=====================
41018ba9a13676587c2257fe79a060e3e84a8d870b1293f8c4e8b86489659b6e /dev/sda
1e0b1d3fcd72745fb9161caa7583c7735a41f8db0a32edda3d3377e7031a5536 /dev/sda1
168495da4363d64e162d6966059bcf3a2c889adb7f66e20bd055426b07c92ad0 /dev/sda2
7818f5542a0404157573be6cffc0e0c8e68ce3c0f5d17d07ccdd9313fb700baf /dev/sda3
fedora_stick_afterwards.txt:
=====================
fdisk output:
=====================
Disk /dev/sda: 28,48 GiB, 30579621888 bytes, 59725824 sectors
Disk model: Transcend 32GB
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: gpt
Disk identifier: BD0CE27D-A6E0-4C37-BEEC-AB4B6F9B6A73
First usable LBA: 64
Last usable LBA: 4484024
Alternative LBA: 4484087
Partition entries starting LBA: 2
Allocated partition entries: 248
Partition entries ending LBA: 63
Device Start End Sectors Type-UUID UUID Name Attrs
/dev/sda1 64 4457875 4457812 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 BD0CE27D-A6E0-4C37-BEED-AB4B6F9B6A73 ISO9660 RequiredPartition GUID:60
/dev/sda2 4457876 4483423 25548 C12A7328-F81F-11D2-BA4B-00A0C93EC93B BD0CE27D-A6E0-4C37-BEEE-AB4B6F9B6A73 Appended2
/dev/sda3 4483424 4484023 600 EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 BD0CE27D-A6E0-4C37-BEEF-AB4B6F9B6A73 Gap1 RequiredPartition GUID:60
=====================
hash values:
=====================
41018ba9a13676587c2257fe79a060e3e84a8d870b1293f8c4e8b86489659b6e /dev/sda
1e0b1d3fcd72745fb9161caa7583c7735a41f8db0a32edda3d3377e7031a5536 /dev/sda1
168495da4363d64e162d6966059bcf3a2c889adb7f66e20bd055426b07c92ad0 /dev/sda2
7818f5542a0404157573be6cffc0e0c8e68ce3c0f5d17d07ccdd9313fb700baf /dev/sda3
It seems that the BIOS (?) in PC-A changes the bootable partition from second one to first one in legacy MBR reserved space in GPT:
A master boot record (MBR) is a type of boot sector in the first few blocks of partitioned computer mass storage devices like fixed disks or removable drives intended for use with IBM PC-compatible systems and beyond. The concept of MBRs was publicly introduced in 1983 with PC DOS 2.0.
The MBR holds the information on how the disc's sectors (aka "blocks") are divided into partitions, each partition notionally containing a file system. The MBR also contains executable code to function as a lo...
Based on the fdisk output the first partition should be bootable (LegacyBIOSBootable), but in the legacy MBR it’s set to second partition.
Maybe related issues:Document workarounds for installing Qubes on legacy BIOS systems · Issue #8732 · QubesOS/qubes-issues · GitHub Qubes R4.2-rc4 does not work with UEFI boot · Issue #8717 · QubesOS/qubes-issues · GitHub Qubes R4.2.0-rc2 cannot be installed on legacy BIOS system · Issue #8462 · QubesOS/qubes-issues · GitHub Installation image doesn't boot in legacy mode on some systems · Issue #8058 · QubesOS/qubes-issues · GitHub
3 Likes
So it is setting the bootable flag for special (EFI) partition and clearing the bootable flag for 2nd partition. This is really bizarre.
Qubes ISOs are using a regular parition table. Whereas Fedora ISOs (as well as Archlinux) are using ISO9660 El Torito, emulating a DVD disk. So the Fedora flash is not modified.
1 Like
o7YDv
August 10, 2024, 5:42pm
24
I don’t understand why it does that, but at least it’s not harmful, at least not if you don’t want to install QubesOS in Legancy mode.
But that doesn’t quite explain why only Qubes-R4.2.1-x86_64.iso - Qubes-R4.2.2-x86_64.iso is affected and Fedora-Workstation-Live-x86_64-40-1.14.iso and Qubes-R4.2.0-x86_64.iso e.g. is not.
I guess this is the related change:
QubesOS:main ← marmarek:iso-partitions
opened 10:08PM - 24 Nov 23 UTC
The isohybrid method produces unusual partition layout, where GPT
doesn't match … MBR partition table, but also MBR isn't really
"protective MBR" layout. Some firmware consider it broken and do not
boot properly from this media. Fdisk also doesn't detect GPT properly
(but gdisk does).
The main reason for switching to isohybrid was to have a "active" MBR
partition for legacy boot (again, some firmware look if any partition is
marked as "active", even if the actual boot code is in the MBR
itself). This can be achieved with a standard GPT + protective MBR
layout by using --mbr-force-bootable option - it adds a small partition
(covering actual MBR boot code) that is marked as "active".
Similarly add --gpt-iso-bootable option to mark some GPT partition as
legacy bootable, per xorrisofs man page:
This bit is specified as "Legacy BIOS bootable" but its true
significance is unclear. Some GPT-aware BIOS might
want to see it in some partition.
Fixes QubesOS/qubes-issues#8717
o7YDv
August 10, 2024, 6:43pm
26
This coversation was started on Nov 24, 2023 but the Qubes-R4.1.0-x86_64.iso i used for testing is from 2022-02-04 19:44.
Check the Qubes-R4.2.0-rc1-x86_64.iso and Qubes-R4.2.0-rc2-x86_64.iso images:https://mirrors.edge.kernel.org/qubes/iso/
o7YDv
August 12, 2024, 1:48pm
28
i’m sorry that i’m only replying now i only had a little time.
Can you try newer images to know which release introduced this issue and try to narrow it down?
o7YDv
August 12, 2024, 2:23pm
30
yes, but that will take some time
I have similar problem.
o7YDv
September 11, 2024, 10:43am
32
I am really sorry for the late reply, but I have had some bigger problems in the last time.
I re-tested all the images under the same conditions and these are the results, if anyone is still interested:
iso
state
Qubes-R4.1.2-x86_64.iso
N/A
Qubes-R4.2.0-rc1-x86_64.iso
PASS
Qubes-R4.2.0-rc2-x86_64.iso
PASS
Qubes-R4.2.0-rc3-x86_64.iso
N/A
Qubes-R4.2.0-rc4-x86_64.iso
N/A
Qubes-R4.2.0-rc5-x86_64.iso
FAIL
Qubes-R4.2.0-x86_64.iso
PASS
Qubes-R4.2.1-rc1-x86_64.iso
FAIL
Qubes-R4.2.1-x86_64.iso
FAIL
Qubes-R4.2.2-rc1-x86_64.iso
FAIL
Qubes-R4.2.2-x86_64.iso
FAIL
