Systems using software raids cannot realiably upgrade to the next major version of RHEL (e.g. RHEL 7 -> 8). The problem is that such systems expects mdadm module inside the initramfs, but the upgrade initramfs doesn't include the mdadm dracut module, nor the configuration file is present when the initramfs is created. It's possible that another problems could be discovered, but this seems as the minimum change that needs to be done.
Hi has there been any progress on this? or any suggested workaround to rebuild the upgrade initramfs before doing the upgrade reboot? kind regards
Hi, no updates here - not even sure whether it will be delivered during this year as we have many others tasks with higher priority right now. Also we are not sure whether the mdadm missing in the initramfs is the only problem around software RAIDs, it's just first thing we realize it's possibly the source of some problems that have been discovered. I am not aware about any official workaround, however, I heard about some successes with software raids - but I do not know any details so I cannot say why it worked for someone and for someone not. If you want to experiment, you could possible create a custom actor that will include the mdadm dracut module into the initramfs and copy the config file, using the UpgradeInitramfsTasks msg: * https://github.com/oamg/leapp-repository/blob/8a1fec72592e6d824f53009eb0692ef743bbcb36/repos/system_upgrade/common/models/initramfs.py#L43 Here is an upstream documentation for the creation of actors: * https://leapp.readthedocs.io/en/latest/el7toel8/actor-rhel7-to-rhel8.html#creating-an-actor and here is documented how to install custom actors on the system: * https://access.redhat.com/articles/4977891#extend-upgrade-using-custom-actors But as I told, I cannot say whether this will actually work or not as we have not experimented with upgrades on systems with RAID configured.
Adding an example of actor that is producing the UpgradeInitramfsTasks msg: * https://github.com/oamg/leapp-repository/tree/master/repos/system_upgrade/common/actors/commonleappdracutmodules
Hi thank you for the links, I'm checking those. Meanwhile I can confirm that fakeraid might not be the reason of failure: just by booting with a live linux, chroot on the updated one and reinstall grub/regenerate grub.cfg fixes it and allowed it to get a test machine back working without any initrd changes
Don't have access to OAMG-4856 but can confirm that in the cases I tested found out that by just blindly patching /usr/share/leapp-repository/repositories/system_upgrade/common/actors/updategrubcore/libraries/updategrubcore.py by changing cmd = ['grub2-install', grub_dev] to something like: cmd = ['grub2-install /dev/sda ; grub2-install /dev/sdb ; grub2-mkconfig > /boot/grub2/grub.cfg'] took care of it and the system was able to properly reboot and continue the upgrade. Didn't spend much time into it to properly add a list of all actual disks along with proper grub2-mkconfig command as this was a one off test kind regards