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 o
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 hav
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
R
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
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 of
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 le
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!
___
deve
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.
> >
> >
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
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.
> >
>
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
> >> pressur
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
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,
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 s
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 wh
在 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 BIO
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)
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-mini
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
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
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
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
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
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
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,
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/so
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
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
> EN
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
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 describ
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
"Du
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 '$ENTR
> 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
t
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/
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. I
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 Fusio
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 cas
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 G
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-bro
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)
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.
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
42 matches
Mail list logo
