Pacman complains after Gummiboot upgrade

Question

Hi,
just updated to gummiboot 24-1 which replaced gummiboot-efi. After installation pacman complained:
File system /boot is not a FAT EFI System Partition (ESP) file system.
Fehler: Befehl konnte nicht korrekt ausgeführt werden (Error: Command not executed)
I just wonder why gummiboot assumes /boot to be a FAT ESP? I mount my ESP at /boot/efi, because I thought this is common practice. Furthermore which command was not executed? Anyhow system is booting normal, so not a big deal.
Last edited by tobsen (2013-03-05 19:00:27)

Answer 1

65kid wrote:
srs5694 wrote:Imagine, for instance, one distribution setting up gummiboot on the ESP; then another one comes along and its installer decides that the ESP is too crowded, so it sets up gummiboot on a separate Freedesktop partition.
This is something that I would consider a buggy installer.
Perhaps -- but the Freedesktop spec creates more room for such bugs to be created than would other alternatives. All other things being equal (which I realize they aren't), it's better to have a spec that gives fewer opportunities for bugs in implementations than a spec that gives more opportunities for such bugs to breed.
Even if creating a separate ESP was a good idea, how would the installer even do that? It would have to shrink another partition first which is way too risky.
No, it wouldn't. An OS installer is presumably creating partition(s) for the OS, so that means that either the disk already has free space or an existing partition must be shrunk to make free space to install the OS. The second ESP or Freedesktop partition would just go in that free space. There's no rule that says that either the ESP or the Freedesktop partition must go before other partitions on the disk, although doing so is advisable because putting an ESP in the middle of the disk increases the odds that it will have to be moved in the future. Also, note that one of my points is that having two ESPs on a disk is inadvisable because Windows doesn't like such configurations; thus, I'd say that it's better to create a Freedesktop boot partition than a second ESP.
srs5694 wrote:Thus, the safest choice -- the one that's most likely to work with the greatest number of computers -- is to put the Linux boot loader (or a boot manager, at least) on the ESP, even if it's small, and put the kernel elsewhere.
But putting the kernel elsewhere is crazy for a simple reason: what if my root including the kernel is on an encrypted drive, RAID, LVM etc.?
I said "elsewhere," not "the Linux root (/) partition." In this context, "elsewhere" could easily be a separate Linux /boot partition, which can reside outside of the LVM or RAID, be unencrypted, be FAT, etc.
That's exactly what gummiboot is about - do only what the boot loader needs to do, let the kernel deal with the rest.
I would argue that "what the boot loader needs to do" should include "read partitions other than the one from which it was loaded." In the BIOS world, this pretty much goes without saying. In the EFI world, it's easier to create a boot loader that can read only from its own partition, but that will inevitably lead to problems on some systems and configurations.
And "the greatest number of computers" won't even care if their ESP is only 100MB, because they only use one OS. And whoever needs more should simply make the ESP big enough in the first place.
By "greatest number of computers" I meant the largest possible number, not the majority. Yes, the majority can probably make do with a 100MiB ESP, but to maximize usability, other configurations are more flexible and therefore preferable.
WonderWoofy wrote:I don understand why srs5694 includes the filesystem drivers in his rEFInd, but also understand your point about having the boot manager be as simple as possible like gummiboot.
Clearly there's a typo; I'm not sure if you mean you do understand or that you don't understand. In case it's the latter, it's because (a) they were available with the rEFIt source code and so could be (relatively) easily included with rEFInd; and (b) because including them in rEFInd greatly simplifies installing and using rEFInd on typical Fedora, Ubuntu, SUSE, and other distributions. These distributions typically either don't use LVM or use a separate ext2/3/4fs /boot partition. It's currently possible to download a Debian package or RPM of rEFInd, install it on one of these distributions, and have it all work without further tweaking, at least in most cases. (If the user uses XFS, JFS, Btrfs, or something else unusual to hold the kernel, this won't work without additional reconfiguration; but the default settings for these distributions put the kernel outside of LVM/RAID setups in ext4fs partitions.) In the end, this is partially labor saving for me, too; users tend to want things to Just Work, and when they don't, they e-mail me for help. Without those drivers, rEFInd does not Just Work on the more popular distributions, but with them, it does, so I spend less time answering e-mail.
It seems that the filesystem driver is optional and is only available if the necessary drivers are placed on the ESP.
rEFInd's filesystem drivers are implemented as separate binaries from rEFInd itself, so you can run rEFInd without using the drivers at all. Currently, the install.sh script (which I believe the Arch package omits) attempts to determine what filesystem is used on /boot and installs it, if necessary. If it's not necessary (say, if the filesystem is FAT), no filesystem driver gets installed unless the --alldrivers option is passed to install.sh. It's possible to use rEFInd's filesystem drivers without using rEFInd, but most EFIs lack support for loading filesystem drivers automatically, so the trick is to get them loaded.
65kid wrote:Modularity may be a good thing, duplicating logic still isn't, even if it's "just" a filesystem driver. The kernel already knows how to do it and it knows how to do it best, why waste effort duplicating the same logic into the bootloader?
Rudictio ad absurdum: The kernel already knows how to accept keyboard input, so why duplicate that functionality in a boot loader?
The answer is the same in both cases: Because it's necessary, or at least helpful, before the kernel loads.
I'm more than happy to admit that it's not necessary for the EFI or a boot loader to read Linux-specific filesystems if the user/installer sets up the computer with the kernel on a FAT filesystem. The problem is that in the real world, that conditional clause is often false. Note my earlier comments about Ubuntu, Fedora, etc. -- they all place their kernels on ext2/3/4 filesystems by default. Even many Arch users today have scripts and whatnot to copy their kernels to the ESP from /boot on some other filesystem. Yes, this becomes simpler if the ESP is mounted at /boot -- but as I've pointed out in this thread, doing this has its drawbacks, too, particularly when the user is a novice who hasn't thought things through or when using software (including third-party OSes) that set things up in a way that's not optimal for this type of configuration. I chose to fork rEFIt to rEFInd in order to glue together all the pieces I saw lying around that could almost handle the real-world situation. Now (as rEFInd) it can.
65kid wrote:I admit that I don't have a good understanding of how these EFI filesystem drivers work, but wouldn't you have also have to keep the EFI driver up-to-date separately?
Yes, but read-only filesystem drivers need little maintenance once they're stabilized. All of rEFInd's filesystem drivers are read-only, so they pose no real threats to your data.
WonderWoofy wrote:As far as updating the driver, I would imagine that this would be inclusive in the rEFInd updates.  But moving the necessary files to the proper places might indeed be manual (rEFInd is not my primary boot manager, so I am not sure if there is automagic function to be included here).
The install.sh script included with rEFInd will update the driver(s) along with the rEFInd binary and icons. Unfortunately, the Arch packagers have chosen to omit this script from the Arch packages (or they had the last time I checked).
65kid wrote:I didn't mean to say that these EFI drivers are complete non-sense, whoever thinks this is the better approach or has a special usecase for it has the option and may use it. I personally just don't see the usecase
Given the relative market shares of Arch vs. Fedora or Arch vs. Ubuntu, it's really the Arch way of doing things that qualifies as the "special usecase." The drivers -- and especially the ext4fs driver -- help a lot with installing rEFInd on these distributions and getting it working painlessly.
progandy wrote:Simply support kernel on ESP, if Windows cannot deal with more than one ESP that is not our problem to solve. The user will have to resize the partition in this case.
Philosophically, you're right -- Windows' bugs and limitations belong to Microsoft. Practically, I'm afraid it's not that simple -- if John Doe installs Linux and then tries to re-install Windows and discovers that it flakes out because of something that Linux put on the hard disk, who will John blame? Maybe Microsoft, but maybe Linux. Furthermore, if a Linux developer knows that the Windows bug exists, is the developer justified in ignoring that bug, knowing that doing so will cause John Doe problems in the future? IMHO, the answer is "no" -- although with the caveat that the difficulty of finding a solution is a factor, too.
As to resizing the ESP, as I wrote in post #12 in this thread, you shouldn't do that unnecessarily, since it will almost certainly require deleting or resizing the first partition that follows the ESP, and in some cases a partition or two after that, as well. Resizing partitions from their start points is inherently dangerous, so any policy that requires doing this will damage somebody's filesystem. This is an even clearer case where developers' decisions can have negative consequences, and developers have a moral obligation to avoid causing such problems (such as data loss), even indirectly.
I'd just like to take a step back from all this to clarify my main point: The Freedesktop proposed loader spec is a worthwhile attempt to address certain problems with boot loaders as they're currently implemented in Linux. I agree with most of their goals and some of the details of that proposal. If it were implemented universally tomorrow, though, it would cause problems. The main reason is because of gummiboot's limitations, which seem to have motivated many of the proposal's details. (Let me say that I'm not trying to trash gummiboot here; I do respect it, but it also has limitations that have important implications when it's used as the core of a proposal like this one.) Consider:
An existing installation has Windows and an ESP that's too small. Under the Freedesktop guidelines, a new Freedesktop partition will be created and used to hold kernels. I don't believe the proposal is specific about where the boot loader must reside, but there are two choices: Put gummiboot on the ESP, in which case it can launch Windows but not Linux; or put gummiboot on the Freedesktop boot partition, where it can launch Linux but not Windows. In either case it's not very useful by itself. In the latter case, the EFI might not even launch it, since the Freedesktop partition isn't an ESP, and IIRC, the EFI spec doesn't require the EFI to be able to launch boot programs on a non-ESP.
Now, consider if gummiboot were modified to support booting from other partitions. The six Freedesktop rules could be cut by two (removing #4 and #6) and slightly amended (to make $BOOT always be a Freedesktop partition and never an ESP, and to permit multiple Freedesktop partitions per disk should the need arise). This will eliminate the problem I've just identified and simplify the rules that OS installers or administrators should follow, thus reducing the odds of bugs or different interpretations causing problems. Yes, it means that the Freedesktop developers will need to add some code to their boot loader. OTOH, this also means there will be:
Less ambiguity about what /boot is (the ESP vs. the Freedesktop boot partition) on any given system; this will lead to simpler code in support scripts and less chance of user error because of confusion or help from others based on false assumptions
Less chance of another OS altering or damaging the Linux boot loader files, thus improving overall system reliability
Less chance of creating a configuration in which gummiboot is incapable of booting some OSes that are legally installed
A need for fewer rules in the proposal, thereby reducing the odds of differing interpretations causing compatibility problems
Overall, I'd say these benefits are worth a few extra lines of code.