search

void-linux / void-mklive

The Void Linux live image maker
https://voidlinux.org
Other
328 stars 194 forks source link

Use limine as the bootloader for both UEFI and BIOS. #314

Closed mobinmob closed 1 year ago

mobinmob commented 1 year ago

This PR implements a solution to https://github.com/void-linux/void-mklive/issues/313 . It uses limine, a single, well maintained bootloader with a single and simple configuration to replace isolinux and grub. It successfully boots in my tests - suggestions for improvements are welcome!

~As limine is not available, I made a single-package repo for it, signed with my key. Anyone can test this PR by running mklive.sh wiith:~

~# ./mklive.sh -r https://ftp.halifax.rwthaachen.de/osdn/storage/g/a/av/avyssos/mklive-pkgs~

~Or build complete isos with build-x86-images:~

~# ./build-x86-images.sh -r https://ftp.halifax.rwth-aachen.de/osdn/storage/g/a/av/avyssos/mklive-pkgs -b base~

mobinmob commented 1 year ago

Limine is now available in the repo, so no need for the unofficial one :)

mobinmob commented 1 year ago

how was splash.bmp generated? is it simple enough that it could be done at runtime? if not, should it replace splash.png?

It was converted from the png using gimp :p

not commenting on functionality just yet, would need to test this locally first

mobinmob commented 1 year ago

@classabbyamp Thanks for the review, all done :) The reason I tried my hand at this is that I find limine a better choice than both isolinux and grub for a live cd. Simpler to configure and install for both uefi and bios, single conf file... extlinux/isolinux is not really developed anymore AFAICT and grub is an unbelievably featurefull and complex beast - a fantastic choice for those that need the features, but an overkill for a live cd.

0x5c commented 1 year ago

I built an x86_64 live image from this PR. The generated ISO contains a rather odd set of partitions for a live image

$ lsblk -f                                             
NAME        FSTYPE    FSVER      LABEL     UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       iso9660   Joliet Ext VOID_LIVE 2023-02-24-04-38-11-00                              
├─loop0p1   iso9660   Joliet Ext VOID_LIVE 2023-02-24-04-38-11-00                              
├─loop0p2   vfat      FAT12      VOID_LIVE 44E7-1D24                                           
└─loop0p3   iso9660   Joliet Ext VOID_LIVE 2023-02-24-04-38-11-00

compared to the last official live image

$ lsblk -f                                             
NAME        FSTYPE    FSVER      LABEL     UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       iso9660   Joliet Ext VOID_LIVE 2022-10-01-17-45-36-00                              
├─loop0p1   iso9660   Joliet Ext VOID_LIVE 2022-10-01-17-45-36-00                              
└─loop0p2   vfat      FAT12      grub_uefi C35E-68B8

When checked with cfdisk, the latest image appears to be using a MBR partition table while the Limine one appears to be using GPT. IIRC this would make it non-bootable on BIOS systems. It's also odd how two of the partitions show as iso9660.

I tested the live image on an x86_64 machine using EFI. Limine starts properly, menu/etc works, it loads linux and the initrd just fine, but dracut fails to find the root and switch to it.

mount: /run/initramfs/live: unknown filesystem type ''.
       dmesg(1) may have more information after failed mount system call.
[    6.526684] dracut: FATAL: Failed to mount block device of live image
[    6.526686] dracut: Refusing to continue

[... about 5 minutes later ...]

dracut Warning: Could not boot.

dracut Warning: dracut: FATAL: Failed to mount block device of live image
dracut Warning: dracut: Refusing to continue
dracut Warning: "/dev/root" does not exist

[dracut drops to a rescue shell]

Astonishingly, booting this live image from grub loopback works flawlessly, despite there being 3 partitions with the same label it looks for. loading the kernel+initrd directly from a bootloader outside the ISO and letting dracut find the iso+squashfs+ext3fs

mobinmob commented 1 year ago

@0x5c Thanks for testing!

I have the following results while testing with a fresh base iso:

lsblk -f output from vbox with uefi: https://termbin.com/dx75t lsblk -f output from vbox with bios: https://termbin.com/6rn91

(Yes, ofc they are the same :P )

It is entirelly possible I have some error in xorriso when creating the image.

@mintsuki : Any ideas where to look for the cause?

@0x5c Can you please check if your image works on vbox?

mintsuki commented 1 year ago

@0x5c GPT images boot on most BIOS systems, the few BIOS systems that I encountered that refuse to boot a ISOHYBRID (which this image is) are actually UEFI capable systems that see that a GPT is present and refuse to boot the image using CSM (which is a non issue since these systems are UEFI capable).

mintsuki commented 1 year ago

@mobinmob I'm not sure about that dracut issue, but it doesn't sound Limine-related to me. Perhaps the stray leading spaces on the kernel command lines may have something to do?

mobinmob commented 1 year ago

@mobinmob I'm not sure about that dracut issue, but it doesn't sound Limine-related to me. Perhaps the stray leading spaces on the kernel command lines may have something to do?

Thank you for the review! Chainload now works on bios. The other issue is something with dracut, I agree, I am just trying to determine where to start searching. Booting from usb disk while chainloading the iso by ventoy but not when it is written by dd is weird (exactly same usb disks, same pc(s).

0x5c commented 1 year ago

GPT images boot on most BIOS systems, the few BIOS systems that I encountered that refuse to boot a ISOHYBRID (which this image is) are actually UEFI capable systems that see that a GPT is present and refuse to boot the image using CSM (which is a non issue since these systems are UEFI capable).

I have at least one non-UEFI machine on which an image form this PR does not boot (Pentium D x86_64). It's old enough to not know GPT, and as such does not recognise the USB drive as bootable. Being that the current images are also ISOHYBRID, I think there's probably something wrong with the new xorriso incantation.

I'm only a void contributor and my review & comments are just my opinion, but seeing the level of compatibility with old devices that void requires for most things, I don't think "boots on most BIOS systems" is going to be enough for the official live images. It seems that they're expected to function on a Pentium 4 system.

I'm not sure about that dracut issue, but it doesn't sound Limine-related to me. Perhaps the stray leading spaces on the kernel command lines may have something to do?

I think it may be a limine issue, in that the xorriso invocation required by limine does not seem to produce truly valid ISOs, at least when written to a USB drive. The kernel seems to agree there's something funny going on when one such USB drive is plugged in:

[27fév 03:57] usb 1-3: new high-speed USB device number 25 using xhci_hcd
[  +0,126954] usb 1-3: New USB device found, idVendor=8644, idProduct=800f, bcdDevice= 1.00
[  +0,000009] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0,000004] usb 1-3: Product: USB Flash Disk
[  +0,000003] usb 1-3: Manufacturer: General
[  +0,000003] usb 1-3: SerialNumber: 05103100000011F2
[  +0,001548] usb-storage 1-3:1.0: USB Mass Storage device detected
[  +0,000401] scsi host1: usb-storage 1-3:1.0
[  +1,009571] scsi 1:0:0:0: Direct-Access     General  USB Flash Disk   1.0  PQ: 0 ANSI: 2
[  +0,001282] sd 1:0:0:0: [sdb] 3913728 512-byte logical blocks: (2.00 GB/1.87 GiB)
[  +0,000548] sd 1:0:0:0: [sdb] Write Protect is off
[  +0,000013] sd 1:0:0:0: [sdb] Mode Sense: 03 00 00 00
[  +0,000347] sd 1:0:0:0: [sdb] No Caching mode page found
[  +0,000011] sd 1:0:0:0: [sdb] Assuming drive cache: write through
[  +0,006018] GPT:Primary header thinks Alt. header is not at the end of the disk.
[  +0,000006] GPT:1282111 != 3913727
[  +0,000005] GPT:Alternate GPT header not at the end of the disk.
[  +0,000002] GPT:1282111 != 3913727
[  +0,000004] GPT: Use GNU Parted to correct GPT errors.
[  +0,000011]  sdb: sdb1 sdb2 sdb3
[  +0,000497] sd 1:0:0:0: [sdb] Attached SCSI removable disk

My guess is that either vbox/ventoy/etc are using more fault-tolerant iso9660 parsing, or that they succeed to boot the image because there's no physical volume for the image to not play nice with. Either way, the live images have to be valid once written to physical media.

mobinmob commented 1 year ago

@0x5c Many thanks again from a fellow contributor for taking the time to test this PR and give quality feedback.

My guess is that either vbox/ventoy/etc are using more fault-tolerant iso9660 parsing, or that they succeed to boot the image because there's no physical volume for the image to not play nice with. Either way, the live images have to be valid once written to physical media.

That is a reasonable assumption. I tried to find something that will trigger this odd behaviour in dracut with no results - but I am not really familiar with the codebase.

On a slightly unrelated note, the reference of EasyOS by @mintsuki in their limine PR made me revisit the articles about the refusal by Barry Kauler to produce live isos for it, choosing to create and release disk image files instead. Anyway, that is a seperate issue :)

Ι will try to find a solution for the issue and close the PR if I fail.

0x5c commented 1 year ago

I'm fairly busy this week, but I'll be exploring possible solutions too

mintsuki commented 1 year ago

@0x5c Limine does not require any special xorriso incantation. You can generate bootable images (or disks) using Limine a whole number of different ways.

The reference xorriso command (as provided in Limine's own README) produces an ISOHYBRID using GPT + a protective MBR (as well as the actual ISO filesystem). This command is actually very similar to (almost taken right from) the one used by GRUB2 in their grub-mkrescue utility.

Given that I have hardly ever heard reports of an ISO generated in such matter not booting on any given system, I am inclined to believe that the modifications to the reference xorriso command made by @mobinmob are (at least partly) to blame, and I'd suggest sticking as closely as possible to the reference xorriso "incantation" to avoid this sort of issues.

Additionally, I would disregard the warnings raised by the Linux kernel w.r.t. the secondary GPT header not being at the end of the disk since this is something that would happen any time a GPT partitioned image is written to media of different size than the image itself.

When it comes to the dracut/initramfs issue, if it expects the medium to be formatted/partitioned in a certain way and this given ISOHYBRID format is incompatible with expectations, that is outside Limine's (or xorriso's) responsibility at that point.

mobinmob commented 1 year ago

The reference xorriso command (as provided in Limine's own README) produces an ISOHYBRID using GPT + a protective MBR (as well as the actual ISO filesystem). This command is actually very similar to (almost taken right from) the one used by GRUB2 in their grub-mkrescue utility.

Given that I have hardly ever heard reports of an ISO generated in such matter not booting on any given system, I am inclined to believe that the modifications to the reference xorriso command made by @mobinmob are (at least partly) to blame, and I'd suggest sticking as closely as possible to the reference xorriso "incantation" to avoid this sort of issues.

I changed the command to be close to the reference in the limine documentation, thanks :) It does not seem to make any difference regarding to the issue, unfortunatelly. On some conditions, dracut cannot boot from the partition labeled VOID_LIVE. There are two of them recognised, with the same UUID - at least that is how they appear in the blkid output at the dracut shell.

mintsuki commented 1 year ago

@mobinmob Thanks for applying my suggestion. Mind you, it wasn't intended as a fix for the dracut issue, but rather as a fix for @0x5c 's claim that Limine failed to boot on their Pentium 4 system.