4 ms·

For me: * Not having "extended partitions" as a concept to deal with * OS booting not dependant on "load an MSDOS bootblock from LBA offset X" What I dislike

For me: * Not having "extended partitions" as a concept to deal with * OS booting not dependant on "load an MSDOS bootblock from LBA offset X" What I dislike: * Not having a minimal straightforward shell to troubleshoot from * Not letting the UEFI variables be easily user accessible/fixable

yencabulator 3y ago
> * Not having a minimal straightforward shell to troubleshoot from There is a shell for UEFI. It feels a lot like a reimplementation of MS-DOS shell, with "FS0:" to change drives etc, but it has directory listings, file copying, etc. The interface is standardized and there's an open source implementation in EDK2. If you build Linux kernels as "EFISTUB", they're simply executables in the UEFI shell. https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg https://github.com/tianocore/tianocore.github.io/wiki/ShellP...
tremon 3y ago
> Not having "extended partitions" as a concept to deal with You can BIOS boot from a GPT-partitioned disk just fine. > OS booting not dependant on "load an MSDOS bootblock from LBA offset X" The only offset that's hardcoded by the BIOS is LBA block 0. The rest is from your bootloader. And GPT partitioning allows you to put the bootloader code in a proper partition rather than in the void under the stairs: https://en.wikipedia.org/wiki/BIOS_boot_partition https://en.wikipedia.org/wiki/BIOS_boot_partition > Not having a minimal straightforward shell to troubleshoot from Download shellx64.efi from the (Intel) EFI development kit. When it's present in the root directory of your EFI System Partition, most firmwares will include an option to boot into that shell. Or is your objection that it's an DOS-inspired command prompt rather than a Unix shell? > Not letting the UEFI variables be easily user accessible/fixable Don't know about this one. The linux kernel supports reading and writing EFI variables through efivarfs, but I don't know if that is predicated on firmware support and whether it includes access to all variables.

yencabulator 3y ago

> * Not having a minimal straightforward shell to troubleshoot from There is a shell for UEFI. It feels a lot like a reimplementation of MS-DOS shell, with "FS0:" to change drives etc, but it has directory listings, file copying, etc. The interface is standardized and there's an open source implementation in EDK2. If you build Linux kernels as "EFISTUB", they're simply executables in the UEFI shell. https://github.com/tianocore/tianocore.github.io/wiki/ShellPkg https://github.com/tianocore/tianocore.github.io/wiki/ShellP...

tremon 3y ago

> Not having "extended partitions" as a concept to deal with You can BIOS boot from a GPT-partitioned disk just fine. > OS booting not dependant on "load an MSDOS bootblock from LBA offset X" The only offset that's hardcoded by the BIOS is LBA block 0. The rest is from your bootloader. And GPT partitioning allows you to put the bootloader code in a proper partition rather than in the void under the stairs: https://en.wikipedia.org/wiki/BIOS_boot_partition https://en.wikipedia.org/wiki/BIOS_boot_partition > Not having a minimal straightforward shell to troubleshoot from Download shellx64.efi from the (Intel) EFI development kit. When it's present in the root directory of your EFI System Partition, most firmwares will include an option to boot into that shell. Or is your objection that it's an DOS-inspired command prompt rather than a Unix shell? > Not letting the UEFI variables be easily user accessible/fixable Don't know about this one. The linux kernel supports reading and writing EFI variables through efivarfs, but I don't know if that is predicated on firmware support and whether it includes access to all variables.