GPT partitions and dmraid

Xeo84 · 2013-08-31 04:52:30

I am installing arch on an Aspire S7-191.
I've used dmraid to make my raid visible on /dev/mapper/ I created two new partitions for home and root (alongside the windows 8 partitions and the efi one) with cgdisk.
Now I am stuck, how can I format the partitions? dmraid wiki only explain how to do with MBR but not UEFI.
Any hints?

thanks.

WonderWoofy · 2013-08-31 06:19:52

I think that by MBR, you really mean ms-dos partitioning, and by UEFI you are referring to GPT. But I am really not sure. If I am right though, I think you are confused about what is what. Partitions are the containers that the filesystem goes into. What is typically referred to as "formatting" is the creation of a new filesystem within a partition.

So your question "..how can I format the partitions?" doesn't really make any sense with "dmraid wiki only explain how to do with MBR but not UEFI."

You would recreate the filesystem just the same no matter what partition table type you are using. So it would be mkfs.ext4 for ext4 filesystems, mkfs.btrfs for btrfs, etc.

If you are asking about the partitions themselves, then you are probably asking what tool to use other than fdisk. Fdisk has some experimental support for GPT (which actually seems to work just fine BTW). But you would use gptfdisk (gdisk) or parted to do that part of it.

Xeo84 · 2013-08-31 11:29:52

I can't use mkfs.ext4 because I have to specify the partition which I don't know because I am using a fake raid.

mkfs.ext4 /dev/sda1 would format the first partition, but sda1 it's not a partition, I have sda and sdb in a raid0 so I used dmraid to create /dev/mapper/Volume0.

And yes, I don't know why I've written UEFI in the last line of the post I was referring to GPT.

So the problem itself it's not GPT but the fakeraid.

srs5694 · 2013-08-31 16:09:56

With software RAID, you create filesystems on the RAID devices, not on the partitions. Thus, you'd use mkfs.ext4 on /dev/mapper/Volume0 (or whatever your RAID device is called).

WonderWoofy · 2013-08-31 18:42:31

Xeo84 wrote:

I can't use mkfs.ext4 because I have to specify the partition which I don't know because I am using a fake raid.
mkfs.ext4 /dev/sda1 would format the first partition, but sda1 it's not a partition, I have sda and sdb in a raid0 so I used dmraid to create /dev/mapper/Volume0.
And yes, I don't know why I've written UEFI in the last line of the post I was referring to GPT.
So the problem itself it's not GPT but the fakeraid.

See now this is much much more clear. In the original post, there was not even any indication that this might have been the problem.

But srs5694 is right, so just proceed with that advice.

FWIW, I think that Linux's regulat software RAID, mdadm is pretty fantastic. I have never actually had the opportunity to try dmraid (fake RAID), but I think even if my machine were capable, I would still use mdadm. If nothing else, it just seems to be the more common choice, so you would be able to find more users in a position to help you. I am pretty sure that mdadm now supports fake RAID these days as well, and from what I have heard, dmraid seems to get more or less just maintenance updates, while mdadm is actively developed.

Oh, and the mdadm page is much better than the dmraid page.

Xeo84 · 2013-08-31 22:53:21

srs5694 wrote:

With software RAID, you create filesystems on the RAID devices, not on the partitions. Thus, you'd use mkfs.ext4 on /dev/mapper/Volume0 (or whatever your RAID device is called).

/dev/mapper/volume0 is the entire disk, I have different partitions, in there, including the EFI and the windows one. I only want to format the root partition and the home partition.

if I run lsblk /dev/sda it says:

sda
|- Volume0

volume0 is type dmraid.
So I basicaly want to access the partitions inside volume0 to create the filesystem.

srs5694 · 2013-08-31 23:14:59

In that case you should (or can) have multiple partitions on /dev/mapper/Volume0, such as /dev/mapper/Volume0_1, /dev/mapper/Volume0_2, and so on. If these don't currently exist, then there is a way to create them, but I don't recall offhand what it is. I have a vague memory of setting this up with a udev rule at some point, but I don't recall if that's a standard udev feature or if I ran an external program triggered from udev. Perhaps somebody else will be able to provide the details, or maybe you can track it down by searching the Web with this clue in hand.

Xeo84 · 2013-08-31 23:35:20

ok thanks, reading other posts I am not sure it's possible to do the way I want to do, my laptop has the intel Rapid Storage technology which causes some issues.
I will now try to use mdadm to see if I can achieve something.

Hydranix · 2013-09-23 13:44:14

Hello Xeo84,

I've ran into this same problem with my revodrive.

I crafted together two solutions to the problem, both with advantages and disadvantages.

The first way that I got this to work, was to use the utility 'partprobe' on the device mapper volume.

# pkgfile partprobe
extra/parted

# pacman -Sy --noconfirm parted

Once 'dmraid -ay' has assembled your raid, run this command on it.

# partprobe /dev/mapper/Volume0

Your device partitions should now properly be mapped and created.

No hookers and cigars yet though, becuase how would you boot without partprobe being ran prior to mounting your root?

Create a custom hook or edit the dmraid hook. I chose to edit the dmraid hook since laerning to write hooks is still on my to-do list.

Add this line to the run_hook() function in /usr/lib/initcpio/hooks/dmraid after the 'fi'

#!/usr/bin/ash

run_hook() {
    modprobe -a -q dm-mod dm-mirror >/dev/null 2>&1
    msg ":: Activating dmraid arrays..."
    # prevent any event monitoring calls with -I
    if [ "$quiet" = "y" ]; then
        dmraid -ay -I -Z >/dev/null
    else
        dmraid -ay -I -Z
    fi
}

# vim: set ft=sh ts=4 sw=4 et:

#!/usr/bin/ash

run_hook() {
    modprobe -a -q dm-mod dm-mirror >/dev/null 2>&1
    msg ":: Activating dmraid arrays..."
    # prevent any event monitoring calls with -I
    if [ "$quiet" = "y" ]; then
        dmraid -ay -I -Z >/dev/null
    else
        dmraid -ay -I -Z
    fi
partprobe /dev/mapper/Volume0 # or use "/dev/mapper/*" but that can get hairy
}

# vim: set ft=sh ts=4 sw=4 et:

Add this line to the build() function in /usr/lib/initcpio/install/dmraid

#!/bin/bash

build() {
    add_module 'dm-mod'
    add_module 'dm-mirror'

    add_binary 'dmraid'
    add_binary 'dmsetup'
    add_file "/usr/lib/device-mapper/libdmraid-events-isw.so"
    add_file "/usr/lib/udev/rules.d/10-dm.rules"
    add_file "/usr/lib/udev/rules.d/13-dm-disk.rules"
    add_file "/usr/lib/udev/rules.d/95-dm-notify.rules"
    add_file "/usr/lib/initcpio/udev/11-dm-initramfs.rules" "/usr/lib/udev/rules.d/11-dm-$

    add_runscript
}

help() {
    cat <<HELPEOF
This hook loads the necessary modules for a dmraid root device.
HELPEOF
}

# vim: set ft=sh ts=4 sw=4 et:

#!/bin/bash

build() {
    add_module 'dm-mod'
    add_module 'dm-mirror'

    add_binary 'dmraid'
    add_binary 'dmsetup'
    add_binary 'partprobe'
    add_file "/usr/lib/device-mapper/libdmraid-events-isw.so"
    add_file "/usr/lib/udev/rules.d/10-dm.rules"
    add_file "/usr/lib/udev/rules.d/13-dm-disk.rules"
    add_file "/usr/lib/udev/rules.d/95-dm-notify.rules"
    add_file "/usr/lib/initcpio/udev/11-dm-initramfs.rules" "/usr/lib/udev/rules.d/11-dm-$

    add_runscript
}

help() {
    cat <<HELPEOF
This hook loads the necessary modules for a dmraid root device.
HELPEOF
}

# vim: set ft=sh ts=4 sw=4 et:

Run mkinitcpio -p linux (or whatever preset you use) and see that it works correctly.
Also don't forget about your edit when you update, sometimes pacman like to pwn edited system files.
a simple "chattr +i <file>" should take care of that though... possibly break pacman.. dunno really.

For the second solution this might be system specific, but worked cleaner.

For this I simple changed from GPT to the MBR, and remaking your windows partition without UEFI boot, but adding an option to chainload the windows bootmgr file into your bootloader.

Some say that UEFI will only work with GPT, but I efistub boot my kernel from a fat32 UEFI partiton on a MBR paritioned disk just fine.

My machine also doesn't work with GPT disks for booting my UEFI shell via the UEFI Menu options. Perhaps I have a weird motherboard? P8Z77-V LK Asus UEFI version 2.0+

To set up proper EFISTUB booting, you're best off using the UEFI shell with the bcfg command. It's simple but here's the command that worked for me. (it took me awhile to get it right)

Drop the linux kernel into the root of your uefi partition with the .efi extension added to it.
Also drop your initramfs.img into there as well. (and do this every time you rebuild initramfs or update kernel or make it your boot parititon and modify preset accordingly...)

FS0:
bcfg boot add 0 \linux.efi "Archlinux" 
bcfg boot -opt 0 "initrd=initramfs-linux.img ro root=<your root device>"

On that last line, add any kernel options in that you use, those are the bare minimum you can get away with.

I use my second method btw, it just worked easier for me, but the first option also worked without any trouble until a BSoD asploded my windows install and I decided to try something new.

Hope I helped a bit... I currently UEFI boot linux from a dmraid fakeraid, it works, I'm happy.

-HNx

Last edited by Hydranix (2013-09-23 13:45:17)

Arch Linux

#1 2013-08-31 04:52:30

GPT partitions and dmraid

#2 2013-08-31 06:19:52

Re: GPT partitions and dmraid

#3 2013-08-31 11:29:52

Re: GPT partitions and dmraid

#4 2013-08-31 16:09:56

Re: GPT partitions and dmraid

#5 2013-08-31 18:42:31

Re: GPT partitions and dmraid

#6 2013-08-31 22:53:21

Re: GPT partitions and dmraid

#7 2013-08-31 23:14:59

Re: GPT partitions and dmraid

#8 2013-08-31 23:35:20

Re: GPT partitions and dmraid

#9 2013-09-23 13:44:14

Re: GPT partitions and dmraid

Board footer