Description of problem: Using a dual-boot (Windows7/Mageia-1) system using Intel ICH10R chipset. Up to release of Mageia-2 (including Mandriva 2009, 2010 and Mageia-1), the RAID array was detected by the installer and it offered to activate it for the install operation. It also worked correctly in Mageia3 Alpha 1 and Alpha 2, but starting with Alpha 3 and continuing with Beta 1 the installer does not recognize the RAID and instead immediately goes to the partitioning step (after detecting the Windows partition size) with the first member disk selected by default. This is the the same condition that prevented me from being able to upgrade to Mageia 2 - after the install, the system cannot mount the RAID volume to continue booting and instead panics. It also causes the array to lose synchronization as it is writing directly to the member disks instead of the virtual RAID volume. Cannot use software RAID since system is dual-boot, anyway it worked perfectly in the past for several years in this configuration. Version-Release number of selected component (if applicable): Mageia3-Alpha3 and Mageia3-Beta1 (also Mageia2) How reproducible: Steps to Reproduce: 1. Start install with system using BIOS RAID-1 2. Installer loads "IDE" driver correctly. 3. Installer does not detect / activate RAID array when reaching the paritioning step.
Please run again the installer up to the partitioning step, then: - plug an USB key, - go to the second text console (press alt+ctrl+F2) - run the "bug" command - attach to this bug report the report.bug.xz file you'll then find on your usb key.
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaud
Created attachment 3287 [details] output from "bug" utility Attaching bug report (note, the utility produced an uncompressed "bug.report" file, so I compressed it manually).
(In reply to comment #0) > > Cannot use software RAID since system is dual-boot, anyway it worked perfectly > in the past for several years in this configuration. > > Version-Release number of selected component (if applicable): > Mageia3-Alpha3 and Mageia3-Beta1 (also Mageia2) > Adding MGA2TOO to the Whiteboard, then. removing the NEEDINFO keyword, because the demanded info was given. The same issue on a Mageia 2 system was reported by Dick Gray https://www.mageia.org/pipermail/mageia-discuss/2013-January/009038.html @ Thierry Do you want Dick's report.bug, too?
Keywords: NEEDINFO => (none)CC: (none) => marja11Whiteboard: (none) => MGA2TOO
Yes.
CC: (none) => pterjan
@Pascal, it looks like fsedit::handle_dmraid() didn't got any VG from dmraid when calling fs::dmraid::vgs() I would have suspect a missing udev rule, but it worked in mga2 & mga3a1m @Steve: by the way if you could attach /root/drakx/report.bug.gz from mga2 install, it could help to compare working & non working installer logs.
CC: (none) => mageia
@Coling: though Dick says it didn't worked for him with mga2, so udev may be a culprit. Me wonders if we should not include kpartx & /etc/udev/rules.d/kpartx.rules in drakx as kpartx is required by dmraid. Me wonders also about /usr/lib64/device-mapper/ When Colin introduced udev in drakx, I noticed we lacked support for LVM & soft raid and so I added the needed rules but maybe dmraid needs a couple more? I just don't have the hardware to test... Or dmevent_tool & dmeventd (was added as the same time as kpartx by thomas) http://svn.mandriva.com/viewvc/packages/cooker/dmraid/current/SPECS/dmraid.spec?r1=508509&r2=508508&pathrev=508509
CC: (none) => bluca
MGA2 install / upgrade failed for me, both from DVD and as an on-line upgrade from MGA1. I had to restore my MGA1 system from backup in order to have a useable system after either attempt. I guess I wasn't clear about this. I should mention that there were no volumes in /dev/mapper (other than control) after the failed MGA2 tried to boot. I thought that there must be some problem with the initrd created during the install. Just FYI, I recently tried the LinuxMint-14 live DVD and it did activate the RAID volumes (the /dev/mapper/isb_* volumes were present); they could be mounted and appeared to work normally. (Though from what I've read Mint can't automatically install to BIOS RAID and you have to pause and chroot to get it to work.)
uhm Intel RST should be activated using md rather than dmraid. looking at debug log from comment #2 i see: <6>[ 25.289226] md: bind<sda> <6>[ 25.566127] md: bind<sdb> <6>[ 25.577792] md: bind<sda> <6>[ 25.577853] md: bind<sdb> <4>[ 25.578134] md: personality for level raid1 is not loaded! why is the raid1.ko module not loaded, do we need to preload it? also mdadm needs the mdmon binary in order to properly activate the array dmraid can also be used for Intel RST, but it needs the dmraid-event package in order to activate the raid.
@luca: For dmraid-event, does it needs only the lib or dmevent_tool too? Note that this was working before switching to udev, so we can include more stuff in stage2 but the odds're high we're missing some stuff for udev instead. Especially for the not loaded raid1 module? For dmevent, we currently include libdmraid-events-isw.so but not /usr/lib64/device-mapper nor /sbin/dmeventd nor /sbin/dmevent_tool. Should we? @steve: comment #7 contradicts with comment #0 (broke before mga2 or mga3a3). Does it work if you manually run "modprobe raid1" before the partition step? I'm uploading a new stage2 with mdmon, please reports if it helps when it lands on your preferred mirror.
CC: (none) => bernard.pidoux
Ping: Various questions outstanding. This concerns installer version(s) which will not be fixed anymore, but perhaps still present in current installer? (5beta1) When answered, pls do remove 'NEEDINFO'. When still current pls change whiteboard to '5beta1' (or higher). Else, it ought to be closed as OLD.
Keywords: (none) => NEEDINFO
This is fixed as of Mageia 5 RC
Status: NEW => RESOLVEDResolution: (none) => FIXED