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

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.