7 ms·

- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partitio

by mjg59 5y ago

- previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1]. GPT may involve GUIDs, but in the grand scheme of things that's a small part of the cost of mounting stuff. - FAT is old, and FAT is well-supported by basically anything, and what features do you want in the partition that contains your bootloader that FAT doesn't support? - Yeah in an ideal universe we wouldn't have to deal with PE binaries and we wouldn't have to deal with the Windows 64-bit calling convention for jumping into the firmware and also we've solved all of this shit and it just isn't a big deal any more. We can look at any platform and complain about the implementation details, but at least this one is better documented than the BIOS interface ever was. In summary: Linux has to boot on computers that exist, and most computers that exist have UEFI. The Linux community has had the opportunity to make meaningful improvements to the UEFI spec in a way that wasn't true with BIOS. UEFI isn't ideal, but it's better than what came before in this respect. [1] Partitions could be identified as "Linux", but that gave you no information about what they were or where they should be mounted. Current systemd-driven development has allowed us to define the partition mount point as part of the GPT data, which means they can be automatically mounted in the correct place without static configuration about partition layout

blueflow 5y ago
- mjg59 5y ago
  I'm responsible for a great deal of the UEFI support on x86 Linux systems. You're absolutely free to have concerns about a lot of the political and social positions I hold, but this is a topic where I am literally a domain expert. If you disagree with me on this subject, present technical arguments.
  - mwcampbell 5y ago
    As a newcomer to this thread, just wanted to say thanks for bringing your domain expertise to this discussion even though you're certainly not obligated to do so. And, though I presume you've been paid for at least some of the work you've done on Linux UEFI support, thanks for that as well. I'm thankful that someone is willing to go to the trouble to make Linux relatively easy to boot and install on modern PCs, though I imagine the desktop Linux space isn't very lucrative.
- scrollaway 5y ago
  As an outsider to this debate, you’re the hostile party. You’re replying with name calling to someone who gave you a respectful and detailed answer.
  - blueflow 5y ago
    [flagged]
  - howinteresting 5y ago
    blueflow's favorites list is remarkably revealing.
    - blueflow 5y ago
      Check the screenshot i posted in your sister post and guess why the font colors are off.
    - blueflow 5y ago
      i fixed it! thanks for reminding me.
qwerty456127 5y ago
> what features do you want in the partition that contains your bootloader that FAT doesn't support? Well, I'd love to be able to drop a bunch of 8GB (notably FAT doesn't support files this big) LiveDVD disk images on a bare file system and see them in the computer's built-in boot-menu immediately. I already enjoy the fact I don't need a traditional boot loader (like GRUB) to handle multi-OS as I can have 2 independent EFI boot partitions (one for Windows and one for Linux) and use the computer's boot menu too choose which to boot from. Ideally the whole OS should be just a read-only boot image and a traditional partition should only be used for config/data files IMHO.
- zozbot234 5y ago
  > notably FAT doesn't support files this big ExFAT can support those. You could also use the UDF file system.
  - blueflow 5y ago
    ExFAT is not supported by EFI.
  - qwerty456127 5y ago
    But ExFAT lacks the FAT's virtues of being universally supported and royalty-free, yet still is a very dumb FS with no journal (which means unreliable) and no extended attributes (which means data-metadata separation impossible) so I don't see a reason for it to exist anywhere outside severely resource-limited embedded applications. I would rather use Ext4 everywhere for everything. Is the problem preventing wide adoption of Ext4 GPL?
    - Macha 5y ago
      NTFS hasn't been widely adopted by firmware manufacturers either. I don't think firmware manufacturers want to spend time implementing support for even the NTFS/ext/APFS era of filesystems, never mind anything newer like ZFS or btrfs.
      - 5y ago
zozbot234 5y ago
> previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1] LVM appears to solve this issue as well as the related issue of only supporting a limited number of partitions in BIOS.
- chasil 5y ago
  I believe that btrfs can be whole-disk and avoid partitions entirely, which would drastically simplify things. The only snag is swap, which I don't believe can be on a subvolume. vgchange is a struggle for me, from the first time I saw it in HP-UX.
  - asveikau 5y ago
    > The only snag is swap, which I don't believe can be on a subvolume. Linux can make swap a regular file, even. It doesn't need to be a partition. Google result shows: https://wiki.archlinux.org/title/swap#Swap_file https://wiki.archlinux.org/title/swap#Swap_file
    - StillBored 5y ago
      And its something you want to do for security reasons anyway, since linux by default isn't encrypting swap partitions. Putting swap on an LUKs encrypted partition is a bit of a PITA but allows one to hibernate/resume without fear that ones private keys end up in plaintext stored on a disk.
      - forty 5y ago
        And relevant to OP, you cannot hibernate on Linux with secure boot enabled, I think precisely because Linux doesn't know how to sign/encrypt the RAM dump (no idea how it's actually called)
        StillBored 5y ago
        Well, its an artificial limitation on secure boot in the Linux kernel pending some cleaups, and is fairly trivial to work around if your willing to comment out the line in question build your own kernel and sign it with a key of your own creation you have enrolled in the firmware. The problem is less about linux being capable of encrypting/protecting the swap file and more around being able to assure that is true. So like many Linux kernel issues recently its less technical, more political. So, as I mentioned previously its entirely possible with off the shelf distro's to enable encrypted swap, the average user just has to choose between hibernate, assuring the swap is secure, and secure boot. Its a bit irritating, but seems to be low priority as the focus seems to be on suspend or hibernate without secure boot.
dinosaurdynasty 5y ago
> what features do you want in the partition that contains your bootloader that FAT doesn't support? Atomic updates and not getting corrupted if the power is pulled/lost while the filesystem is being written to.
- StillBored 5y ago
  I suspect your thinking about FAT as a general purpose filesystem rather than the uEFI System Partition (ESP). For the latter case, one simply serializes access to the FAT/directory and renames files into their final resting place. That is going to be as robust and uncorruptable as any of the more "advanced" file systems jouraling mechanisms. Sure you might have a lost FAT chain, or a FAT chain mismatch between FAT copies, but its not going to cause a boot problem and a FAT "fsck" operation done during boot is going to be the equivalent of throwing the incomplete journal entries away, and probably just as fast given most ESP's contain a less than a dozen files. So, not a problem, with the huge advantage FAT can be implemented/validated/etc in a few dozen lines of code. KISS
sounds 5y ago
- edgyquant 5y ago
  I don’t think this is an important detail, if anything it may skew people against them as it seems they have corporate interests
- homarp 5y ago
  workED for Red Hat, per wikipedia: https://en.m.wikipedia.org/wiki/Matthew_Garrett https://en.m.wikipedia.org/wiki/Matthew_Garrett Right now at Aurora
- dralley 5y ago
  Matthew left Red Hat 10 years ago. If you're going to "full disclosure" people, you should probably do a better job with the details.
Dwedit 5y ago
FAT filesystems tend to get the cluster chains corrupted, then all your files are suddenly truncated to exactly 1 cluster long. So I'd rather use EXT3 or NTFS because of Journaling, and not FAT.

by mjg59 5y ago

blueflow 5y ago

mjg59 5y ago
I'm responsible for a great deal of the UEFI support on x86 Linux systems. You're absolutely free to have concerns about a lot of the political and social positions I hold, but this is a topic where I am literally a domain expert. If you disagree with me on this subject, present technical arguments.
- mwcampbell 5y ago
  As a newcomer to this thread, just wanted to say thanks for bringing your domain expertise to this discussion even though you're certainly not obligated to do so. And, though I presume you've been paid for at least some of the work you've done on Linux UEFI support, thanks for that as well. I'm thankful that someone is willing to go to the trouble to make Linux relatively easy to boot and install on modern PCs, though I imagine the desktop Linux space isn't very lucrative.
scrollaway 5y ago
As an outsider to this debate, you’re the hostile party. You’re replying with name calling to someone who gave you a respectful and detailed answer.
- blueflow 5y ago
  [flagged]
- howinteresting 5y ago
  blueflow's favorites list is remarkably revealing.
  - blueflow 5y ago
    Check the screenshot i posted in your sister post and guess why the font colors are off.
  - blueflow 5y ago
    i fixed it! thanks for reminding me.

qwerty456127 5y ago

> what features do you want in the partition that contains your bootloader that FAT doesn't support? Well, I'd love to be able to drop a bunch of 8GB (notably FAT doesn't support files this big) LiveDVD disk images on a bare file system and see them in the computer's built-in boot-menu immediately. I already enjoy the fact I don't need a traditional boot loader (like GRUB) to handle multi-OS as I can have 2 independent EFI boot partitions (one for Windows and one for Linux) and use the computer's boot menu too choose which to boot from. Ideally the whole OS should be just a read-only boot image and a traditional partition should only be used for config/data files IMHO.

zozbot234 5y ago
> notably FAT doesn't support files this big ExFAT can support those. You could also use the UDF file system.
- blueflow 5y ago
  ExFAT is not supported by EFI.
- qwerty456127 5y ago
  But ExFAT lacks the FAT's virtues of being universally supported and royalty-free, yet still is a very dumb FS with no journal (which means unreliable) and no extended attributes (which means data-metadata separation impossible) so I don't see a reason for it to exist anywhere outside severely resource-limited embedded applications. I would rather use Ext4 everywhere for everything. Is the problem preventing wide adoption of Ext4 GPL?
  - Macha 5y ago
    NTFS hasn't been widely adopted by firmware manufacturers either. I don't think firmware manufacturers want to spend time implementing support for even the NTFS/ext/APFS era of filesystems, never mind anything newer like ZFS or btrfs.
    - 5y ago

zozbot234 5y ago

> previously, x86 MBR-style partition tables (which were the only thing really supported in Linux) gave you no strong semantic information about what a partition was[1] LVM appears to solve this issue as well as the related issue of only supporting a limited number of partitions in BIOS.

chasil 5y ago
I believe that btrfs can be whole-disk and avoid partitions entirely, which would drastically simplify things. The only snag is swap, which I don't believe can be on a subvolume. vgchange is a struggle for me, from the first time I saw it in HP-UX.
- asveikau 5y ago
  > The only snag is swap, which I don't believe can be on a subvolume. Linux can make swap a regular file, even. It doesn't need to be a partition. Google result shows: https://wiki.archlinux.org/title/swap#Swap_file https://wiki.archlinux.org/title/swap#Swap_file
  - StillBored 5y ago
    And its something you want to do for security reasons anyway, since linux by default isn't encrypting swap partitions. Putting swap on an LUKs encrypted partition is a bit of a PITA but allows one to hibernate/resume without fear that ones private keys end up in plaintext stored on a disk.
    - forty 5y ago
      And relevant to OP, you cannot hibernate on Linux with secure boot enabled, I think precisely because Linux doesn't know how to sign/encrypt the RAM dump (no idea how it's actually called)
      - StillBored 5y ago
        Well, its an artificial limitation on secure boot in the Linux kernel pending some cleaups, and is fairly trivial to work around if your willing to comment out the line in question build your own kernel and sign it with a key of your own creation you have enrolled in the firmware. The problem is less about linux being capable of encrypting/protecting the swap file and more around being able to assure that is true. So like many Linux kernel issues recently its less technical, more political. So, as I mentioned previously its entirely possible with off the shelf distro's to enable encrypted swap, the average user just has to choose between hibernate, assuring the swap is secure, and secure boot. Its a bit irritating, but seems to be low priority as the focus seems to be on suspend or hibernate without secure boot.

dinosaurdynasty 5y ago

> what features do you want in the partition that contains your bootloader that FAT doesn't support? Atomic updates and not getting corrupted if the power is pulled/lost while the filesystem is being written to.

StillBored 5y ago
I suspect your thinking about FAT as a general purpose filesystem rather than the uEFI System Partition (ESP). For the latter case, one simply serializes access to the FAT/directory and renames files into their final resting place. That is going to be as robust and uncorruptable as any of the more "advanced" file systems jouraling mechanisms. Sure you might have a lost FAT chain, or a FAT chain mismatch between FAT copies, but its not going to cause a boot problem and a FAT "fsck" operation done during boot is going to be the equivalent of throwing the incomplete journal entries away, and probably just as fast given most ESP's contain a less than a dozen files. So, not a problem, with the huge advantage FAT can be implemented/validated/etc in a few dozen lines of code. KISS

sounds 5y ago

edgyquant 5y ago
I don’t think this is an important detail, if anything it may skew people against them as it seems they have corporate interests
homarp 5y ago
workED for Red Hat, per wikipedia: https://en.m.wikipedia.org/wiki/Matthew_Garrett https://en.m.wikipedia.org/wiki/Matthew_Garrett Right now at Aurora
dralley 5y ago
Matthew left Red Hat 10 years ago. If you're going to "full disclosure" people, you should probably do a better job with the details.

Dwedit 5y ago

FAT filesystems tend to get the cluster chains corrupted, then all your files are suddenly truncated to exactly 1 cluster long. So I'd rather use EXT3 or NTFS because of Journaling, and not FAT.