Re: Grub 2 protected packages
On Mon, Apr 12, 2021 at 11:51 PM Chris Murphy wrote: > > On Mon, Apr 12, 2021 at 4:01 AM Neal Gompa wrote: > > > > Ideally, we should change to a system similar to what openSUSE does > > and have the RPMs install bootloader content into /usr, then execute a > > helper program that copies things over to /boot and configures things > > properly (we should still have the files %ghosted in /boot, though!). > > This makes it much more straightforward to support updating or > > downgrading bootloader files when needed, which is why openSUSE does > > it this way to support full system snapshots with rollback > > functionality. > > That's the intent of bootupd. > https://github.com/coreos/bootupd/ > > And also include 'grub2-install' on BIOS systems to ensure the > embedded instance is also kept up to date. And a possible future > feature is EFI system partition syncing in the case of multiple ESPs. Agreed that packages shouldn't install anything in /boot or update the bootloader images (e.g: the embedding gap for x86 legacy BIOS, PReP partition for ppc64le, etc) and instead all that setup logic should be done by bootupd. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Mon, Apr 12, 2021 at 4:01 AM Neal Gompa wrote: > > Ideally, we should change to a system similar to what openSUSE does > and have the RPMs install bootloader content into /usr, then execute a > helper program that copies things over to /boot and configures things > properly (we should still have the files %ghosted in /boot, though!). > This makes it much more straightforward to support updating or > downgrading bootloader files when needed, which is why openSUSE does > it this way to support full system snapshots with rollback > functionality. That's the intent of bootupd. https://github.com/coreos/bootupd/ And also include 'grub2-install' on BIOS systems to ensure the embedded instance is also kept up to date. And a possible future feature is EFI system partition syncing in the case of multiple ESPs. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Mo, 12.04.21 11:22, Colin Walters (walt...@verbum.org) wrote: > But, trying to change the traditional RPM path seems quite tricky to > do safely without having a window where the grub binaries are > deleted from `/boot` e.g. Wouldn't it suffice to just start marking the files as %ghost in an RPM package update? I'd assume tht RPM would then leave the files that are already in place in place, no? > And we've conditioned people to the idea that `yum update` will also > update grub for EFI systems. Well, the RPM scriptlets of grub could should the equivalent of "bootctl update" of course. Lennart -- Lennart Poettering, Berlin ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Mon, Apr 12, 2021, at 10:52 AM, Lennart Poettering wrote: > O > (Of course, sd-boot works this way: the RPM packages drop EFI binaries > into /usr/, and "bootctl install" and "bootctl update" will copy them > into the boot loader partitions, carefully and defensively in order > not to corrupt what else might be there.) Yep, rpm-ostree and bootupd (https://github.com/coreos/bootupd/) that are used by Fedora CoreOS are similar. But, trying to change the traditional RPM path seems quite tricky to do safely without having a window where the grub binaries are deleted from `/boot` e.g. And we've conditioned people to the idea that `yum update` will also update grub for EFI systems. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Mo, 12.04.21 06:00, Neal Gompa (ngomp...@gmail.com) wrote: > > In fact, the presence of a bunch of other files in /boot in > > grub2-efi-x64 seems like a bad idea. IMO, just installing the grub2 > > packages should either not modify /boot (which is not the exclusive > > property of grub2 and often has limited space), or if this cannot > > be done, grub2 needs to make sure that the grub2 packages are not > > a dependency of anything and can only be installed with an explicit > > user request. > > Ideally, we should change to a system similar to what openSUSE does > and have the RPMs install bootloader content into /usr, then execute a > helper program that copies things over to /boot and configures things > properly (we should still have the files %ghosted in /boot, though!). > This makes it much more straightforward to support updating or > downgrading bootloader files when needed, which is why openSUSE does > it this way to support full system snapshots with rollback > functionality. I vehemently agree with this. The ESP and other boot loader partitions should really be considered common good and not really "owned" by RPM or other packaging tools the way stuff in /usr/ is owned by them. Multiple OSes and Linux distributions might want to drop stuff in these partitions (under common names even, consider the main EFI entrypoint after all), and hence the update semantics need to be a bit more cooperative, to avoid everyone steps on each other toes all the time. Hence: use RPM to update boot loaders binaries in /usr, and use a separate tool to copy things over to the ESP and other boot partitions when appropriate. (Of course, sd-boot works this way: the RPM packages drop EFI binaries into /usr/, and "bootctl install" and "bootctl update" will copy them into the boot loader partitions, carefully and defensively in order not to corrupt what else might be there.) Lennart -- Lennart Poettering, Berlin ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On So, 11.04.21 03:53, Robert Scheck (rob...@fedoraproject.org) wrote: > My intention of packaging efifs for Fedora was to get systemd-boot handling > my ext4 XBOOTLDR (https://github.com/systemd/systemd/issues/17756), which > still is not working, because of the two issues mentioned there (and less > systemd-boot upstream interest as it seems). I would be delighted to merge a patch to sd-boot that works around this issue. None has been submitted so far, and in my personal use this issue hasn't shown up yet, so I didn't really put the effor in myself yet. I'd also be delighted to merge a patch for sd-boot that auto-loads all drivers in some drop-in directory in the ESP before searching for boot menu items, so that there's a nice way to load other file system drivers. I'll look into both these issues eventually if noone else does, but it's not the top prio for me I have to say. A submitted, clean PR would speed things up a lot. Lennart -- Lennart Poettering, Berlin ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 4/12/21 3:51 AM, Javier Martinez Canillas wrote: I dropped it by mistake when rebasing to 2.06, sorry about that. I've fixed it now in F33, F34 and Rawhide. i see rawhide has 'stable' already; and that F33/F34 are 'pending->testing'. thx! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Mon, Apr 12, 2021 at 5:43 AM Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Apr 10, 2021 at 09:04:09PM -, Filippe LeMarchand wrote: > > > This shouldn't be the case. Unless there's a bug, grub2 may be > > > installed an unused. If it interferes with sd-boot, please file > > > a bug. > > > > The grub2-efi-x64 package contains directory > > /boot/loader/entries. AFAICT this directory presence alone makes > > kernel-install script install the boot files there instead of > > /boot/efi/loader (which is needed for sd-boot). Should this be > > considered a grub2 bug? > > It's not only a grub2 bug, it's also a straightforward recreation of a > bug that was already fixed once with a lot of pain [1]. > > At the time a solution was hashed out that depends on the presence of > certain directories [2]. The idea was that bootctl would create > /boot/efi/loader/entries only when 'bootctl install' is called [3]. > And the appropriate grub2 equivalents would do that same when grub2 is > installed to EFI. And generally, it should be fine for both sets of > rpms (and even other boot loaders!) to be installed into the system, > so that systems don't stop booting again when the grub2 rpms are > pulled in through a dependency. > > This is fragile, and is certainly not an ideal solution, but we didn't > have a better solution that would work for existing systems without an > explicit user intervention. But now grub2 embeds /boot/loader/entries > directly in grub2-efi-x64.rpm, breaking things. > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1648907 > [2] https://github.com/systemd/systemd/commit/cf73f65089 > [3] https://github.com/systemd/systemd/commit/341890de86 > > In fact, the presence of a bunch of other files in /boot in > grub2-efi-x64 seems like a bad idea. IMO, just installing the grub2 > packages should either not modify /boot (which is not the exclusive > property of grub2 and often has limited space), or if this cannot > be done, grub2 needs to make sure that the grub2 packages are not > a dependency of anything and can only be installed with an explicit > user request. > Ideally, we should change to a system similar to what openSUSE does and have the RPMs install bootloader content into /usr, then execute a helper program that copies things over to /boot and configures things properly (we should still have the files %ghosted in /boot, though!). This makes it much more straightforward to support updating or downgrading bootloader files when needed, which is why openSUSE does it this way to support full system snapshots with rollback functionality. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 09:04:09PM -, Filippe LeMarchand wrote: > > This shouldn't be the case. Unless there's a bug, grub2 may be > > installed an unused. If it interferes with sd-boot, please file > > a bug. > > The grub2-efi-x64 package contains directory > /boot/loader/entries. AFAICT this directory presence alone makes > kernel-install script install the boot files there instead of > /boot/efi/loader (which is needed for sd-boot). Should this be > considered a grub2 bug? It's not only a grub2 bug, it's also a straightforward recreation of a bug that was already fixed once with a lot of pain [1]. At the time a solution was hashed out that depends on the presence of certain directories [2]. The idea was that bootctl would create /boot/efi/loader/entries only when 'bootctl install' is called [3]. And the appropriate grub2 equivalents would do that same when grub2 is installed to EFI. And generally, it should be fine for both sets of rpms (and even other boot loaders!) to be installed into the system, so that systems don't stop booting again when the grub2 rpms are pulled in through a dependency. This is fragile, and is certainly not an ideal solution, but we didn't have a better solution that would work for existing systems without an explicit user intervention. But now grub2 embeds /boot/loader/entries directly in grub2-efi-x64.rpm, breaking things. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1648907 [2] https://github.com/systemd/systemd/commit/cf73f65089 [3] https://github.com/systemd/systemd/commit/341890de86 In fact, the presence of a bunch of other files in /boot in grub2-efi-x64 seems like a bad idea. IMO, just installing the grub2 packages should either not modify /boot (which is not the exclusive property of grub2 and often has limited space), or if this cannot be done, grub2 needs to make sure that the grub2 packages are not a dependency of anything and can only be installed with an explicit user request. Zbyszek ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sun, Apr 11, 2021 at 2:29 PM PGNet Dev wrote: > > > Ordinarily, no. But in this case, since GRUB 2.06~rc1 is required to > > solve major critical vulnerabilities and it's very difficult to pull > > the patch set that fixes it (>115 patches!) backwards, GRUB got moved > > forward instead. > > > > GRUB 2.06~rc1 was pretty much released to release the patch set... > > got it. > As Neal said, the other option was to backport all the CVE fixes and SBAT support patches which was a riskier option. Also, we are trying to get rid of the huge patch-set that the Fedora package is currently carrying, not adding more to the set. > then will stick with v2.06, and try to get it re-patched for Xen @ the bug. > I dropped it by mistake when rebasing to 2.06, sorry about that. I've fixed it now in F33, F34 and Rawhide. 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sun, Apr 11, 2021 at 4:29 PM Pete Batard wrote: > > On 2021.04.11 21:14, Robert Scheck wrote: > > On Sun, 11 Apr 2021, Neal Gompa wrote: > >> To be absolutely clear, I completely agree with everything here. > >> However, with GRUB being completely dysfunctional upstream and all the > >> pressure from everyone else basically doing nothing, I don't know what > >> else we're supposed to do. Outside of Fedora, I help maintain GRUB for > >> other distributions, and I wound up having no choice but to use the > >> Red Hat tree to get *any* maintained improvements. If there was any > >> light at the end of the tunnel, I would say my own suggestion is > >> completely ridiculous. > >> > >> However, the *major* reason for my suggestion to use the Red Hat tree > >> is that the Btrfs driver has the SUSE patches to be able to read and > >> boot from subvolumes, which are not upstream. > > > > I am sorry, but if some folks decide to run kind of a GRUB2 fork, then > > please do it either properly (e.g. by calling it an official fork and a > > separate project that might attract other projects as GRUB2 alternative), > > or get the changes into upstream. Staying close to upstream is a Fedora > > goal: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects > > > > As long as EfiFs upstream only supports a non-forked GRUB2, I won't change > > my package except when being forced officially by FESCo to do so (in that > > case I will consider orphaning the package). > > > > Anyway, as long as systemd-boot upstream does not seem to care much about > > whether vfat XBOOTLDR is working at all (even an EfiFs driver is loaded by > > UEFI itself; their own internal UEFI driver loader is not yet implemented), > > a discussion about EfiFs using the Red Hat GRUB2 fork is IMHO unnecessary. > > I'm just going to add that, since I am patching GRUB in EfiFs anyway > (https://github.com/pbatard/efifs/blob/master/0001-GRUB-fixes.patch), > mostly to fix incompatibilities with EDK2 or MSVC, then if someone can > point me to the exact subset of commits you'd like to see applied, I > *may* look into adding a second GRUB patch into my repo, that adds the > changes required to address your issue (provided that these can be > condensed to a reasonable sized patch and don't require extensive rework). > > Considering that one must already apply one patch to the GRUB tree for > EfiFs compilation anyway, this might hopefully provide a compromise that > is good enough to satisfy everyone... > > But of course, I need to know what is the minimal subset of changes, > that Fedora's GRUB has, and that you need to see applied to EfiFs's GRUB. > You can see the commits here: https://github.com/rhboot/grub2/commits/fedora-35/grub-core/fs The commits applied by "martinezjavier" on March 22 are the only commits we have in grub-core/fs that's not in mainline GRUB2. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sun, 11 Apr 2021, Robert Scheck wrote: > Anyway, as long as systemd-boot upstream does not seem to care much about > whether vfat XBOOTLDR is working at all (even an EfiFs driver is loaded by > UEFI itself; their own internal UEFI driver loader is not yet implemented), > a discussion about EfiFs using the Red Hat GRUB2 fork is IMHO unnecessary. Sorry, I meant: [...] whether *non*-vfat XBOOTLDR is working [...] Regards, Robert pgpNYtVhIKdJV.pgp Description: PGP 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sun, 11 Apr 2021, Neal Gompa wrote: > To be absolutely clear, I completely agree with everything here. > However, with GRUB being completely dysfunctional upstream and all the > pressure from everyone else basically doing nothing, I don't know what > else we're supposed to do. Outside of Fedora, I help maintain GRUB for > other distributions, and I wound up having no choice but to use the > Red Hat tree to get *any* maintained improvements. If there was any > light at the end of the tunnel, I would say my own suggestion is > completely ridiculous. > > However, the *major* reason for my suggestion to use the Red Hat tree > is that the Btrfs driver has the SUSE patches to be able to read and > boot from subvolumes, which are not upstream. I am sorry, but if some folks decide to run kind of a GRUB2 fork, then please do it either properly (e.g. by calling it an official fork and a separate project that might attract other projects as GRUB2 alternative), or get the changes into upstream. Staying close to upstream is a Fedora goal: https://fedoraproject.org/wiki/Staying_close_to_upstream_projects As long as EfiFs upstream only supports a non-forked GRUB2, I won't change my package except when being forced officially by FESCo to do so (in that case I will consider orphaning the package). Anyway, as long as systemd-boot upstream does not seem to care much about whether vfat XBOOTLDR is working at all (even an EfiFs driver is loaded by UEFI itself; their own internal UEFI driver loader is not yet implemented), a discussion about EfiFs using the Red Hat GRUB2 fork is IMHO unnecessary. Regards, Robert pgpDynFpQIpTC.pgp Description: PGP 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 11.04.2021 15:22, Nico Kadel-Garcia wrote:
So would "rpm -e". It's dangerous enough for the ordinary user to
remove those that I think it's worth keeping that protection in place.
The /etc/dnf/protected.d/{shim,grub2*}.conf files are part of the grub2*
and shim* packages. It is absolutely safe to remove them.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 11.04.2021 03:12, Chris Murphy wrote: As far as I'm aware, the only two things preventing sd-boot from reading this directory is (a) this $BOOT currently doesn't have the proper Extended Boot Loader partition type GUID, (b) it's ext4 and out of the box the firmware can't read ext4. That's why I use ESP (EFI System Partition) to store kernels and BLS configs. After removing grub2*, kernel-install will start using /boot/efi/loader/entries directory and everything works fine. Installation manual: sudo dnf remove grubby grub2\* shim\* memtest86\* sudo rm -rf /boot/grub2 sudo rm -rf /boot/loader cat /proc/cmdline | cut -d ' ' -f 2- | sudo tee /etc/kernel/cmdline sudo chmod 644 /etc/kernel/cmdline sudo bootctl --path=/boot/efi install sudo kernel-install add $(uname -r) /lib/modules/$(uname -r)/vmlinuz -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
在 2021-04-11星期日的 15:59 +0200，Vitaly Zaitsev via devel写道： > On 11.04.2021 03:19, Chris Murphy wrote: > > That condition is met by efifs, ergo by wrapping GRUB file system > > modules as EFI file system drivers. > > Is it possible to install such EFI filesystem drivers without > patching > UEFI BIOS? You are not **patching** UEFI, instead you just register a driver via efibootmgr. > > -- > Sincerely, > Vitaly Zaitsev (vit...@easycoding.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.fedoraproje > ct.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 11.04.2021 03:19, Chris Murphy wrote: That condition is met by efifs, ergo by wrapping GRUB file system modules as EFI file system drivers. Is it possible to install such EFI filesystem drivers without patching UEFI BIOS? -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 2:35 PM Vitaly Zaitsev via devel
wrote:
>
> On 10.04.2021 20:32, Matthew Miller wrote:
> > Protected doesn't mean that it's impossible to remove
>
> Problem: The operation would result in removing the following protected
> packages: grub2-efi-x64, grub2-pc, grub2-tools-minimal, shim-x64
> (try to add '--skip-broken' to skip uninstallable packages)
>
> > rm /etc/dnf/protected.d/{shim,grub2*}.conf
>
> It works, thanks.
So would "rpm -e". It's dangerous enough for the ordinary user to
remove those that I think it's worth keeping that protection in place.
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
Ordinarily, no. But in this case, since GRUB 2.06~rc1 is required to solve major critical vulnerabilities and it's very difficult to pull the patch set that fixes it (>115 patches!) backwards, GRUB got moved forward instead. GRUB 2.06~rc1 was pretty much released to release the patch set... got it. then will stick with v2.06, and try to get it re-patched for Xen @ the bug. thx. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sun, Apr 11, 2021 at 8:23 AM PGNet Dev wrote: > > tangentially related ... > > distro update on f33 from grub 2.04-release -> 2.06-rc (re)breaks Xen boot on > EFI. > > already reopened the original bug, but a question: > > is it normal/expected to push an *rc* (grub 2.06-rc, in this case), to > 'supported' fedora (33) *release*? > unreleased f34/rawhide I can understand. Ordinarily, no. But in this case, since GRUB 2.06~rc1 is required to solve major critical vulnerabilities and it's very difficult to pull the patch set that fixes it (>115 patches!) backwards, GRUB got moved forward instead. GRUB 2.06~rc1 was pretty much released to release the patch set... -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
tangentially related ... distro update on f33 from grub 2.04-release -> 2.06-rc (re)breaks Xen boot on EFI. already reopened the original bug, but a question: is it normal/expected to push an *rc* (grub 2.06-rc, in this case), to 'supported' fedora (33) *release*? unreleased f34/rawhide I can understand. ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sun, Apr 11, 2021 at 7:22 AM Pete Batard wrote: > > Hello all, > > On 2021.04.11 04:47, Chris Murphy wrote: > > On Sat, Apr 10, 2021 at 7:54 PM Robert Scheck > > wrote: > >> > >> On Sat, 10 Apr 2021, Neal Gompa wrote: > >>> We do have those packaged in Fedora: > >>> https://src.fedoraproject.org/rpms/efifs > > Interesting. I had no idea Fedora had an EfiFs package. > > >>> The GRUB2 sources being used as an input is wrong, though. > > I think there's a major issue with the GRUB2 maintainership being > reluctant to release, even when they are critical issues (such as > BootHole) that do warrant an immediate release. > > This is causing a lot of issues downstream, with distros maintaining > their own (incompatible) forks with cherry picked patches, and, I > believe, ultimately makes people reluctant to try to upstream anything, > because, even if their patch makes it into the git repo, it may > literally be years before it appears into a dot release. > > I mentioned this explicitly on the list > (https://lists.gnu.org/archive/html/grub-devel/2020-10/threads.html#00073), > but it looks like most people there don't seem to be of the opinion that > this is a major showstopper or that dot releases are that consequential > (which, ironically, may very well due to the fact that most distros > prefer working on their own fork rather than upstream). > > If GRUB2 was what I would call a functional project, there should be no > reason for Fedora or other distros to maintain their own fork (outside > of perhaps a few supplementary patches, that shouldn't impact much of > anything), as, as is the case with other projects, I would expect distro > maintainers to be able to reach a compromise with the upstream project > to ensure that it can satisfy their needs in a timely manner, without > the need for a custom distro specific fork. > > All this to say that, the GRUB2 being used might be "wrong", but this is > really a direct result of the GRUB2 project being dysfunctional in terms > of producing releases in a timely manner, and I'd rather see pressure > being put on the GRUB 2 project to improve things in that respect, than > go with the idea that trying to upstream the patches a distro might need > has now become essentially pointless, and therefore that having each > distro maintain a fork, with a large deviation from mainline, is an > acceptable practice... > > >>> It should > >>> be using the ones from the rhboot fork: > >>> https://github.com/rhboot/grub2/commits/fedora-35 > >> > >> I am sorry, but honestly I do not have much interest to use the Red Hat > >> grub2 fork, because efifs is patching the grub2 sources as part of its > >> build process - and I am in doubt that the Red Hat grub2 fork won't break > >> this (or something else). > > I second that. You can't just ask a project to go with a dependency that > isn't mainline. Instead, issues that introduce delays with mainline > getting required updates in a timely manner need to be addressed upfront. > > >> And if I would open Pandora's box, I wonder if > >> the efifs upstream maintainer (Cc-ed) is still going to support me further > >> in case of issues (especially if caused by the Red Hat grub2 fork) - Pete? > > To be blunt: Not in a million years. > > Because EfiFs is really a side project for me (I happened to need a > read-only UEFI NTFS driver at the time, so I crafted one by reusing the > GRUB source, and, as because it was relatively easy to do, added a bunch > of file systems I didn't really need), I can't justify investing that > much time onto it, and I already have some trouble finding enough time > to address some of the issues (sometime major, such as > https://github.com/pbatard/efifs/issues/27) that get reported. > > As such, if someone comes to me with "I'm using EfiFs with non mainline > GRUB 2.0", the first thing I'll tell them is to come back if they can > replicate the issue with mainline. > > > Strictly from the perspective of, who will provide support, I think we > > want to go directly to the upstreams as much as possible. When GRUB's > > file system modules get updates, they appear first upstream, and it'll > > just delay things to have to wait for Fedora's GRUB to be rebased to > > get those updates. > > Another good point. > > This is indeed a two way street: Some of the updates Fedora might want > may ultimately take time to appear upstream, which make it easy to want > to use the Fedora fork as the source, but some critical updates may also > appear in mainline, long before Fedora picks them up (especially if they > create integration conflicts with Fedora's own changes which becomes > more an more of a probability as a fork deviates from mainline). > To be absolutely clear, I completely agree with everything here. However, with GRUB being completely dysfunctional upstream and all the pressure from everyone else basically doing nothing, I don't know what else we're supposed to do. Outside of Fedora, I help maintain GRUB for
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 7:54 PM Robert Scheck wrote: > > On Sat, 10 Apr 2021, Neal Gompa wrote: > > We do have those packaged in Fedora: > > https://src.fedoraproject.org/rpms/efifs > > > > The GRUB2 sources being used as an input is wrong, though. It should > > be using the ones from the rhboot fork: > > https://github.com/rhboot/grub2/commits/fedora-35 > > I am sorry, but honestly I do not have much interest to use the Red Hat > grub2 fork, because efifs is patching the grub2 sources as part of its > build process - and I am in doubt that the Red Hat grub2 fork won't break > this (or something else). And if I would open Pandora's box, I wonder if > the efifs upstream maintainer (Cc-ed) is still going to support me further > in case of issues (especially if caused by the Red Hat grub2 fork) - Pete? Strictly from the perspective of, who will provide support, I think we want to go directly to the upstreams as much as possible. When GRUB's file system modules get updates, they appear first upstream, and it'll just delay things to have to wait for Fedora's GRUB to be rebased to get those updates. And then if something isn't working right, the Red Hat bootloader folks would have to be asked about what's going on, while upstream pretty much is expected to ask if we've tried the upstream source? > My intention of packaging efifs for Fedora was to get systemd-boot handling > my ext4 XBOOTLDR (https://github.com/systemd/systemd/issues/17756), which > still is not working, because of the two issues mentioned there (and less > systemd-boot upstream interest as it seems). That is unfortunate. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 7:35 PM Neal Gompa wrote: > > On Sat, Apr 10, 2021 at 9:20 PM Chris Murphy wrote: > > > "$BOOT must be a file system readable by the firmware" > > > > That condition is met by efifs, ergo by wrapping GRUB file system > > modules as EFI file system drivers. For non-UEFI, in effect, the spec > > insists that $BOOT is FAT. And I think that's fine for systemd-boot to > > implement a subset of the spec and have such a requirement, it is not > > OK for the spec to have arbitrary requirements. > > > > > > We do have those packaged in Fedora: https://src.fedoraproject.org/rpms/efifs Cool! > We also would need these EFI binaries signed in order for the firmware > to load them. Yep. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, 10 Apr 2021, Neal Gompa wrote: > We do have those packaged in Fedora: https://src.fedoraproject.org/rpms/efifs > > The GRUB2 sources being used as an input is wrong, though. It should > be using the ones from the rhboot fork: > https://github.com/rhboot/grub2/commits/fedora-35 I am sorry, but honestly I do not have much interest to use the Red Hat grub2 fork, because efifs is patching the grub2 sources as part of its build process - and I am in doubt that the Red Hat grub2 fork won't break this (or something else). And if I would open Pandora's box, I wonder if the efifs upstream maintainer (Cc-ed) is still going to support me further in case of issues (especially if caused by the Red Hat grub2 fork) - Pete? My intention of packaging efifs for Fedora was to get systemd-boot handling my ext4 XBOOTLDR (https://github.com/systemd/systemd/issues/17756), which still is not working, because of the two issues mentioned there (and less systemd-boot upstream interest as it seems). Regards, Robert pgpJKOtnm9ven.pgp Description: PGP 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: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 9:20 PM Chris Murphy wrote: > > On Sat, Apr 10, 2021 at 3:55 PM Vitaly Zaitsev via devel > wrote: > > > > On 10.04.2021 23:16, PGNet Dev wrote: > > > https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-1-boot-loader-specification-entries > > > https://www.freedesktop.org/software/systemd/man/systemd-boot.html > > > > I think the Extended Boot Loader Partition is not suitable for Fedora > > yet because it does not support symlinks (FAT32 by specification) > > "$BOOT must be a file system readable by the firmware" > > That condition is met by efifs, ergo by wrapping GRUB file system > modules as EFI file system drivers. For non-UEFI, in effect, the spec > insists that $BOOT is FAT. And I think that's fine for systemd-boot to > implement a subset of the spec and have such a requirement, it is not > OK for the spec to have arbitrary requirements. > > We do have those packaged in Fedora: https://src.fedoraproject.org/rpms/efifs The GRUB2 sources being used as an input is wrong, though. It should be using the ones from the rhboot fork: https://github.com/rhboot/grub2/commits/fedora-35 We also would need these EFI binaries signed in order for the firmware to load them. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 3:55 PM Vitaly Zaitsev via devel wrote: > > On 10.04.2021 23:16, PGNet Dev wrote: > > https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-1-boot-loader-specification-entries > > https://www.freedesktop.org/software/systemd/man/systemd-boot.html > > I think the Extended Boot Loader Partition is not suitable for Fedora > yet because it does not support symlinks (FAT32 by specification) "$BOOT must be a file system readable by the firmware" That condition is met by efifs, ergo by wrapping GRUB file system modules as EFI file system drivers. For non-UEFI, in effect, the spec insists that $BOOT is FAT. And I think that's fine for systemd-boot to implement a subset of the spec and have such a requirement, it is not OK for the spec to have arbitrary requirements. >and > Fedora's grub2 contains at least one: > > $ sudo file /boot/grub2/grubenv > /boot/grub2/grubenv: symbolic link to ../efi/EFI/fedora/grubenv grubenv and grub.cfg are no longer on the ESP, starting with Fedora 34. Both are located in /boot/grub2/ as a result of: https://fedoraproject.org/wiki/Changes/UnifyGrubConfig -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 3:10 PM Vitaly Zaitsev via devel wrote: > > On 10.04.2021 23:00, Chris Murphy wrote: > > Both of those resolve to $BOOT/loader/entries and systemd-boot > > supports either EFI System partition or Extended Boot Loader > > partition. > > if ! [[ $MACHINE_ID ]]; then > ENTRY_DIR_ABS=$(mktemp -d /tmp/kernel-install.X) || exit 1 > trap "rm -rf '$ENTRY_DIR_ABS'" EXIT INT QUIT PIPE > elif [[ -d /efi/loader/entries ]] || [[ -d /efi/$MACHINE_ID ]]; then > ENTRY_DIR_ABS="/efi/$MACHINE_ID/$KERNEL_VERSION" > elif [[ -d /boot/loader/entries ]] || [[ -d /boot/$MACHINE_ID ]]; then > ENTRY_DIR_ABS="/boot/$MACHINE_ID/$KERNEL_VERSION" > elif [[ -d /boot/efi/loader/entries ]] || [[ -d /boot/efi/$MACHINE_ID > ]]; then > ENTRY_DIR_ABS="/boot/efi/$MACHINE_ID/$KERNEL_VERSION" > elif mountpoint -q /efi; then > ENTRY_DIR_ABS="/efi/$MACHINE_ID/$KERNEL_VERSION" > elif mountpoint -q /boot/efi; then > ENTRY_DIR_ABS="/boot/efi/$MACHINE_ID/$KERNEL_VERSION" > else > ENTRY_DIR_ABS="/boot/$MACHINE_ID/$KERNEL_VERSION" > fi > > If the /boot/loader/entries directory is exists, kernel-install will use > it. systemd-boot cannot read configs from this directory. As far as I'm aware, the only two things preventing sd-boot from reading this directory is (a) this $BOOT currently doesn't have the proper Extended Boot Loader partition type GUID, (b) it's ext4 and out of the box the firmware can't read ext4. If /boot is $BOOT, then it has /loader/entries/ same as an ESP as $BOOT. (a) is not supported by parted, which is what anaconda uses; (b) efifs doesn't exist yet in Fedora. So for the pure Boot Loader Spec implementation, it's not possibly out of the box no matter how you look at it. You've got post-install tasks. But the implementation we have is also more flexible for non-UEFI systems and other arches, and Boot Loader Spec as currently written is very x86 UEFI specific, so if it's going to get more broad adoption, the spec will need to be broadened. > > $ dnf -C repoquery --list grub2-efi-x64 > /boot/efi/EFI/fedora/fonts > /boot/efi/EFI/fedora/grub.cfg > /boot/efi/EFI/fedora/grubenv > /boot/efi/EFI/fedora/grubx64.efi > /boot/grub2/grubenv > /boot/loader/entries > /etc/grub2-efi.cfg > > That's why we need to remove grub2* packages. We should also drop /boot/efi in favor of either /boot or /efi, both of which sd-boot supports. It's possible none of the above is appropriate, and instead should be owned by bootupd or alternatively sd-boot, and mounted only on-demand in a location of the owner's choosing. These are not user or even sys admin serviceable partitions. They belong to the bootloader. And persistently mounting them has always been a weak 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 10.04.2021 23:16, PGNet Dev wrote: https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-1-boot-loader-specification-entries https://www.freedesktop.org/software/systemd/man/systemd-boot.html I think the Extended Boot Loader Partition is not suitable for Fedora yet because it does not support symlinks (FAT32 by specification) and Fedora's grub2 contains at least one: $ sudo file /boot/grub2/grubenv /boot/grub2/grubenv: symbolic link to ../efi/EFI/fedora/grubenv -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 10.04.2021 23:16, PGNet Dev wrote: Boot entries defined with Boot Loader Specification description files located in /loader/entries/ on the ESP and the Extended Boot Loader Partition. These usually describe Linux kernel images with associated initrd images, but alternatively may also describe arbitrary other EFI executables." Thanks. I will create a new Extended Boot Loader Partition and switch to this configuration. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
If the /boot/loader/entries directory is exists, kernel-install will use it. systemd-boot cannot read configs from this directory. fyi, https://systemd.io/BOOT_LOADER_SPECIFICATION/#type-1-boot-loader-specification-entries https://www.freedesktop.org/software/systemd/man/systemd-boot.html "During boot systemd-boot automatically assembles a list of boot entries from the following sources: Boot entries defined with Boot Loader Specification description files located in /loader/entries/ on the ESP and the Extended Boot Loader Partition. These usually describe Linux kernel images with associated initrd images, but alternatively may also describe arbitrary other EFI executables." ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 10.04.2021 23:00, Chris Murphy wrote: Both of those resolve to $BOOT/loader/entries and systemd-boot supports either EFI System partition or Extended Boot Loader partition. if ! [[ $MACHINE_ID ]]; then ENTRY_DIR_ABS=$(mktemp -d /tmp/kernel-install.X) || exit 1 trap "rm -rf '$ENTRY_DIR_ABS'" EXIT INT QUIT PIPE elif [[ -d /efi/loader/entries ]] || [[ -d /efi/$MACHINE_ID ]]; then ENTRY_DIR_ABS="/efi/$MACHINE_ID/$KERNEL_VERSION" elif [[ -d /boot/loader/entries ]] || [[ -d /boot/$MACHINE_ID ]]; then ENTRY_DIR_ABS="/boot/$MACHINE_ID/$KERNEL_VERSION" elif [[ -d /boot/efi/loader/entries ]] || [[ -d /boot/efi/$MACHINE_ID ]]; then ENTRY_DIR_ABS="/boot/efi/$MACHINE_ID/$KERNEL_VERSION" elif mountpoint -q /efi; then ENTRY_DIR_ABS="/efi/$MACHINE_ID/$KERNEL_VERSION" elif mountpoint -q /boot/efi; then ENTRY_DIR_ABS="/boot/efi/$MACHINE_ID/$KERNEL_VERSION" else ENTRY_DIR_ABS="/boot/$MACHINE_ID/$KERNEL_VERSION" fi If the /boot/loader/entries directory is exists, kernel-install will use it. systemd-boot cannot read configs from this directory. $ dnf -C repoquery --list grub2-efi-x64 /boot/efi/EFI/fedora/fonts /boot/efi/EFI/fedora/grub.cfg /boot/efi/EFI/fedora/grubenv /boot/efi/EFI/fedora/grubx64.efi /boot/grub2/grubenv /boot/loader/entries /etc/grub2-efi.cfg That's why we need to remove grub2* packages. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
> This shouldn't be the case. Unless there's a bug, grub2 may be > installed an unused. If it interferes with sd-boot, please file > a bug. The grub2-efi-x64 package contains directory /boot/loader/entries. AFAICT this directory presence alone makes kernel-install script install the boot files there instead of /boot/efi/loader (which is needed for sd-boot). Should this be considered a grub2 bug? ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 2:39 PM Vitaly Zaitsev via devel wrote: > > On 10.04.2021 22:22, Neal Gompa wrote: > > GRUB by default uses the same configuration snippets as sd-boot for > > the past few releases: > > https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault > > /boot/loader/entries/ instead of /boot/efi/loader/entries/. Both of those resolve to $BOOT/loader/entries and systemd-boot supports either EFI System partition or Extended Boot Loader partition. The spec proposes putting kernel/initramfs in a different location than we do, $BOOT/$MACHINEID/$VERSION/linux\|initramfs but blscfg for GRUB and sd-boot will do whatever the BLS snippet tells it to do. I think. It's an explicit format. > systemd-boot cannot read ext4/btrfs fs. It can read only FAT32 (ESP). It can read whatever the firmware can read. sd-boot can't even read FAT32, it's the firmware that reads it. And efifs means the firmware can read anything we want it to read. https://github.com/pbatard/efifs -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 10.04.2021 22:22, Neal Gompa wrote: GRUB by default uses the same configuration snippets as sd-boot for the past few releases: https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault /boot/loader/entries/ instead of /boot/efi/loader/entries/. systemd-boot cannot read ext4/btrfs fs. It can read only FAT32 (ESP). -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 4:20 PM Vitaly Zaitsev via devel wrote: > > On 10.04.2021 21:34, Zbigniew Jędrzejewski-Szmek wrote: > > Every once in a while something pulls in the grub stack. For a long > > time this was grubby. Maybe now it's something else. > > Proprietary NVIDIA drivers from RPM Fusion repository has a strict > dependency on grubby. > > > This shouldn't be the case. Unless there's a bug, grub2 may be > > installed an unused. If it interferes with sd-boot, please file > > a bug. > > The problem is /usr/bin/kernel-install. If the grub2* packages are > installed the kernel-install script uses /boot for kernels/configs. > systemd-boot uses /boot/efi/$machine_id. GRUB by default uses the same configuration snippets as sd-boot for the past few releases: https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 10.04.2021 21:34, Zbigniew Jędrzejewski-Szmek wrote: Every once in a while something pulls in the grub stack. For a long time this was grubby. Maybe now it's something else. Proprietary NVIDIA drivers from RPM Fusion repository has a strict dependency on grubby. This shouldn't be the case. Unless there's a bug, grub2 may be installed an unused. If it interferes with sd-boot, please file a bug. The problem is /usr/bin/kernel-install. If the grub2* packages are installed the kernel-install script uses /boot for kernels/configs. systemd-boot uses /boot/efi/$machine_id. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 08:26:02PM +0200, Vitaly Zaitsev via devel wrote: > Hello. > > Today I found[1] that the grub* and shim* packages are now protected > in Fedora 34 and cannot be removed by dnf. I think this change > should be reverted before the F34 release, because some users don't > use Grub at all. Every once in a while something pulls in the grub stack. For a long time this was grubby. Maybe now it's something else. > I'm using systemd-boot and all grub2 packages must be removed for > the systemd-boot scripts to work properly. This shouldn't be the case. Unless there's a bug, grub2 may be installed an unused. If it interferes with sd-boot, please file a bug. And finally, you can remove protected packages by using 'rpm -e' directly. Zbyszek ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 08:35:11PM +0200, Vitaly Zaitsev via devel wrote: > >Protected doesn't mean that it's impossible to remove > Problem: The operation would result in removing the following > protected packages: grub2-efi-x64, grub2-pc, grub2-tools-minimal, > shim-x64 > (try to add '--skip-broken' to skip uninstallable packages) That error message could be better, obviously. The skip-broken advice isn't helpful, obviously. Probably worth a bug report with DNF. -- Matthew Miller Fedora Project Leader ___ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On 10.04.2021 20:32, Matthew Miller wrote:
Protected doesn't mean that it's impossible to remove
Problem: The operation would result in removing the following protected
packages: grub2-efi-x64, grub2-pc, grub2-tools-minimal, shim-x64
(try to add '--skip-broken' to skip uninstallable packages)
rm /etc/dnf/protected.d/{shim,grub2*}.conf
It works, thanks.
--
Sincerely,
Vitaly Zaitsev (vit...@easycoding.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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Grub 2 protected packages
On Sat, Apr 10, 2021 at 08:26:02PM +0200, Vitaly Zaitsev via devel wrote:
> Today I found[1] that the grub* and shim* packages are now protected
> in Fedora 34 and cannot be removed by dnf. I think this change
> should be reverted before the F34 release, because some users don't
> use Grub at all.
Protected doesn't mean that it's impossible to remove -- you can change the
DNF protected_packages option temporarily, or simply
rm /etc/dnf/protected.d/{shim,grub2*}.conf
before removing them. That's an extra step for an edge case, which I think
is okay given the benefit for the general case.
--
Matthew Miller
Fedora Project Leader
___
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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Grub 2 protected packages
Hello. Today I found[1] that the grub* and shim* packages are now protected in Fedora 34 and cannot be removed by dnf. I think this change should be reverted before the F34 release, because some users don't use Grub at all. I'm using systemd-boot and all grub2 packages must be removed for the systemd-boot scripts to work properly. [1]: https://pagure.io/fedora-workstation/issue/165 -- Sincerely, Vitaly Zaitsev (vit...@easycoding.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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
