Open rmetrich opened 3 months ago
Please note that every PR needs to comply with the Leapp Guidelines and must pass all tests in order to be mergeable. If you want to request a review or rebuild a package in copr, you can use following commands as a comment:
Packit will automatically schedule regression tests for this PR's build and latest upstream leapp build. If you need a different version of leapp, e.g. from PR#42, use /packit test oamg/leapp#42
Note that first time contributors cannot run tests automatically - they will be started by a reviewer.
It is possible to schedule specific on-demand tests as well. Currently 2 test sets are supported, beaker-minimal
and kernel-rt
, both can be used to be run on all upgrade paths or just a couple of specific ones.
To launch on-demand tests with packit:
kernel-rt
tests set for all upgrade pathskernel-rt
and beaker-minimal
test sets for 8.10->9.4 upgrade pathSee other labels for particular jobs defined in the .packit.yaml
file.
Please open ticket in case you experience technical problem with the CI. (RH internal only)
Note: In case there are problems with tests not being triggered automatically on new PR/commit or pending for a long time, please contact leapp-infra.
/packit copr-build
@pirat89 for your kind eyes :)
/packit copr-build
Hi! We stumbled across this issue during an leapp upgrade and i was wondering if @mkluson had the time to review this PR so it can be merged!
Hello @Macleykun, The review has already been done by @pirat89. He mentions me as I am responsible for leapp priorities in RHEL. Because this project is quite connected with RHEL workflows, I have to ensure I have enough RHEL recourses first.
What version of leapp, and where do you use?
Hello @Macleykun, The review has already been done by @pirat89. He mentions me as I am responsible for leapp priorities in RHEL. Because this project is quite connected with RHEL workflows, I have to ensure I have enough RHEL recourses first.
What version of leapp, and where do you use?
hi! tottaly understand that the implications of merging this has consequences of everyone who uses leapp for rhel!
We use this version of leapp: leapp-0.17.0-1.el8
We used this on one of our internal mailservers, my collegeue stumbled across the issue after the inplace upgrade was finished:
We do use EFI + secureboot so we fall under this condition stated in this PR.
I am planning on testing this patch to see if that remdiates the issue if that helps with testing/ensurance. edit: seem the issue still persists.
@Macleykun please follow RHEL-36249 to have the latest information when it is supposed to land in RHEL.
I see same scenario happening 8.10 EFI boot and GRUB 2.06 going to cli after the initramfs inplaceupgrade runs... I can manually boot the OS on RHEL 9.4 from the GRUB cli and I see indeed the /boot/efi/EFI/redhat/grub.cfg content is not as it should... I tried "injecting" the proposed actor before running the upgrade and I see it being executed, as per the logs, but still did not solve the issue and went again into GRUB 2.06 cli after reboot...
I see same scenario happening 8.10 EFI boot and GRUB 2.06 going to cli after the initramfs inplaceupgrade runs... I can manually boot the OS on RHEL 9.4 from the GRUB cli and I see indeed the /boot/efi/EFI/redhat/grub.cfg content is not as it should... I tried "injecting" the proposed actor before running the upgrade and I see it being executed, as per the logs, but still did not solve the issue and went again into GRUB 2.06 cli after reboot...
May I ask how you were able to boot to rhel 9? I tried but couldn’t find clear steps how to do it from there.
I see same scenario happening 8.10 EFI boot and GRUB 2.06 going to cli after the initramfs inplaceupgrade runs... I can manually boot the OS on RHEL 9.4 from the GRUB cli and I see indeed the /boot/efi/EFI/redhat/grub.cfg content is not as it should... I tried "injecting" the proposed actor before running the upgrade and I see it being executed, as per the logs, but still did not solve the issue and went again into GRUB 2.06 cli after reboot...
May I ask how you were able to boot to rhel 9? I tried but couldn’t find clear steps how to do it from there.
Hey @Macleykun , Sure you can ask... from the console on the GRUB cli you load the corresponding files and boot them running the following 3 commands: linux (hd0,gpt2)/vmlinuz-5.14.0-427.26.1.el9_4.x86_64 root=/dev/{{device with root fs}} initrd (hd0,gpt2)/initramfs-5.14.0-427.26.1.el9_4.x86_64.img boot
note: hd0 is the disk and gpt2 is the partition where /boot is located... the grub cli has tab autocomplete which will help you. last minute note: as in /boot/efi/EFI/redhat/grub.cfg I see it writes something to load configs from /boot/grub2/grub.cfg I just tried creating that file before running upgrade and it worked for me... so try grub2-mkconfig -o /boot/grub2/grub.cfg and then leapp upgrade... see if that works for you.
I see same scenario happening 8.10 EFI boot and GRUB 2.06 going to cli after the initramfs inplaceupgrade runs... I can manually boot the OS on RHEL 9.4 from the GRUB cli and I see indeed the /boot/efi/EFI/redhat/grub.cfg content is not as it should... I tried "injecting" the proposed actor before running the upgrade and I see it being executed, as per the logs, but still did not solve the issue and went again into GRUB 2.06 cli after reboot...
May I ask how you were able to boot to rhel 9? I tried but couldn’t find clear steps how to do it from there.
Hey @Macleykun , Sure you can ask... from the console on the GRUB cli you load the corresponding files and boot them running the following 3 commands: linux (hd0,gpt2)/vmlinuz-5.14.0-427.26.1.el9_4.x86_64 root=/dev/{{device with root fs}} initrd (hd0,gpt2)/initramfs-5.14.0-427.26.1.el9_4.x86_64.img boot
note: hd0 is the disk and gpt2 is the partition where /boot is located... the grub cli has tab autocomplete which will help you. last minute note: as in /boot/efi/EFI/redhat/grub.cfg I see it writes something to load configs from /boot/grub2/grub.cfg I just tried creating that file before running upgrade and it worked for me... so try grub2-mkconfig -o /boot/grub2/grub.cfg and then leapp upgrade... see if that works for you.
Thanks this did the trick! Thank you so much for suggesting this! I did make the grub2 config for the original efi location and removed the one for the bios location and also that worked! Sorry to everyone for my (unrelated) replies for this PR.
When upgrading a UEFI system with /boot on Software Raid, the
/boot/efi/EFI/redhat/grub.cfg
wrapper is created with unexpected content, causing the system to land intogrub>
prompt upon upgrade completion.jira: https://issues.redhat.com/browse/RHEL-36186 RHEL-36249