-
Notifications
You must be signed in to change notification settings - Fork 247
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Software RAID: IMSM support #2702
Conversation
Great, thanks for the contribution! I am currently in the process of learning how to use IMSM on an actual IMSM capable hardware, but I haven't written any code yet. I am going to try your code in IMSM test setup, hopefully soon. |
See also RHBZ 2017107 for reproducing without any IMSM hardware (just some hack is required to let the system boot). |
The current code was badly failing with Software RAID having Containers, such as IMSM.
@rmetrich Could you do me a favour and also post here your output of
on your test system - ideally the one where you posted your "Example with this patch" I like that |
Actually I don't have it anymore, did modify the configuration for wider testing ...
|
To me as non RAID expert the lsblk output seems
should create a container of sdc sdd sde sdf |
Right, actually there was a disk renaming after I rebooted, explaining the difference (sdX naming is not reliable). |
Ah - "reboot" explains it all. Unfortunately it seems the NAME output column of E.g. on my homeoffice laptop with LUKS (excerpt)
where one can see the /dev/mapper/ symlinks as NAME
versus on a QEMU/KVM test system with RAID1 (excerpt)
where one cannot see the stable /dev/md/ symlinks as NAME
but only the unstable kernel device nodes :-( |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rmetrich looks good to me. Seems a significant improvement of the current code.
Thanks.
@pcahyna |
@jsmeix sorry for the delay, it took me some time to do proper tests (backup+restore) on an actual IMSM-capable hardware. Here are the results (not with the current code though - I backported the change to ReaR 2.6 in RHEL 8.5).
So, first problem, ReaR is not able to execute efibootmgr to set the RAID bootable. (This looks similar to #2595 and I can fix this separately, because I fixed that issue as well). After fixing the boot order in UEFI and rebooting, the machine is stuck in initrd and drops to the emergency shell because it is not able to find its LVM storage. Investigation reveals that the recovery process has changed the MD UUIDs, but the GRUB command line and Not sure about the second problem - ReaR should be able to patch configuration files to solve it, but shouldn't it restore the arrays with the same UUIDs in the first place to avoid the problem from the start?
|
I never tested software RAID having containers such as IMSM From plain looking at the code in layout/prepare/GNU/Linux/120_include_raid_code.sh
So you should run "rear -D recover" to see how that code Before you run "rear -D recover" you may By the way:
I think "device" in 120_include_raid_code.sh is "raiddevice" in "man mdadm" and |
@jsmeix thanks for looking so quickly and for the warning about the code in |
@pcahyna |
See #2714 (comment) |
Additionally show UUID in 'lsblk' output of the original system as comment in disklayout.conf to make it easier to compare UUIDs of the original system with what was recreated, cf. "... shouldn't it [ReaR] restore the [RAID] arrays with the same UUIDs ...?" in #2702 (comment) and #2714 (comment)
So, I looked at the debug log and ReaR is not doing anything weird: it merely passes the right
|
@pcahyna Regarding how to deal with such kind of issues in ReaR I would try to add a test in layout/prepare/GNU/Linux/120_include_raid_code.sh Optionally - but only as far as possible with reasonable effort - I would In general the user must test if "rear recover" works for him |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See
#2702 (comment)
Sure, feel free to close this, I have no time to follow all the details :) |
@rmetrich |
New layout/recreate/default/220_verify_layout.sh Verify RAID devices are actually recreated with the UUIDs in disklayout.conf because mdadm silently ignores this option when creating IMSM arrays (both containers and the volumes inside them) and picks a random UUID cf. #2702 (comment)
Overhauled RAID code based on #2702 that is about initial software RAID IMSM support i.e. with the changes in that pull request: Completely overhauled layout/save/GNU/Linux/210_raid_layout.sh - no longer a subshell that appends all stdout to disklayout.conf but explicit append to disklayout.conf where needed to be safe against accidental things written to disklayout.conf - handle each mdadm option in one place i.e. parse and prepare output - handle options ordered by importance, mandatory first, then optional ones - basic tests that mandatory options are syntactically valid plus Error if not. Overhauled layout/prepare/GNU/Linux/120_include_raid_code.sh - the FEATURE_MDADM_UUID code is meanwhile obsolete because all mdadm versions in supported ReaR Linux distributions support '--uuid'. New layout/recreate/default/220_verify_layout.sh to verify if RAID devices are recreated with the UUIDs in disklayout.conf because mdadm silently ignores this option when creating IMSM arrays (both containers and the volumes inside them) and picks a random UUID cf. #2702 (comment) Support user specified DISKS_TO_BE_WIPED to mitigate #2715 see the DISKS_TO_BE_WIPED description in default.conf
Additionally show the filesystem LABEL in the 'lsblk' output of the original system as comment in disklayout.conf to make it easier to understand subsequent data in particular for RAID where the array name is shown as LABEL in 'lsblk' for example like "/dev/sda ... linux_raid_member any:raid1sdab" - see also "one cannot see ... /dev/md/ symlinks as NAME ... /dev/md/raid1sdab -> ../md127" in #2702 (comment) and see also 1a8a88c
The current code was badly failing with Software RAID having Containers, such as IMSM.
Relax-and-Recover (ReaR) Pull Request Template
Please fill in the following items before submitting a new pull request:
Pull Request Details:
Type: Enhancement
Impact: Normal
Reference to related issue (URL):
How was this pull request tested?
On RHEL8 with Upstream ReaR, by creating fake IMSM arrays on a QEMU/KVM
Brief description of the changes in this pull request:
When encountering an IMSM array, to be able to recreate it the
mdadm
command line is somehow different.In particular the volumes inside the container have only the container as parent, and size of the array can be specified.
Finally, because the normal partitions are also seen, it's necessary to wipe the devices prior to setting it up.
Reproducer (a QEMU/KVM)
Create a QEMU/KVM with additional SCSI disks and allocate an ID to each disk.
Create a IMSM container
Create volumes in the container (size is optional)
Amend
/etc/rear/local.conf
Execute
rear mkrescue
Restore the ISO on a clone system
With current code, the restore will fail due to missing
raid-devices
option for the container,wipefs
issues and badly formed lines for the Volumes containing raw devices making the Container, whereas the Container device should be used.Example with this patch: