Hi, Dominik 'Rathann' Mierzejewski wrote: > > > Dell XPS 15 L502X 8GB RAM (BIOS only) BIOS-only on a laptop might mean the firmware quirk which demands to see the "boot/active" flag at some MBR partition table slot. See a thread of grub-bug (and later grub-devel) from 2015/16 https://marc.info/?l=grub-bug&m=145052506901159&w=2 where Alexander E. Patrakov wrote: "Subject: [bug #46716] Protective MBR partition is not marked as bootable [...] Changing the byte at offset 0x1be to 0x80 in the resulting iso makes it bootable on such boards." This led to the creation of xorrisofs option --mbr-force-bootable in xorriso-1.4.3. Does the following bash hack "repair" the USB stick so that it boots on the affected machine ? echo $'\x80' | dd of=/dev/sdX conv=notrunc bs=1 seek=446 count=1 (Of course with outmost care when choosing the real sdX name. Users who have a safe copy-image-to-USB-stick program should consider to patch the image file instead and then copy it to the stick. Therefore i added the "conv=notrunc" option to this proposal.) The difference will not show up in partition editor listings, except possibly as complaint that this boot/active flag with the 0xEE partition is illegal. EFI systems might refuse to boot from this stick for the same reason. If it turns out that we here face this BIOS bug, then a decision is needed whether those firmwares shall stay supported. If yes, then the mildest known remedy would be to add xorrisofs option --mbr-force-bootable which will cause a second MBR partition of type 0x00 from LBA 0 with size 1 and boot/active flag. Something like: MBR partition table: N Status Type Start Blocks MBR partition : 1 0x00 0xee 1 1334255 MBR partition : 2 0x80 0x00 0 1 EFI implementations are supposed to ignore the partition of type 0x00. Buggy BIOS should be happy with its boot/active flag (Status 0x80). Normal BIOS should not care for that flag, which is rather a hint for a class of x86 MBR code on which PBMR to hop. GRUB's MBR is not of that class. xorrisofs option --mbr-force-bootable may be added to the grub-mkrescue arguments. If we indeed face this bug, then a grub-mrescue ISO with EFI equipment should not boot on the affected machine, unless this extra option was given at production time. Have a nice day :) Thomas _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
