Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Rebuild to see if the builder is fixed
Signed-off-by: Peter Jones <pjones@redhat.com>
nx_required was initialized to 0 but was never assigned
a value. Call grub_efi_check_nx_required() to solve this.
Signed-off-by: Nicolas Frayer <nfrayer@redhat.com>
Although this patch is correct and at some point it will be
re-introduced, currently shim does not support the loader protocol so
drop it in the meanwhile.
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
When upgrading from <=2.06-126 to newer versions, the grub config stub
may have different mode than 0600, so set the latter if this is the case.
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
Fix the rpm verificaton issues (see below) introduced in 2.06.123 [1].
On the other hand, 2.06.125 [2] introduced a change on grub2-mkconfig where
it prevents overwritting {EFI_HOME}/grub.cfg with side effects on the
%posttrans spec script, where it tries to recreate it in case this
file does not exist but due to [2] the {EFI}/grub.cfg file is never
created. Fix the %posttrans code with the logic but applied to
{GRUB_HOME}/grub.cfg.
Issue detected on RHEL CI but also reproduced on fedora since
2.06.123, where this change fixes it.
$ rpm -Vqa
.
.
.M....... c /boot/grub2/grub.cfg
.M....... c /boot/efi/EFI/fedora/grub.cfg
.M....... c /boot/grub2/grub.cfg
.M....... c /boot/efi/EFI/fedora/grub.cfg
.M....... c /boot/grub2/grub.cfg
[1] a137559e71
[2] f28d50ee44
Signed-off-by: Leo Sandoval <lsandova@redhat.com>
Starting with fedpkg 1.45, we can now have `fedpkg build` automatically
trigger both the Rawhide and ELN build of this package, since it cannot
be rebuilt by the normal ELN auto-rebuild service due to the restricted
nature of this package. By adding this file, the maintainer does not
need to remember to build it for both releases manually.
Signed-off-by: Stephen Gallagher <sgallagh@redhat.com>
Xen PV and PVH guest use direct kernel boot and may use 'pygrub' tool to
parse guest's grub config. The tool is incompatible with BLS and thus
99-grub-mkconfig.install disables it. The problem is observed with HVM
guests which are 'normal' VMs and don't require pygrub compatibility. E.g.
legacy AWS instance types are of this kind. Disabling BLS for them is
undesired and unjustified. Luckily, kernel driver for Xen provides
'/sys/hypervisor/guest_type' interface telling us which type of guest are
we running in.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
In the old days before BLS, setting the GRUB_DEFAULT_DTB variable would
create a devicetree entry for each kernel, which would be prepended by
/dtb-${kernelver}, so it was possible to test a different dtb per
installed kernel.
In the transition to BLS, the variable was kept but the functionality is
now slightly different. The value of GRUB_DEFAULT_DTB goes to the
grubenv and that dtb is loaded from the /dtb symlink instead, which may
change with kernel installs.
This patch introduces a different variable which restores the previous
behavior, and adds the devicetree entry to each BLS entry, if set.
This variable is not set by default in an install, so it does not affect
users with default settings.
It is useful for developers and users of boards with not yet stable
upstream support, where changes to the dtb may cause behavior
difference. In these cases, it is desirable to not pick the dtb of just
the latest installed kernel, but keep previous kernel+dtb choices
unaffected as a fallback.
Signed-off-by: Erico Nunes <ernunes@redhat.com>
xz decompression is very slow and slows down boot by around 5 seconds on
aarch64/Apple M1 when using the default font. Switch to lzop, which
takes less than one second to uncompress.
This increases EFI core image size by around 11%.
Signed-off-by: Hector Martin <marcan@marcan.st>
When installing grub2-tools grub2-tools-minimal is pulled in which
obsoletes grub2-tools causing grub2-tools to not get installed.
Remove the obsoletes so that grub2-tools can be installed again.
Signed-off-by: Daan De Meyer <daan.j.demeyer@gmail.com>
Fix enablement of grub services and timer:
- Switch back to static enablement for grub services in tools package
- Add %%triggerpostun to apply grub-boot-success.timer preset
when upgrading from older versions where this was not a preset
Closes: https://bugzilla.redhat.com/show_bug.cgi?id=2247635
Signed-off-by: Christian Glombek <cglombek@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
8800efcb0b replaced '-a' with '--preserve=timestamps' to avoid
preserving ownership information on non vfat file systems. This breaks
copying of the 'dtb' directory on aarch64 systems since '-a' implies
'-r'. Add '-r' to the single place where 'dtb/' is copied to /boot.
Resolves: #2243060
Fixes: 8800efcb0b ("Do not preserve ownership or xattrs on copied files")
Signed-off-by: Janne Grunau <j@jannau.net>
Signed-off-by: Nicolas Frayer <nfrayer@redhat.com>
When kernel-install is called for a UKI, 20-grub.install copies it to /boot
which is totally unneeded, UKIs are now handled by the standard systemd's
90-uki-copy.install (systemd-253+) correctly which places them to the ESP.
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
As noticed in https://bugzilla.redhat.com/show_bug.cgi?id=2239008#c16, when
compiling a kernel as a user and doing 'sudo make install', and when using a
non-vfat fs for the install destination, the file would end up owned by the
user. This is not useful at all, so let's only preserve the timestamps on the
copied file, no other attributes.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
The mkbls() function would write 'linux /vmlinuz-${kernelver}' into the boot
loader entry. But the code that actually copies the file would use the original
file name with a version suffix ('cp -aT "$i" "/boot/${i##*/}-${KERNEL_VERSION}"').
In case of a local kernel build calling /sbin/installkernel this file name was
e.g. 'bzImage', so we would end up with '/bzImage-${KERNEL_VERSION}', which of
course doesn't match '/vmlinuz-*'. The script would later call 'grub2-mkrel'
on the name taken from the boot entry which would fail because the file does not
exist. Rename the argument to "vmlinuz", so that both parts match.
Tested by doing a local kernel build with 'sudo make install' at the end.
Signed-off-by: Zbigniew Jędrzejewski-Szmek <zbyszek@in.waw.pl>
