Alma/Rocky Linux 9 support #57

Closed
opened 2022-10-14 11:32:19 +02:00 by pacofelc · 16 comments
pacofelc commented 2022-10-14 11:32:19 +02:00 (Migrated from github.com)

Hey, Rocky Linux 9 is already out. Is there any chance it gets added to installimage?
Thank's in advance.

Hey, Rocky Linux 9 is already out. Is there any chance it gets added to installimage? Thank's in advance.
asciiprod commented 2022-11-02 13:22:41 +01:00 (Migrated from github.com)

Yes, eventually support will be added.

Yes, eventually support will be added.
asciiprod commented 2023-05-31 09:27:07 +02:00 (Migrated from github.com)

installimage includes limited support for RHEL9-based images since 38226a51
However due to shim unconditionally modifying the boot order and being unremovable as an essential package, support for RHEL-based images will be limited.

Also see: https://github.com/rhboot/shim/issues/568

installimage includes limited support for RHEL9-based images since 38226a51 However due to shim unconditionally modifying the boot order and being unremovable as an essential package, support for RHEL-based images will be limited. Also see: https://github.com/rhboot/shim/issues/568
leetsin commented 2023-06-01 11:35:40 +02:00 (Migrated from github.com)

Thanks a lot Hetzner People 👍😎

@asciiprod as you have custom motherboards, will a custom bios(uefi) solve the net boot problem ?

Thanks a lot Hetzner People 👍😎 @asciiprod as you have custom motherboards, will a custom bios(uefi) solve the net boot problem ?
kleisauke commented 2023-09-12 18:29:40 +02:00 (Migrated from github.com)

and being unremovable as an essential package

shim is in fact removable, it's only marked as protected after commit https://src.fedoraproject.org/rpms/shim/c/f4bf84f7c52ca6b105e03ad22ef3f891d6b37364.

One could remove shim by executing:

$ dnf remove --setopt=protected_packages= "shim-*"
> and being unremovable as an essential package shim is in fact removable, it's only marked as protected after commit https://src.fedoraproject.org/rpms/shim/c/f4bf84f7c52ca6b105e03ad22ef3f891d6b37364. One could remove shim by executing: ```console $ dnf remove --setopt=protected_packages= "shim-*" ````
asciiprod commented 2023-10-24 09:47:19 +02:00 (Migrated from github.com)

While that may allow removing shim, grub has been modified in these distributions and can no longer create an EFI binary.
https://bugzilla.redhat.com/show_bug.cgi?id=1917213

While that may allow removing shim, grub has been modified in these distributions and can no longer create an EFI binary. https://bugzilla.redhat.com/show_bug.cgi?id=1917213
kleisauke commented 2023-10-24 12:29:56 +02:00 (Migrated from github.com)

While that may allow removing shim, grub has been modified in these distributions and can no longer create an EFI binary.
https://bugzilla.redhat.com/show_bug.cgi?id=1917213

According to https://bugzilla.redhat.com/show_bug.cgi?id=1917213#c47, one should not use grub2-install on EFI systems and consider using efibootmgr as an alternative.

Perhaps this patch would help?:

--- a/rockylinux.sh
+++ b/rockylinux.sh
@@ -104,7 +104,7 @@ generate_config_grub() {
 
 write_grub() {
   if [ "$UEFI" -eq 1 ]; then
-    # we must NOT use grub2-install here. This will replace the prebaked
+    # we must NOT use efibootmgr here. This will replace the prebaked
     # grubx64.efi (which looks for grub.cfg in ESP) with a new one, which
     # looks for in in /boot/grub2 (which may be more difficult to read)
     rm -f "$FOLD/hdd/boot/grub2/grubenv"
@@ -115,7 +115,7 @@ write_grub() {
     for ((i=1; i<=COUNT_DRIVES; i++)); do
       if [ "$SWRAID" -eq 1 ] || [ "$i" -eq 1 ] ;  then
         local disk; disk="$(eval echo "\$DRIVE"$i)"
-        execute_chroot_command "grub2-install --no-floppy --recheck $disk 2>&1"
+        execute_chroot_command "efibootmgr -c -d $disk -p 1 -w -L \"Rocky Linux\" -l \EFI\rocky\grubx64.efi 2>&1"
         declare -i EXITCODE=$?
       fi
     done

(untested)

> While that may allow removing shim, grub has been modified in these distributions and can no longer create an EFI binary. > https://bugzilla.redhat.com/show_bug.cgi?id=1917213 According to https://bugzilla.redhat.com/show_bug.cgi?id=1917213#c47, one should not use `grub2-install` on EFI systems and consider using `efibootmgr` as an alternative. Perhaps this patch would help?: ```diff --- a/rockylinux.sh +++ b/rockylinux.sh @@ -104,7 +104,7 @@ generate_config_grub() { write_grub() { if [ "$UEFI" -eq 1 ]; then - # we must NOT use grub2-install here. This will replace the prebaked + # we must NOT use efibootmgr here. This will replace the prebaked # grubx64.efi (which looks for grub.cfg in ESP) with a new one, which # looks for in in /boot/grub2 (which may be more difficult to read) rm -f "$FOLD/hdd/boot/grub2/grubenv" @@ -115,7 +115,7 @@ write_grub() { for ((i=1; i<=COUNT_DRIVES; i++)); do if [ "$SWRAID" -eq 1 ] || [ "$i" -eq 1 ] ; then local disk; disk="$(eval echo "\$DRIVE"$i)" - execute_chroot_command "grub2-install --no-floppy --recheck $disk 2>&1" + execute_chroot_command "efibootmgr -c -d $disk -p 1 -w -L \"Rocky Linux\" -l \EFI\rocky\grubx64.efi 2>&1" declare -i EXITCODE=$? fi done ``` (untested)
kleisauke commented 2023-11-27 14:41:27 +01:00 (Migrated from github.com)

... it looks like https://bugzilla.redhat.com/show_bug.cgi?id=1917213 is now resolved via commit https://src.fedoraproject.org/rpms/grub2/c/8a9297c4314b61eac1f47ab6444615eb9f13874d. You'll have to use the --force option to create the EFI boot entry.

... it looks like https://bugzilla.redhat.com/show_bug.cgi?id=1917213 is now resolved via commit https://src.fedoraproject.org/rpms/grub2/c/8a9297c4314b61eac1f47ab6444615eb9f13874d. You'll have to use the `--force` option to create the EFI boot entry.
asciiprod commented 2023-11-27 14:54:59 +01:00 (Migrated from github.com)

Thank you for the info. Now we have to wait and see if this change will get picked up by the RHEL-clones

Thank you for the info. Now we have to wait and see if this change will get picked up by the RHEL-clones
leonardehrenfried commented 2023-12-10 22:35:39 +01:00 (Migrated from github.com)

What about the suggestion to use efibootmgr instead of grub-install?

Wouldn't that be the better solution?

What about the suggestion to use efibootmgr instead of grub-install? Wouldn't that be the better solution?
kleisauke commented 2023-12-23 12:59:59 +01:00 (Migrated from github.com)

I just requested a backport for that commit to RHEL 9 in PR https://github.com/rhboot/grub2/pull/135.

I just requested a backport for that commit to RHEL 9 in PR https://github.com/rhboot/grub2/pull/135.
kleisauke commented 2024-02-22 14:41:09 +01:00 (Migrated from github.com)

... that commit has just been backported to RHEL 9, see:
grub2/-@6c0546793a

It should become available in the upcoming RHEL 9.4.0 release. 🎉

... that commit has just been backported to RHEL 9, see: https://gitlab.com/redhat/centos-stream/rpms/grub2/-/commit/6c0546793ae19d7a217cd7add5b7a493bfad41a6 It should become available in the upcoming RHEL 9.4.0 release. :tada:
leonardehrenfried commented 2024-03-20 22:21:42 +01:00 (Migrated from github.com)

Sorry for the nag but is it going to be possible to use CentOS 9 now that the above fix has been added?

Sorry for the nag but is it going to be possible to use CentOS 9 now that the above fix has been added?
kleisauke commented 2024-04-14 17:15:10 +02:00 (Migrated from github.com)

It looks like Hetzner now offers support for AlmaLinux 9, CentOS Stream 9 and Rocky Linux 9 on the AX41-NVMe servers:
https://www.hetzner.com/dedicated-rootserver/matrix-ax#software-2286

It looks like Hetzner now offers support for AlmaLinux 9, CentOS Stream 9 and Rocky Linux 9 on the [AX41-NVMe](https://www.hetzner.com/dedicated-rootserver/ax41-nvme/) servers: https://www.hetzner.com/dedicated-rootserver/matrix-ax#software-2286
kleisauke commented 2024-05-07 08:50:50 +02:00 (Migrated from github.com)

It should become available in the upcoming RHEL 9.4.0 release.

Unfortunately, this change was not shipped in RHEL 9.4.

> It should become available in the upcoming RHEL 9.4.0 release. Unfortunately, this change was not shipped in RHEL 9.4.
kleisauke commented 2024-06-15 12:09:10 +02:00 (Migrated from github.com)

This fix has just been shipped in grub2-2.06-80.el9_4, so ignore my previous comment. See for reference:
openela-main/grub2@98b580a7c4
grub2/-@b524202569
rpms/grub2@373fa37ba6

This fix has just been shipped in `grub2-2.06-80.el9_4`, so ignore my previous comment. See for reference: https://github.com/openela-main/grub2/commit/98b580a7c4a34170534dcae70a54199f60b7150e https://git.rockylinux.org/staging/rpms/grub2/-/commit/b524202569789ead872d1d71d35257f1e9d8a601 https://git.almalinux.org/rpms/grub2/commit/373fa37ba6d6083bb1a96c90494d0ca2309bb4a4
pat-s commented 2024-06-26 23:22:50 +02:00 (Migrated from github.com)

I was able to install a fresh Alma9 on an AX42 -> instructions.

I was able to install a fresh Alma9 on an AX42 [-> instructions](https://forums.almalinux.org/t/upgrade-8-8-to-9-2-using-leapp-does-not-boot-into-elevate-upgrade-initramfs/2566/5?u=pat-s).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
DiamantTh/installimage#57
No description provided.