Description of problem: Using a custom image for the compute nodes. Performing an upgrade of the compute nodes from OSP 16.2 to OSP 17.1 after leapp the nodes reboot but enter in grub Version-Release number of selected component (if applicable): OSP 16.2 How reproducible: Uncertain Steps to Reproduce: 1. Perform upgrade of compute nodes according to documentation but with a custom image 2. 3. Actual results: Compute nodes enter in grub Expected results: Compute nodes to reboot without issues Additional info:
Broken servers can be booted manually from their GRUB shell by manual execution of: $ set root=LABEL=img-rootfs $ linux (lvm/vg-lv_root)/boot/vmlinuz-5.14.0-284.62.1.el9_2.x86_64 root=LABEL=img-rootfs $ initrd (lvm/vg-lv_root)/boot/initramfs-5.14.0-284.62.1.el9_2.x86_64.img $ boot
We had a similar bug for director recently https://bugzilla.redhat.com/show_bug.cgi?id=2266025 . Does it look like a match?
@Alex, no from what I see in 2266025 the nodes rebooted in the old RHEL8 and in this case the system is just stuck on the grub menu unable to boot unless manual actions are taken via console.
IMHO, this issue is very similar to https://bugzilla.redhat.com/show_bug.cgi?id=2279545 but in the FFU scenario
*** Bug 2277685 has been marked as a duplicate of this bug. ***
This customer has Satellite but it seems leapp disabled the custom repository that was being used to serve the HF so they weren't installed during the leapp upgrade. When I check the article [0] leapp needs one of 2 options to be able to use custom repositories, regardless if Satellite is being used: 1) Create the /etc/leapp/files/leapp_upgrade_repositories.repo file, and add one or more repositories. All repositories configured in this file are used only by Leapp during an in-place upgrade. Use this approach if you want to define custom repositories only for the purpose of an in-place upgrade. 2) Use repositories configured in the /etc/yum.repos.d/ directory. This is the standard directory for configuring repositories on a RHEL system, which are used, for example, by the YUM or DNF utility. You can use previously configured repositories or create one or more new .repo files in this directory. If you want to use any of the repositories configured in /etc/yum.repos.d/ for the upgrade, enable each of the selected repositories explicitly when executing the leapp command. In the preupgrade phase: # leapp preupgrade --enablerepo repository_id1 --enablerepo repository_id2 ... # During the in-place upgrade: leapp upgrade --enablerepo repository_id1 --enablerepo repository_id2 ... As leapp upgrade is being done by OpenStack playbooks option 2 does not seem very interesting and option 1 seems to be the best way to ensure leapp picks up the custom repositories. [0] https://access.redhat.com/articles/4977891
NOTE: Leapp ignores the enabled directives set for custom repositories in any of the .repo files. Leapp uses repositories from the /etc/yum.repos.d/ directory if they are enabled through the --enablerepo option of the leapp command, and automatically all repositories configured in the /etc/leapp/files/leapp_upgrade_repositories.repo file.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days