Re: Does the installer detects when a distro have already created BLS?
First I'd like to thanks people that made me realize I was confusing the GPT's partition type GUID and GPT's Unique partition GUID. And to also mention the filesystem UID. Because Fedora choose not to apply the BLS partition type GUID or BLS MBR type id, I believe we generate the following consequences: When installing a Fedora version beside an other Fedora version, we create a new /boot, and so I believe we cannot boot the old version anymore... I might be wrong on this one. When a BLS compliant distribution is installed, and we install Fedora, we create a new /boot, and so we cannot boot anymore the old compliant BLS distribution. When Fedora is installed, and a BLS compliant distribution is then installed, it choose to mount our ESP (Efi System Partition) as /boot because our ESP is big enough, but by doing so, it loose Fedora boot entries, and so the new OS boot, but Fedora is not shown anymore and cannot be booted. Also, because we choose to use an EXT4 filesystem by default for /boot, it means that a BLS compliant implementation, might be unable to read either our boot entries, or the kernel file and initrd files. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
On 24/05/2020 19:56, Paul Dufresne via devel wrote: > "These directories are defined below the placeholder file system $BOOT. This > placeholder file system shall be determined during installation time, and an > fstab entry for it shall be created mounting it to /boot. The installer > program should pick $BOOT according to the following rules: > > If the OS is installed on a disk with MBR disk label, and a partition > with the MBR type id of 0xEA already exists it should be used as $BOOT. > Otherwise, if the the OS is installed on a disk with MBR disk label, a > new partition with MBR type id of 0xEA shall be created, of a suitable size > (let's say 500MB), and it should be used as $BOOT. > If the OS is installed on a disk with GPT disk label, and a partition > with the GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 already > exists, it should be used as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and an > ESP partition (i.e. with the GPT type UID of > c12a7328-f81f-11d2-ba4b-00a0c93ec93b) already exists and is large enough > (let's say 250MB) and otherwise qualifies, it should be used as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and if > the ESP partition already exists but is too small, a new suitably sized > (let's say 500MB) partition with GPT type GUID of > bc13c2ff-59e6-4262-a352-b275fd6f7172 shall be created and it should be used > as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and no > ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should > be created and should be used as $BOOT. > > " > One of the first problem I have, is /boot have not the correct GUID for > BLS: > > [paul@localhost /]$ cat /etc/fstab > > # > # /etc/fstab > # Created by anaconda on Sun May 24 11:48:45 2020 > # > # Accessible filesystems, by reference, are maintained under '/dev/disk/'. > # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more > info. > # > # After editing this file, run 'systemctl daemon-reload' to update systemd > # units generated from this file. > # > /dev/mapper/myLVM-fedoraMain / ext4 defaults 1 1 > UUID=4a82a496-5316-4aca-9d27-8376197c8a6d /boot ext4 defaults 1 2 > UUID=62BD-AFFC /boot/efi vfat umask=0077,shortname=winnt 0 2 > /dev/mapper/myLVM-fedoraSwap none swap defaults 0 0 > [paul@localhost /]$ > > Reading the BLS, it seems the installer did not generated a valid entry > /boot... not the valid type (vfat, EFS)... nor a valid UUID. > > Oh well, the other way of saying it is the installer did not force me to > generate a valid /boot partition. > > I have: > > [paul@localhost /]$ sudo parted /dev/sda -- print > [sudo] Mot de passe de paul : > Modèle : ATA ST500LM021-1KJ15 (scsi) > Disque /dev/sda : 500GB > Taille des secteurs (logiques/physiques) : 512B/4096B > Table de partitions : gpt > Drapeaux de disque : > > Numéro Début Fin Taille Système de fichiers Nom > Drapeaux > 1 1049kB 268MB 267MB ext4 > 2 269MB 479MB 210MB fat16 > démarrage, esp > 3 479MB 701MB 222MB fat16 EFI System > Partition démarrage, esp > 4 701MB 194GB 193GB > lvm Aside from the other stuff people have explained elsewhere, you're conflating two different UUIDs/GUIDs here. The partition *type* UUID is what's specified in the BLS etc., and everybody's EFI partition will have the same partition type UUID, everybody's /boot partition (if present) should have the same UUID, etc. It's what's translated by parted and the like into 'ext4', 'fat16', etc., rather than displaying the 36 character or so string. But the just-*partition* UUID is for identifying that particular partition, to distinguish it from any other, and no two should ever be the same (this has bitten me a few times when cloning disks). And on top of that, there's often also a filesystem UUID, which should also never be the same (and has also bitten me a few times when dd'ing partition images). Either of the latter two can be used in fstab to identify that particular partition, I believe much more commonly the filesystem UUID, and that's what you see in your fstab there, rather than the partition type UUID. So there's nothing to worry about with it not looking anything like the BLS partition type UUIDs. (Apologies if the formatting goes pear-shaped, I tried tidying up the quotes a bit.) -- J. Randall Owens | http://www.GhiaPet.net/ signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines:
Re: Does the installer detects when a distro have already created BLS?
On Mon, May 25, 2020 at 4:00 AM Chris Murphy wrote: > On Sun, May 24, 2020 at 7:48 PM James Cassell > wrote: > > On Sun, May 24, 2020, at 9:39 PM, Chris Murphy wrote: > > > On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel > > > wrote: > > > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : [snip] > > > But an additional difficulty to fully implementing the spec is so far > > > upstream GRUB don't want to follow it. So that means Fedora has to > > > carry patches for GRUB to support it. And it's just yet another of > > > 100+ patches Fedora carries for GRUB, and makes it difficult for the > > > Fedora and RH boot teams. The resources so far implement some of the > > > parts of BLS that help make things better on Fedora, but it's not a > > > complete implementation. Drop-in snippets to add new kernels is crash > > > safe, worst case the previous kernel is booted and you just reinstall > > > the kernel; but writing out a new grub.cfg or modifying it, wasn't > > > ever crash safe. Also, modifying the snippets is easier, they're just > > > a few lines and fairly self-describing compared to what users often > > > did, which was wade neck deep into editing grub.cfg. Or the Rube > > > Goldberg machine that is editing /etc/default/grub, running a script > > > (grub-mkconfig), which then runs 20 other scripts to create a > > > configuration file that is actually a script. Yes, what was implemented in GRUB and also the other bootloaders used in Fedora (Petiboot and zipl) was support to parse BLS snippets. The goal was to have a consistent bootloader configuration scheme and file format across all the different architectures and bootloaders supported by Fedora. This allowed to simplify and improve the bootloader configuration tooling for the reasons Chris already mentioned. We could get rid of the old grubby tool that was used before to parse and modify the bootloader specific configuration files, which was quite fragile since users also changed these files breaking the assumptions made by grubby. Using BLS snippets for all Fedora variants also aligned better with OSTree based ones, that were already using BLS snippets for the boot entries. > > > > Even so, isn't the canonical way of persistently updating kernel args, > > still, to edit /etc/default/grub and run the script? (If not, are there > > docs for the new way?) > > It does still work, but by indirection. You set it in > /etc/default/grub but grub2-mkconfig puts it into grub.cfg first and > then it goes into grubenv. The grubenv variables are loaded by GRUB at > boot time, and the BLS snippets reference those variables. > This still works from F33 onwards. But instead of grub2-mkconfig updating a variable in grubenv, the options field of the BLS snippets are updated with the kernel cmdline set in /etc/default/grub. This is done for backward compatibility because as mentioned in this thread, is the canonical form to update the kernel cmdline and documented everywhere. > I've resorted to using 'grub2-editenv' to directly modify grubenv. But > as grubenv is fragile, using it will be abandoned. > There's a grubby script that is provided for backward compatibility, that just modifies the BLS snippets. So this can also be used to update the kernel cmdline. I agree that we need better tools for users to manage the BLS snippets and also improve the documentation. Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020 at 7:48 PM James Cassell wrote: > > > On Sun, May 24, 2020, at 9:39 PM, Chris Murphy wrote: > > On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel > > wrote: > > > > > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : > > > > The change record for this states that we are not following the BLS at > > > > https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but > > > > the proposed update at > > > > https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . > > > > > > Thanks for remembering me this alternative specification! > > > > > > That said, Fedora does not seems to follow this alternative spec, > > > because we use: > > > > > > $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as > > > indicated in this standard. > > > > > > The point is that as the $BOOT is shared among distributions, there must > > > be a way to detect if it is already there, to be able to re-use it. For > > > that, the specification (whatever the exact version if chosen) must be > > > relatively well followed. > > > > Yep. > > > > But an additional difficulty to fully implementing the spec is so far > > upstream GRUB don't want to follow it. So that means Fedora has to > > carry patches for GRUB to support it. And it's just yet another of > > 100+ patches Fedora carries for GRUB, and makes it difficult for the > > Fedora and RH boot teams. The resources so far implement some of the > > parts of BLS that help make things better on Fedora, but it's not a > > complete implementation. Drop-in snippets to add new kernels is crash > > safe, worst case the previous kernel is booted and you just reinstall > > the kernel; but writing out a new grub.cfg or modifying it, wasn't > > ever crash safe. Also, modifying the snippets is easier, they're just > > a few lines and fairly self-describing compared to what users often > > did, which was wade neck deep into editing grub.cfg. Or the Rube > > Goldberg machine that is editing /etc/default/grub, running a script > > (grub-mkconfig), which then runs 20 other scripts to create a > > configuration file that is actually a script. > > > > Even so, isn't the canonical way of persistently updating kernel args, still, > to edit /etc/default/grub and run the script? (If not, are there docs for the > new way?) It does still work, but by indirection. You set it in /etc/default/grub but grub2-mkconfig puts it into grub.cfg first and then it goes into grubenv. The grubenv variables are loaded by GRUB at boot time, and the BLS snippets reference those variables. I've resorted to using 'grub2-editenv' to directly modify grubenv. But as grubenv is fragile, using it will be abandoned. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020, at 9:39 PM, Chris Murphy wrote: > On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel > wrote: > > > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : > > > The change record for this states that we are not following the BLS at > > > https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but > > > the proposed update at > > > https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . > > > > Thanks for remembering me this alternative specification! > > > > That said, Fedora does not seems to follow this alternative spec, > > because we use: > > > > $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as > > indicated in this standard. > > > > The point is that as the $BOOT is shared among distributions, there must > > be a way to detect if it is already there, to be able to re-use it. For > > that, the specification (whatever the exact version if chosen) must be > > relatively well followed. > > Yep. > > But an additional difficulty to fully implementing the spec is so far > upstream GRUB don't want to follow it. So that means Fedora has to > carry patches for GRUB to support it. And it's just yet another of > 100+ patches Fedora carries for GRUB, and makes it difficult for the > Fedora and RH boot teams. The resources so far implement some of the > parts of BLS that help make things better on Fedora, but it's not a > complete implementation. Drop-in snippets to add new kernels is crash > safe, worst case the previous kernel is booted and you just reinstall > the kernel; but writing out a new grub.cfg or modifying it, wasn't > ever crash safe. Also, modifying the snippets is easier, they're just > a few lines and fairly self-describing compared to what users often > did, which was wade neck deep into editing grub.cfg. Or the Rube > Goldberg machine that is editing /etc/default/grub, running a script > (grub-mkconfig), which then runs 20 other scripts to create a > configuration file that is actually a script. > Even so, isn't the canonical way of persistently updating kernel args, still, to edit /etc/default/grub and run the script? (If not, are there docs for the new way?) V/r, James Cassell ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020 at 6:42 PM Paul Dufresne via devel wrote: > > Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : > > The change record for this states that we are not following the BLS at > > https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but > > the proposed update at > > https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . > > Thanks for remembering me this alternative specification! > > That said, Fedora does not seems to follow this alternative spec, > because we use: > > $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as > indicated in this standard. > > The point is that as the $BOOT is shared among distributions, there must > be a way to detect if it is already there, to be able to re-use it. For > that, the specification (whatever the exact version if chosen) must be > relatively well followed. Yep. But an additional difficulty to fully implementing the spec is so far upstream GRUB don't want to follow it. So that means Fedora has to carry patches for GRUB to support it. And it's just yet another of 100+ patches Fedora carries for GRUB, and makes it difficult for the Fedora and RH boot teams. The resources so far implement some of the parts of BLS that help make things better on Fedora, but it's not a complete implementation. Drop-in snippets to add new kernels is crash safe, worst case the previous kernel is booted and you just reinstall the kernel; but writing out a new grub.cfg or modifying it, wasn't ever crash safe. Also, modifying the snippets is easier, they're just a few lines and fairly self-describing compared to what users often did, which was wade neck deep into editing grub.cfg. Or the Rube Goldberg machine that is editing /etc/default/grub, running a script (grub-mkconfig), which then runs 20 other scripts to create a configuration file that is actually a script. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020 at 5:07 PM Paul Dufresne via devel wrote: > > Well... I will try to repeat more clearly my claim: > > If Fedora want to pretend to implement the Boot Loader Specification, it > must, on a new disk formatted in GPT, end up with an entry in fstab for an > ESP partition mounted on /boot: > > "These directories are defined below the placeholder file system $BOOT. This > placeholder file system shall be determined during installation time, and an > fstab entry for it shall be created mounting it to /boot." In practice, Fedora's implementation is closer in some respects to this variant of the spec: https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ > "if the OS is installed on a disk with GPT disk label, and no ESP partition > exists yet, a new suitably sized (let's say 500MB) ESP should be created and > should be used as $BOOT" > > This is the rule you are supposed end up to follow for an empty GPT partition. > > And for now, the installer seems to make you define a specific /boot/efi that > it make ESP. To follow BLS, it should be /boot that is the ESP partition... > and I see no point to define an other /boot/efi partition to be mounted on > /boot. Correct. Fedora went with a hybrid approach, rather than fully conforming to (either) spec. So in practice, it's an implementation without a spec. But that happens with web standards and various other specs too so it's not remarkable in that sense, even if it's confusing. > "$BOOT must be a VFAT (16 or 32) file system. Other file system types should > not be used. Applications accessing $BOOT should hence not assume that > fancier file system features such as symlinks, hardlinks, access control or > case sensitivity are supported." Yeah it's difficult to cover all possible use cases this way, and the spec itself doesn't try to cover them. One of those that is still worse on UEFI, is the inability to support redundant boot with two drives. There needs to be some service or daemon that syncs the EFI System partitions on each drive, and software raid inadequately addresses the concerns, and creates new ones and for that md/mdadm upstream folks have consistently opposed such implementations and yet they exist and are as fragile as expected. Another problem is FAT isn't atomic so while it's possible to do rename atomically at the VFS level, it's not atomic on FAT so if you need such a guarantee when modifying the ESP, FAT leaves the door open (however small) to boot failure following a crash during an update of the ESP. I'm not sure how Windows solves this, or even if it does. Apple solves it by not not using the ESP for booting at all, they use an EFI file system driver so that the pre-boot environment can read APFS, and as that's a COW file system, all kernel and boot related updates happen atomically by design. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020 at 11:21 AM Paul Dufresne via devel wrote: > > Well... it take time to me to get used to the Boot Loader Specification. > > I am being lazy here... asking people on the mailing list rather than trying > to determine it myself. > > After making an installation of Fedora, I begin to think: > > Hey, I don't remember having seen the installer like detecting the use of a > previously installed /boot and/or /boot/efi partition, and tells me that it > will automatically use it by default. Fedora isn't following the Boot Loader Spec exactly in all ways. The installer doesn't support BLS with respect to $BOOT type codes: either EFI System partition or the Extended Boot partition. > But since with Boot Loader Specification, these are supposed to be shared > among distribution (maybe more likely a recent Fedora version with an older > Fedora version), it make sense that it should happens. Maybe I did not seen > it because I tend to erase the disk and begin from scratch. You didn't miss it. Fedora hasn't committed to it fully. What it's mostly committed to are the BLS snippets, those are the individual drop-in files that describe a boot entry to be displayed by GRUB. There is also currently the use of variables stored in grubenv, referenced by the BLS snippets, which isn't in the actual spec. That's going away in F33, such that the BLS snippets completely describe the boot entry details, i.e. are self-contained. > "These directories are defined below the placeholder file system $BOOT. This > placeholder file system shall be determined during installation time, and an > fstab entry for it shall be created mounting it to /boot. The installer > program should pick $BOOT according to the following rules: > > If the OS is installed on a disk with MBR disk label, and a partition with > the MBR type id of 0xEA already exists it should be used as $BOOT. > Otherwise, if the the OS is installed on a disk with MBR disk label, a new > partition with MBR type id of 0xEA shall be created, of a suitable size > (let's say 500MB), and it should be used as $BOOT. > If the OS is installed on a disk with GPT disk label, and a partition with > the GPT type GUID of bc13c2ff-59e6-4262-a352-b275fd6f7172 already exists, it > should be used as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and an ESP > partition (i.e. with the GPT type UID of > c12a7328-f81f-11d2-ba4b-00a0c93ec93b) already exists and is large enough > (let's say 250MB) and otherwise qualifies, it should be used as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and if the > ESP partition already exists but is too small, a new suitably sized (let's > say 500MB) partition with GPT type GUID of > bc13c2ff-59e6-4262-a352-b275fd6f7172 shall be created and it should be used > as $BOOT. > Otherwise, if the OS is installed on a disk with GPT disk label, and no ESP > partition exists yet, a new suitably sized (let's say 500MB) ESP should be > created and should be used as $BOOT. > > " > > So the question is basically, does the installer make the check for > preexisting $BOOT ? No. It also does not set any of those type codes such that they could be identified subsequently. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
Le 20-05-24 à 19 h 34, Naheem Zaffar a écrit : The change record for this states that we are not following the BLS at https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but the proposed update at https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . Thanks for remembering me this alternative specification! That said, Fedora does not seems to follow this alternative spec, because we use: $BOOT/loader directory, and not $BOOT/org/freedesktop/bls directory as indicated in this standard. The point is that as the $BOOT is shared among distributions, there must be a way to detect if it is already there, to be able to re-use it. For that, the specification (whatever the exact version if chosen) must be relatively well followed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
The change record for this states that we are not following the BLS at https://www.freedesktop.org/wiki/Specifications/BootLoaderSpec/ but the proposed update at https://www.freedesktop.org/wiki/MatthewGarrett/BootLoaderSpec/ . It is not clear however if everyone has moved to the new spec or whether they are now competing specs. On Mon, 25 May 2020 at 00:27, James Cassell wrote: > > On Sun, May 24, 2020, at 7:06 PM, Paul Dufresne via devel wrote: > > Well... I will try to repeat more clearly my claim: > > > > If Fedora want to pretend to implement the Boot Loader Specification, > > it must, on a new disk formatted in GPT, end up with an entry in fstab > > for an ESP partition mounted on /boot: > > > > "These directories are defined below the placeholder file system $BOOT. > > This placeholder file system shall be determined during installation > > time, and an fstab entry for it shall be created mounting it to /boot." > > > > ... > > > > "if the OS is installed on a disk with GPT disk label, and no ESP > > partition exists yet, a new suitably sized (let's say 500MB) ESP should > > be created and should be used as $BOOT" > > > > This is the rule you are supposed end up to follow for an empty GPT > partition. > > > > And for now, the installer seems to make you define a specific > > /boot/efi that it make ESP. To follow BLS, it should be /boot that is > > the ESP partition... and I see no point to define an other /boot/efi > > partition to be mounted on /boot. > > > > I agree with your assessment and am also confused about the discrepancy > between BLS documentation and Fedora's implementation. > > > V/r, > James Cassell > > > ... > > > > "`$BOOT` must be a VFAT (16 or 32) file system. Other file system types > > should not be used. Applications accessing `$BOOT` should hence not > > assume that fancier file system features such as symlinks, hardlinks, > > access control or case sensitivity are supported." > > > > > > > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
On Sun, May 24, 2020, at 7:06 PM, Paul Dufresne via devel wrote: > Well... I will try to repeat more clearly my claim: > > If Fedora want to pretend to implement the Boot Loader Specification, > it must, on a new disk formatted in GPT, end up with an entry in fstab > for an ESP partition mounted on /boot: > > "These directories are defined below the placeholder file system $BOOT. > This placeholder file system shall be determined during installation > time, and an fstab entry for it shall be created mounting it to /boot." > > ... > > "if the OS is installed on a disk with GPT disk label, and no ESP > partition exists yet, a new suitably sized (let's say 500MB) ESP should > be created and should be used as $BOOT" > > This is the rule you are supposed end up to follow for an empty GPT partition. > > And for now, the installer seems to make you define a specific > /boot/efi that it make ESP. To follow BLS, it should be /boot that is > the ESP partition... and I see no point to define an other /boot/efi > partition to be mounted on /boot. > I agree with your assessment and am also confused about the discrepancy between BLS documentation and Fedora's implementation. V/r, James Cassell > ... > > "`$BOOT` must be a VFAT (16 or 32) file system. Other file system types > should not be used. Applications accessing `$BOOT` should hence not > assume that fancier file system features such as symlinks, hardlinks, > access control or case sensitivity are supported." > > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
Well... I will try to repeat more clearly my claim: If Fedora want to pretend to implement the Boot Loader Specification, it must, on a new disk formatted in GPT, end up with an entry in fstab for an ESP partition mounted on /boot: "These directories are defined below the placeholder file system $BOOT. This placeholder file system shall be determined during installation time, and an fstab entry for it shall be created mounting it to /boot." ... "if the OS is installed on a disk with GPT disk label, and no ESP partition exists yet, a new suitably sized (let's say 500MB) ESP should be created and should be used as $BOOT" This is the rule you are supposed end up to follow for an empty GPT partition. And for now, the installer seems to make you define a specific /boot/efi that it make ESP. To follow BLS, it should be /boot that is the ESP partition... and I see no point to define an other /boot/efi partition to be mounted on /boot. ... "|$BOOT| must be a VFAT (16 or 32) file system. Other file system types should not be used. Applications accessing |$BOOT| should hence not assume that fancier file system features such as symlinks, hardlinks, access control or case sensitivity are supported." ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
On Sun, 24 May 2020 14:56:34 -0400 Paul Dufresne via devel wrote: > I have installed the May 22 Rawhide on a disk today, and I am now > realizing that the installer did not helped me enough to create valid > Boot Loader Specification partitions. > > So I wanted (still want) to make this disk dual boot (Fedora and > NixOS). > > Because NixOS does not follows BLS (I think... thought... I should > verify)... well I decided to create two boot partitions, one for the > Fedora BLS partition, and an other for NixOS. Good thought. Does NixOS allow the use of uefi? If it doesn't, it will definitely need a separate partition for /boot. > And my idea was to create a big LVM(2) partition for more normal > partition: / and Swap... which I did. > > I have chosen ext4 for my Fedora /boot, which is illegal according to > BLS: "$BOOT must be a VFAT (16 or 32) file system.". I think $BOOT will be /boot/efi, and that is required to be vfat. /boot does *not* have to be vfat. > The installer, then forced my hand to add a /boot/efi partition, > which I had not tought previously to add. > > So I removed my LVM(2) partiton, add the /boot/efi partition, then > added back my LVM(2) partition. > > It finally installed... > > One of the first problem I have, is /boot have not the correct GUID > for BLS: > > [paul@localhost /]$ cat /etc/fstab > > # > # /etc/fstab > # Created by anaconda on Sun May 24 11:48:45 2020 > # > # Accessible filesystems, by reference, are maintained under > '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or > blkid(8) for more info. # > # After editing this file, run 'systemctl daemon-reload' to update > systemd # units generated from this file. > # > /dev/mapper/myLVM-fedoraMain / ext4 > defaults 1 1 > UUID=4a82a496-5316-4aca-9d27-8376197c8a6d /boot ext4 defaults > 1 2 UUID=62BD-AFFC /boot/efi vfat > umask=0077,shortname=winnt 0 2 > /dev/mapper/myLVM-fedoraSwap none swap > defaults 0 0 > [paul@localhost /]$ > > Reading the BLS, it seems the installer did not generated a valid > entry /boot... not the valid type (vfat, EFS)... nor a valid UUID. > > Oh well, the other way of saying it is the installer did not force me > to generate a valid /boot partition. Because it is under / in the lvm. /boot does not have to be vfat, it is /boot/efi that has to be vfat. If you want a separate /boot for the / in the lvm you will have to create a separate partition for it during install (custom), but it is *not* required, thus why you did not get a prompt. > I have: > > [paul@localhost /]$ sudo parted /dev/sda -- print > [sudo] Mot de passe de paul : > Modèle : ATA ST500LM021-1KJ15 (scsi) > Disque /dev/sda : 500GB > Taille des secteurs (logiques/physiques) : 512B/4096B > Table de partitions : gpt > Drapeaux de disque : > > Numéro Début Fin Taille Système de fichiers Nom > Drapeaux > 1 1049kB 268MB 267MB ext4 > 2 269MB 479MB 210MB fat16 > démarrage, esp > 3 479MB 701MB 222MB fat16 EFI System > Partition démarrage, esp > 4 701MB 194GB > 193GB lvm > > [paul@localhost /]$ lsblk > NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT > sda 8:0 0 465,8G 0 disk > ├─sda1 8:1 0 255M 0 part /boot > ├─sda2 8:2 0 200M 0 part > ├─sda3 8:3 0 212M 0 part /boot/efi > └─sda4 8:4 0 180G 0 part > ├─myLVM-fedoraMain 253:0 0 80G 0 lvm / > └─myLVM-fedoraSwap 253:1 0 9G 0 lvm [SWAP] > sr0 11:0 1 6,6G 0 rom > /run/media/paul/090130_0113 [paul@localhost /]$ Fedora can't run without a / partition, usually defaults to ext4, but many other fs types available /boot, ext? usually, but I *think* can be *some* other types. Can be under /, then no separate /boot needed. /boot under the / partition the default now. Is there not a /boot under the / in the lvm partition after install? Are there not entries in /boot/loader/entries/ of the /boot in the lvm partition? /boot/efi required to be vfat by the uefi standard Is there no /boot/efi/EFI/fedora directory with entries corresponding to the lvm partition? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
Re: Does the installer detects when a distro have already created BLS?
I have installed the May 22 Rawhide on a disk today, and I am now realizing that the installer did not helped me enough to create valid Boot Loader Specification partitions. So I wanted (still want) to make this disk dual boot (Fedora and NixOS). Because NixOS does not follows BLS (I think... thought... I should verify)... well I decided to create two boot partitions, one for the Fedora BLS partition, and an other for NixOS. And my idea was to create a big LVM(2) partition for more normal partition: / and Swap... which I did. I have chosen ext4 for my Fedora /boot, which is illegal according to BLS: "$BOOT must be a VFAT (16 or 32) file system.". The installer, then forced my hand to add a /boot/efi partition, which I had not tought previously to add. So I removed my LVM(2) partiton, add the /boot/efi partition, then added back my LVM(2) partition. It finally installed... One of the first problem I have, is /boot have not the correct GUID for BLS: [paul@localhost /]$ cat /etc/fstab # # /etc/fstab # Created by anaconda on Sun May 24 11:48:45 2020 # # Accessible filesystems, by reference, are maintained under '/dev/disk/'. # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info. # # After editing this file, run 'systemctl daemon-reload' to update systemd # units generated from this file. # /dev/mapper/myLVM-fedoraMain / ext4 defaults 1 1 UUID=4a82a496-5316-4aca-9d27-8376197c8a6d /boot ext4 defaults 1 2 UUID=62BD-AFFC /boot/efi vfat umask=0077,shortname=winnt 0 2 /dev/mapper/myLVM-fedoraSwap none swap defaults 0 0 [paul@localhost /]$ Reading the BLS, it seems the installer did not generated a valid entry /boot... not the valid type (vfat, EFS)... nor a valid UUID. Oh well, the other way of saying it is the installer did not force me to generate a valid /boot partition. I have: [paul@localhost /]$ sudo parted /dev/sda -- print [sudo] Mot de passe de paul : Modèle : ATA ST500LM021-1KJ15 (scsi) Disque /dev/sda : 500GB Taille des secteurs (logiques/physiques) : 512B/4096B Table de partitions : gpt Drapeaux de disque : Numéro Début Fin Taille Système de fichiers Nom Drapeaux 1 1049kB 268MB 267MB ext4 2 269MB 479MB 210MB fat16 démarrage, esp 3 479MB 701MB 222MB fat16 EFI System Partition démarrage, esp 4 701MB 194GB 193GB lvm [paul@localhost /]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465,8G 0 disk ├─sda1 8:1 0 255M 0 part /boot ├─sda2 8:2 0 200M 0 part ├─sda3 8:3 0 212M 0 part /boot/efi └─sda4 8:4 0 180G 0 part ├─myLVM-fedoraMain 253:0 0 80G 0 lvm / └─myLVM-fedoraSwap 253:1 0 9G 0 lvm [SWAP] sr0 11:0 1 6,6G 0 rom /run/media/paul/090130_0113 [paul@localhost /]$ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
