-
Bug
-
Resolution: Done-Errata
-
Major
-
rhel-8.10.z
-
None
-
grub2-2.02-165.el8_10
-
Yes
-
Important
-
rhel-bootloader
-
ssg_core_services
-
3
-
False
-
False
-
-
None
-
None
-
Pass
-
RegressionOnly
-
Unspecified
-
Unspecified
-
Unspecified
-
-
All
-
None
What were you trying to do that didn't work?
Leapp upgrade from 7 -> 8.10 and 8 -> 9.4
What is the impact of this issue to you?
Prevents upgrades
Please provide the package NVR for which the bug is seen:
$ grep leapp installed-rpms leapp-0.18.0-1.el8_10.noarch Tue Apr 1 16:06:51 2025 leapp-deps-0.18.0-1.el8_10.noarch Tue Apr 1 16:06:51 2025 leapp-upgrade-el8toel9-0.21.0-2.el8_10.noarch Tue Apr 1 16:06:53 2025 leapp-upgrade-el8toel9-deps-0.21.0-2.el8_10.noarch Tue Apr 1 16:06:51 2025 python3-leapp-0.18.0-1.el8_10.noarch Tue Apr 1 16:06:51 2025
The customer claims:
vmlinuz-4.18.0-553.46.1.el8_10.x86_64 works well vmlinuz-4.18.0-553.47.1.el8_10.x86_64 don't boot, with same issue. and 5.14.0-503.34.1.el9_5.x86_64 fails as well
How reproducible is this bug?:
For the customer, 100%
We retrieved both their initramfs and kernel images and are unable to reproduce the issue in house.
Steps to reproduce
- convert2rhel centos to rhel
- rhel 7 leapp to rhel 8
- optional, rhel 8 leapp to rhel 9
Expected results
Boots
Actual results
Boot failure with an inability to decompress the initramfs.
unable to boot with their RHEL 8->9 leapp upgrade entry, getting the following error:
[ 1.358085] Initramfs unpacking failed: uncompression error
and then naturally:
[ 1.810292] md: Waiting for [ 1.810292] md: Waiting for all devices to be available before autodetect [ 1.810401] md: If you don't use raid, use raid=noautodetect [ 1.810513] md: Autodetecting RAID arrays. [ 1.810588] md: autorun ... [ 1.810638] md: ... autorun DONE. [ 1.810717] List of all partitions: [ 1.810775] No filesystem could mount root, tried: [ 1.810776] [ 1.810885] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) [ 1.819588] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.14.0-503.35.1.el9_5.x86_64 #1 [ 1.821269] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 [ 1.823843] Call Trace: [ 1.824363] <TASK> [ 1.824816] dump_stack_lvl+0x34/0x48 [ 1.825613] panic+0x107/0x2bb [ 1.826282] mount_root_generic+0x1c6/0x1d9 [ 1.827134] ? mount_root+0x134/0x176 [ 1.827888] prepare_namespace+0x1ae/0x1f5 [ 1.828723] kernel_init_freeable+0x182/0x1a7 [ 1.829625] ? __pfx_kernel_init+0x10/0x10 [ 1.830483] kernel_init+0x16/0x130 [ 1.831204] ret_from_fork+0x29/0x50 [ 1.831938] </TASK> [ 2.885567] Shutting down cpus with NMI
We tried several things:
- Moved the VM to another hypervisor, as we suspected memory problems. Still the same problem.
- Booted the VM with a RHEL 9.5 ISO, in case this was an incompatibility of some sort with RHEL 9. All good.
- Christophe took the upgrade initramfs that is failing on the customer's side and booted a RHEL 9 VM with it. It worked perfectly.
- The customer mentioned they have an EDR which they disable during the upgrade.
- we retrieved the rhel 8 post leapp initramfs and are able to decompress it manually and boot with it
- we retrieved the literal kernel images noted and are able to boot fine with either
- is cloned by
-
-
- Closed
-
- links to
-
RHBA-2025:148352
grub2 update
