Description of problem: boot-error after installing online-updates (encrypted swap on intel-fake-raid) Version-Release number of selected component (if applicable): NAME="Mageia" VERSION="8" Following setup: DELL Optiplex 9020 with Intel "Fake-Raid" and encrypted filesystems for /home /usr/local und swap. Installing Mageia8 has no problems and systems boots up after entering passphrase (which is the same for all fs). After installing online-updates boot fails with following message: dracut: luksOpen /dev/sda8 luks-3768c443-798a-4a39-8e57-3dccc0ce8325 ... dracut: Scanning for dmraid devices isw_dgfdfhfccf_ARRAY0 dracut: Found dmraid sets: dracut: isw_dgfdfhfccf_ARRAY0 dracut: Activating isw_dgfdfhfccf_ARRAY0 device-mapper: table: 252:1: mirror: Device lookup failure device-mapper: ioctl: error adding target to table dracut: ERROR: removing part 8 from /dev/sda: Device or resource busy dracut: dracut: BAID set "isw_dgfdfhfccf_ARRAY0" was not activated dracut: ERROR: device "isw_dgfdfhfccf_ARRAY0" could not be found dracut Warning: Could not boot. dracut Warning: /dev/mapper/isw_dgfdfhfccf_ARRAY0P1 does not exist dracut Warning: /dev/mapper/isw_dgfdfhfccf_ARRAY0P5 does not exist After a while the system enters debug-shell. It seems, that opening sda8 for swap breaks the raid, because when entering the dracut shell and "cryptsetup luksClose /dev/mapper/luks-3768c443-798a-4a39-8e57-3dccc0ce8325" followed by "dmraid-scan" and "STRG-D" the system boots up.
Created attachment 13383 [details] /run/initramfs/rdsosreport.txt with rd.debug kernel-option
Does it just happen once and is ok after that, or does it now happen every boot? It's likely from bug 29884, It's reference, https://www.openwall.com/lists/oss-security/2022/01/13/2 has ... ===================== The former reencryption operation (without the additional digest) is no longer supported (reencryption with the digest is not backward compatible). You need to finish in-progress reencryption before updating to new packages. The alternative approach is to perform a repair command from the updated package to recalculate reencryption digest and fix metadata. The reencryption repair operation always require a user passphrase. An alternative fix is to use the newly introduced configure option --disable-luks2-reencryption to completely disable LUKS2 reencryption code. ===================== Assigning to kernel and drivers team.
CC: (none) => davidwhodginsAssignee: bugsquad => kernel
For further information please also see the thread in the german forum: https://forums.mageia.org/de/viewtopic.php?f=7&t=3942 To summarize, either doing swapoff -a before regenerating initrd after updates or using 'dracut -f --omit "resume"' enables to boot normally, so this might be an issue from dracut handling encrypted swap on an Intel RAID. OP mentioned he does have encrypted swap etc. on another box without the Intel RAID and it works fine there. FWIW, another issue seems to be that adding 'omit_dracutmodules+=" resume "' to /etc/dracut.conf.d/99-disable-resume.conf seems to be read by dracut, but it does not have the same effect as 'dracut -f --omit "resume"' (although it should.)
CC: (none) => doktor5000
(In reply to Dave Hodgins from comment #2) > Does it just happen once and is ok after that, or does it now happen every > boot? This happens on every boot. A workaround is to generate an initrd like Florian told.
do you have /etc/dracut.conf.d/51-mageia-resume.conf if you comment out the add_device* line there, does it work automatically then when regenerating initrd without having to pass '--omit "resume"'
(In reply to Thomas Backlund from comment #5) > do you have /etc/dracut.conf.d/51-mageia-resume.conf > > if you comment out the add_device* line there, does it work automatically > then when regenerating initrd without having to pass '--omit "resume"' The file exists but is empty.
We stopped supporting Mageia 8 almost 8 months ago https://blog.mageia.org/en/2023/12/30/mageia-8-end-of-life/ That means we also stopped fixing Mageia 8 bugs and that this bug report needs to be closed, regardless of whether it was fixed for Mageia 8 or not. If this particular bug did not get fixed for Mageia 8, then we do regret that. If this issue is still present in Mageia 9 or cauldron, then please reopen this report, write a comment and adjust the "Version:" field. If you are not yet a member of one or our teams, then please consider becoming one. https://wiki.mageia.org/en/Contributing Mageia is a community project, meaning that we, the users, make Mageia together. The more active contributors we have, the more bug reports will get fixed. Besides, being active in a team can be very rewarding. It was and is certainly rewarding to me :-D
Resolution: (none) => OLDStatus: NEW => RESOLVED