Bug 15791 - RAID 0 can't add 5th partition
Summary: RAID 0 can't add 5th partition
Alias: None
Product: Mageia
Classification: Unclassified
Component: Installer (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
: High major
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
Keywords: 6sta1.5
Depends on: 15665
  Show dependency treegraph
Reported: 2015-04-29 01:13 CEST by Tony Blackwell
Modified: 2016-10-10 17:38 CEST (History)
6 users (show)

See Also:
Source RPM:
Status comment:

RAID 0 problems; early attempts (2.55 KB, text/plain)
2016-07-14 14:14 CEST, Tony Blackwell
report.bug at failed partitioning (130.37 KB, text/plain)
2016-07-14 14:21 CEST, Tony Blackwell
further progress on RAID install (5.74 KB, text/plain)
2016-07-15 01:06 CEST, Tony Blackwell
report2.bug dump at time of triggering this bug (160.04 KB, text/plain)
2016-07-21 14:23 CEST, Tony Blackwell

Description Tony Blackwell 2015-04-29 01:13:35 CEST
Description of problem:

(to save space here, see description late in closed bug 13592 as to how I set up RAID 0 on this UEFI ASUS UX301 dual SSD laptop.  The problem during install was that on having partitioned the RAID0 drive, it then failed. 
'failed to add partition #5 on /dev/mapper/isw_bbacjebecf_vol0'  

I have an initial 300Mb EFI partition, then 3 further partitions of around 80Gb each.  My attempted partitioning had been to next have a large encrypted partition, then swap at the end of the RAID0.

I got it to install and reboot having just the EFI and 3 further partitions each of 80Gb, followed by empty disk space with no swap.  From the working system, I am still unable to create a swap or any other type of partition in the considerable spare space in RAID 0, volume 0.

Version-Release number of selected component (if applicable):

How reproducible: always

Steps to Reproduce:
See the process I went through in bug 13592 comment 27 as I recall.


Steps to Reproduce:
Comment 1 Thierry Vignaud 2015-04-29 08:59:17 CEST
We don't really support partitionable RAIDs yet
Comment 2 Tony Blackwell 2015-04-29 13:13:57 CEST
Ah well, its maybe surprising how far I got then.

Since then, some indirect new info of a sort.
1.  I tried to install Win8.1 from an OEM memory stick that would accept my hidden-in-UEFI serial number.  It could see the existing partitions within RAID vol0, but reported it was unable to install as it had some issue with what was there.

I tried again, from win8.1 deleted all the partitions, then let it install as on a new system.  Worked.  This was a step forward, as previously Win8.1 still saw separate sda and sdb despite the RAID flag being set in UEFI.  Something must have been written to the 2 disks by my Mageia 5 RC installation which allowed Win8.1 to install and work

I've since run an M5 x86_64 UEFI install.  Deleted some little win8.1 partition of 128Mb next to the 100Mb EFI, and combined them as a bigger EFI.

Note that the installer didn't renumber the partitions - so there was one missing.

Rebooted Classic DVD in rescue mode.  By default it didn't recognise the RAID, (had only 'control' in /dev/mapper) but after running dmraid -ay there was then an isw_xxxxx_vol0 in there as well, and gdisk could access the win8.1-created partitions inside vol0.  Running 'sort' in gdisk renumbered the partitions (and may have thereby killed the win8.1, but hey, its just a test...)

Re-ran the M5 installation, and curiously this time, building on what the Win8.1 had done, there was no trouble adding all the extra partitions I wanted during install. (added 2 ext4's, a big linux native and a swap with no issues.)  New system rebooted and ran fine.

So, it looks as if there is something buggy in the way we set up partitions inside the RAID0 volume using Classic M5 RC.  I'll take your advice that it's not been addressed so far, but should probably keep this bug open as the 'use case' of installing M5 into spare disk space on a pre-existing MS-Win dual-HD RAID system is not unheard of.
Comment 3 Tony Blackwell 2015-05-27 15:20:33 CEST
This is still valid immediately pre-release.  

for Errata
Installation onto a new bare RAID 0 system may have problems if you try to  create a 5th partition although works normally with fewer partitions.  The work-around is that the classical installer can happily work with pre-existing MS-Windows partitions within a RAID 0 drive, allowing manual resizing of the main windows partition, deleting un-needed Windows partitions (e.g. a drive 'D') and replacing them with linux partitions, at and above a total of 5 partitions.  Note that the MS-Windows must be completely and cleanly shut down first.
Comment 4 Thierry Vignaud 2015-05-27 15:42:20 CEST
That has nothing to do with 5th partition IMHO.
The issue is with adding partitions to a partitionned array, IMHO.
WDYT Thomas?
Comment 5 Tony Blackwell 2015-05-27 15:47:51 CEST
Clarification: it manifest as inability to create more than 4 partitions in a de-novo Mageia-5 RAID 0 array.  There was no problem adding more than 4 partitions in an existing (created by MS-Win) array.
Comment 6 Tony Blackwell 2015-05-27 15:50:52 CEST
... but comment 4 is probably valid in that this bug suggests the whole of our partitioning RAID 0 is buggy.
Comment 7 Thomas Backlund 2015-05-27 16:13:09 CEST
Partitioning on dmraid managed raid devices should work... It atleast used to back when I used them...

Since it seems a specific <=4 is ok, but the 5th fails, I wonder if we are actually doing the partitioning (or checking) in mbr format with only primary ones, meaning we hit mbr max 4 primary...

And as it works on pre-partitioned disc where Win does switch to extended partitioning when it hits >3 partitions, we can easily add partitions in the extended section
Comment 8 Thierry Vignaud 2015-05-29 13:45:51 CEST
Could you attach the installer log for that error?
Comment 9 Tony Blackwell 2015-05-29 14:31:52 CEST
I'm sorry that log is lost since I've re-installed after letting Windows set up the initial disk partitioning.  At the moment I'm overseas with the 'test' laptop as my only machine, so will have to wait to mid June before I can assist further with this.
 Just remind me how to get the bug report at that early point in the install, before anything is written to disk?
With thanks,
Comment 10 Thierry Vignaud 2015-05-29 15:14:29 CEST
Just plug an USB key, go to tty2 and type "bug" and voila.
You then have a nice "report.bug" file on your USB key (or floppy...)

So you can just start the installer, just try to add a new partition w/o touching anything else then run the "bug" command once the installed failed.
Comment 11 papoteur 2015-05-31 16:22:45 CEST
Added in Errata.

Suppress it if the bug is solved.
Comment 12 Nic Baxter 2016-01-04 03:25:57 CET
Tony, anything further?
Comment 13 Tony Blackwell 2016-04-21 22:02:38 CEST
I see the ball's in my court.  I've been delaying testing in M6 as would have to rely on good graces of manufacturer to re-image disks to recover.
Has anything changed to improve my chances of success?
Any hints on the fine detail of how to dd my current setup to aid recovery?
(Have 2 RAID0 SSD's in very fast laptop).
Comment 14 Marja van Waes 2016-06-28 21:03:42 CEST
(In reply to Tony Blackwell from comment #13)
> I see the ball's in my court.  I've been delaying testing in M6 as would
> have to rely on good graces of manufacturer to re-image disks to recover.
> Has anything changed to improve my chances of success?
> Any hints on the fine detail of how to dd my current setup to aid recovery?
> (Have 2 RAID0 SSD's in very fast laptop).

Please ask on dev ml (I don't have the slightest idea :-/ ).

Closing this report as OLD, since the needed information is still missing.

Please reopen if the issue is still valid for Mageia 6sta1 or 6dev1 installs, and attach the needed logs.
Comment 15 Thierry Vignaud 2016-06-29 11:33:44 CEST
I think it's still valid though we need for someone to give us logs when the bug happens, aka:
- plug a USB keu
- go to tty2
- run the "bug" command
  => this makes the installer to dump its logs to the report.bug file
     on the USB key
- attach this report.bug file here (not paste)
Comment 16 Marja van Waes 2016-07-13 18:47:41 CEST
(In reply to Thierry Vignaud from comment #15)
> I think it's still valid though we need for someone to give us logs when the
> bug happens, aka:
> - plug a USB keu
> - go to tty2
> - run the "bug" command
>   => this makes the installer to dump its logs to the report.bug file
>      on the USB key
> - attach this report.bug file here (not paste)

@ Tony

Could you do that?
Comment 17 Tony Blackwell 2016-07-13 23:08:07 CEST
Sync'ing RC now, will do it today
Comment 18 Tony Blackwell 2016-07-14 14:14:50 CEST
Created attachment 8175 [details]
RAID 0 problems; early attempts

I busted up my RAID to test this.
The results speak for themselves.
at step 41 its late - enough for tonight.

RC is not ready.
Comment 19 Tony Blackwell 2016-07-14 14:18:18 CEST
see the attachment for what I actually did - to unwieldy to paste in here.
Comment 20 Tony Blackwell 2016-07-14 14:21:53 CEST
Created attachment 8176 [details]
report.bug at failed partitioning
Comment 21 Tony Blackwell 2016-07-15 01:06:28 CEST
Created attachment 8182 [details]
further progress on RAID install

See the long attached text file.
Managed to get working RAID0 install by first booting Classic x86_64 in recovery mode and setting up partitions manually with gdisk.  Didn't see the 5th partitions error.

I'll detour ti see whether I can re-install Win8.1 at this point, then tear all the partitions down and try it all via just the installer, which is where the '5th partition' problem arose with M5.

More news shortly!
Comment 22 Tony Blackwell 2016-07-21 14:23:28 CEST
Created attachment 8218 [details]
report2.bug dump at time of triggering this bug

Have now conclusively demonstrated this bug for M6 RC:

HW: ASUS UX301L laptop, EFI, dual SSD each 256 Gb

Software: M6 x86_64 RC USB

Laptop starting state: Win 81 and M6 installed on RAID 0 array.

Test procedure:
1. Boot into EFI, change SATA mode selection from RAID0 to AHCI, save
2. Reboot into M6 RC in rescue mode -> Console
3. (ls /dev/mapper: just had the 'control' file.)
4. Wipe any left-over metadata from disks: mdadm --zero-superblock /dev/sda
5. same for sdb; both completed silently (meaning there _was_ some metadata there).
6 reboot into EFI, reset SATA to RAID
7. Reboot into M6 installation.
8. When it pauses at 'choose a language', go to # prompt at F2
9. Create a RAID container with 'mdadm -C /dev/md/imsm /dev/sd[a-b] -n 2 -e imsm'
Response: 'mdadm: /dev/sdb appears to be part of a raid array:
	level=raid0 devices=0 ctime=Thu Jan 1 00:00:00 1970'
mdadm: metadata will over-write last partition on /dev/sdb.
Continue creating array?
10. y
11. Response: 'mdadm: container /dev/md/imsm prepared.'
12. Create the RAID 0 volume /dev/md/vol0 within this imsm container:
mdadm -C /dev/md/vol0 /dev/md/imsm -n 2 -l 0
13. Response: 'mdadm: array /dev/md/vol0 started.'
14. See where we are at:  'mdadm -E -s -config=mdadm.conf > /etc/mdadm.conf'
resulting file of form:
ARRAY metadat-imsm UUID=(the string for that UUID)
ARRAY /dev/md/vol0 container=(same string as UUID)      member=0      UUID=(different UUID string)
15: can't go on at this point; it thinks partition tables are corrupt: so reboot.
16. on reboot, restart install from USB.  This time, after accepting licence, get popup
'BIOS software RAID detected on disks /dev/sdb /deb/sda. Activate it?'
17 y
18 Choose install (rather than upgrade the old M6 it sees after the RAID0 was rebuilt)
19.  Realise this isn't going to test anything, as all the old RAID0 partitions are there.
20. Delete them all.  For test realism, reboot, activate the RAID array when prompted, custom disk partitioning.
21.  Select mapper/isw_ggceccijf_vol0 as the RAID array to be partitioned.
22. It thinks there is a 4Mb EFI system partition at the start of the disk; delete it.
23.  try to re-create something like the partitions that existed previously:
400Mb, type needs to be 2700, basic data partition.  M6 install graphics don't seem to allow this level of choice; pick Fat32 for now.
100Mb, type EFI system partition, give it mount point of /boot/EFI
128Mb, of type Compaq Diagnostics
29.34Gb, of type NTFS-3G (main Windows partition)
100Gb, of type ext4
24.  Proceeded from there, accepted write-to-disk.
25: failure; bug demonstrated.
'An error occurred.
INTERNAL ERROR: unknown device mapper/isw_ggceccijif_vol0p5

see attached reoport2.bug
Comment 23 Tony Blackwell 2016-07-25 00:16:32 CEST
Anything I can do to help with this?  This bug fell off the back of the stack with M5.  I'm keeping the laptop devoid of anything useful at the moment ready for re-testing of installation.

Note You need to log in before you can comment on or make changes to this bug.