All 3 disks have 465.76 GB and have a main extended partition with the same size (i.e. /dev/sda1 465.76 GB - Extended)
/dev/md0 contains opensuse13.1 (the running server)
/dev/md1 is for storage
/dev/md2 contains Leap 42.3 (it will be the new server) with the bootloader Grub2 (it starts opensuse 13.1 as default system)
/dev/md3 for swap
Before switching from opensuse 13.1 to Leap42.3 I want to :
change form old legacy partition scheme (MBR) to GPT
shrink /dev/md1 (i.e. 100 GB) for having room for 1 dedicated boot partition (i.e. 300 MB) and for another data partition (remaining space)
recreate for all partitions RAID1
install on new /boot partition Grub2 (now is on /dev/md2)
At the end of this operations I would have, obviuosly, a runnable opensuse 13.1 and Leap 42.3 without loosing any data …
For 1) I know I’ve to use gdisk (I’ve used in the past on a single disk), but I don’t know what I’ve to do with RAID …
For 2) I know the way of resizing/moving partition, bus as for 1) I don’t know what I’ve to do with RAID …
For 3) Maybe I’ve to use mdadm -a …
For 4) I think I’ve to use grub2-mkconfig -o /boot/grub2/grub.cfg but I’m not so sure
For all of 4 points I also think I’ve to boot with a rescue image …
I hope someone can give me the correct sequence of operations.
First, please in the future use CODE tags around copied/pasted computer text in a post. It is the # button in the tool bar of the post editor. When applicable copy/paste complete, that is including the prompt, the command, the output and the next prompt. This to make the computer text better interpretable for others.
Then, you have whole story about how your disks are partitioned, but you better post the output of
fdisk -l
Posting computer output spares you a lot of talking/typing and make things better understandable for others.
I have no idea why you want to switch from MBR to GPT partitioning. While, from your description, it seems that your present MBR partitioning is a bit unusual (your four extended partitions in an extended partition spanning the whole disk could also have been done in just four primary partitions), but there is nothing wrong with it.
But, because you want to re-partition in ay case, my personal solution would be to offload all data, partition to my wishes, create MD RAID devices to my wishes, create file systems to my wishes and the restore the data. Because that is the most straightforward approach (building up from scratch) and it will leave no artefacts from the old situation.
It will be clear that a good, written down plan must be the base of such an action. But that is also the case if your go for any other scenario.
Hi Henk,
thank for your reply and sorry for having not used CODE tags…
This is the requested output :
**fdisk -l**
Disk /dev/sda: 500.1 GB, 500106780160 bytes, 976771055 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Identificativo disco: 0x10ae4686
Dispositivo Boot Start End Blocks Id System
/dev/sda1 * 2048 976769023 488383488 f W95 Ext'd (LBA)
/dev/sda5 4096 83890175 41943040 fd Linux raid autodetect
/dev/sda6 83892224 167778303 41943040 fd Linux raid autodetect
/dev/sda7 167780352 184557567 8388608 fd Linux raid autodetect
/dev/sda8 184559616 976769023 396104704 fd Linux raid autodetect
Disk /dev/sdb: 500.1 GB, 500107862016 bytes, 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Identificativo disco: 0x000b7ad1
Dispositivo Boot Start End Blocks Id System
/dev/sdb1 * 2048 976773167 488385560 5 Extended
/dev/sdb5 4096 83890175 41943040 fd Linux raid autodetect
/dev/sdb6 83892224 167778303 41943040 fd Linux raid autodetect
/dev/sdb7 167780352 184557567 8388608 fd Linux raid autodetect
/dev/sdb8 184559616 976773167 396106776 fd Linux raid autodetect
Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes, 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk label type: dos
Identificativo disco: 0x0005deb1
Dispositivo Boot Start End Blocks Id System
/dev/sdc1 * 2048 1953525167 976761560 5 Extended
/dev/sdc5 4096 83890175 41943040 fd Linux raid autodetect
/dev/sdc6 83892224 167778303 41943040 fd Linux raid autodetect
/dev/sdc7 167780352 184557567 8388608 fd Linux raid autodetect
/dev/sdc8 184559616 977283071 396361728 fd Linux raid autodetect
/dev/sdc9 977285120 1953503231 488109056 83 Linux
Disk /dev/md0: 42.9 GB, 42949541888 bytes, 83885824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/md3: 42.9 GB, 42949541888 bytes, 83885824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/md1: 405.6 GB, 405611020288 bytes, 792209024 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk /dev/md2: 8589 MB, 8589869056 bytes, 16777088 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
I have no idea why you want to switch from MBR to GPT partitioning.
I know it’s not really necessary to change from MBR to GPT but it seems to me the right moment while I resize/move partitions.
But, because you want to re-partition in ay case, my personal solution would be to offload all data, partition to my wishes, create MD RAID devices to my wishes, create file systems to my wishes and the restore the data. Because that is the most straightforward approach (building up from scratch) and it will leave no artefacts from the old situation.
I agree with you : this is the easiest way …
It will be clear that a good, written down plan must be the base of such an action. But that is also the case if your go for any other scenario.
Normally I try to stay safe and have always a running system not upgrading it with new distribution but installing new distribution in a separate root partition.
When everything on new distribution is running fine simply I start to use it (but I’m still able to boot on the old distribution in case of necessity).
Following this my own personal way of operate I can spend many hours for reinstalling / configuring Leap 42.3 but I can’t keep off for to much time the running server (acceptable downtime of 2 - 3 hours) …
That is about the same as I do. Having a spare / and /home for testing and later switching. But what you now want is something different.
Oh and about the switch to GPT. IMHO you should not see this a s a goal that should be reached fore each and every disk that is MBR partitioned now. MBR disks will function and be accepted by systems for a long, long time to go.
BTW, just before I go to sleep, I get the idea that it is probably NOT a good idea to change the disks to GPT. After all the BIOS also has some basic knowledge about partitioning and it will probably not understand your GPT (and thus not even boot).
I assume that when your system was delivered with a BIOS (or UEFI aware firmware) that understands GPT, it would have had GPT disks from the very beginning.