Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #228646 > unrolled thread

RAID installation at boot questions

Back to article view | Back to linux.debian.user

Contents

  RAID installation at boot questions Charles Curley <charlescurley@charlescurley.com> - 2020-11-14 04:50 +0100
    Re: RAID installation at boot questions john doe <johndoe65534@mail.com> - 2020-11-14 08:20 +0100
      Re: RAID installation at boot questions Charles Curley <charlescurley@charlescurley.com> - 2020-11-14 20:50 +0100
        Re: RAID installation at boot questions Toni Mas Soler <antomassol@gmail.com> - 2020-11-14 23:10 +0100
          Re: RAID installation at boot questions Charles Curley <charlescurley@charlescurley.com> - 2020-11-15 01:00 +0100
        [Solved] Re: RAID installation at boot questions Charles Curley <charlescurley@charlescurley.com> - 2020-11-20 19:00 +0100

#228646 — RAID installation at boot questions

I've added RAID and two new hard drives to my desktop. The RAID appears
to work, once it is up and running. Alas, on boot it is not being
properly set up. Everything else comes up correctly.

I have two new four terabyte drives set aside for RAID. They are
partitioned, with one partition on each, and the two partitions
combined in a RAID1 array. So far so good.

On top of the RAID1 array is an encrypted device. This is where booting
seems to break down. I do not get the device files related to the
encrypted layer in /dev/mapped.

On top of the encrypted layer is an LVM2 physical volume (PV). Within
that is one logical volume, with an ext4 file system on it.

I see messages in syslog for the two drives originally in the system,
sda and sdb. However, I don't see any for the two new drives, sdc and
sdd. E.g:

systemd[1]: Started Cryptography Setup for sdb3_crypt.

I can manually complete the process after the system has booted:

cryptsetup luksOpen /dev/md0 encryptedRaid
mount /dev/mapper/hawk--vg--raid-crc2020

What do I do to automate that?

Once I have done that:

root@hawk:~# ll /dev/mapper/
total 0
drwxr-xr-x  2 root root     220 Nov 13 20:13 ./
drwxr-xr-x 22 root root    3860 Nov 13 20:13 ../
crw-------  1 root root 10, 236 Nov 13 20:08 control
lrwxrwxrwx  1 root root       7 Nov 13 20:13 encryptedRaid -> ../dm-6
lrwxrwxrwx  1 root root       7 Nov 13 20:09 hawk2017large-crc2017 -> ../dm-5
lrwxrwxrwx  1 root root       7 Nov 13 20:08 hawk--vg-home -> ../dm-3
lrwxrwxrwx  1 root root       7 Nov 13 20:13 hawk--vg--raid-crc2020 -> ../dm-7
lrwxrwxrwx  1 root root       7 Nov 13 20:08 hawk--vg-root -> ../dm-1
lrwxrwxrwx  1 root root       7 Nov 13 20:08 hawk--vg-swap_1 -> ../dm-2
lrwxrwxrwx  1 root root       7 Nov 13 20:08 sda5_crypt -> ../dm-0
lrwxrwxrwx  1 root root       7 Nov 13 20:09 sdb3_crypt -> ../dm-4
root@hawk:~# 

Prior to manually completing the process, encryptedRaid and
hawk--vg--raid-crc2020 are absent.



Also, I get the following message in syslog at boot time:

udisksd[747]: Failed to load the 'mdraid' libblockdev plugin

How badly do I need mdraid, and do I get it from the
libblockdev-mdraid2 package?

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [next] | [standalone]

#228647

On 11/14/2020 4:23 AM, Charles Curley wrote:
> I've added RAID and two new hard drives to my desktop. The RAID appears
> to work, once it is up and running. Alas, on boot it is not being
> properly set up. Everything else comes up correctly.
>
> I have two new four terabyte drives set aside for RAID. They are
> partitioned, with one partition on each, and the two partitions
> combined in a RAID1 array. So far so good.
>
> On top of the RAID1 array is an encrypted device. This is where booting
> seems to break down. I do not get the device files related to the
> encrypted layer in /dev/mapped.
>
> On top of the encrypted layer is an LVM2 physical volume (PV). Within
> that is one logical volume, with an ext4 file system on it.
>
> I see messages in syslog for the two drives originally in the system,
> sda and sdb. However, I don't see any for the two new drives, sdc and
> sdd. E.g:
>
> systemd[1]: Started Cryptography Setup for sdb3_crypt.
>
> I can manually complete the process after the system has booted:
>
> cryptsetup luksOpen /dev/md0 encryptedRaid
> mount /dev/mapper/hawk--vg--raid-crc2020
>
> What do I do to automate that?
>



Is your '/etc/crypttab' file properly populated?

--
John Doe

[toc] | [prev] | [next] | [standalone]

#228658

On Sat, 14 Nov 2020 08:12:41 +0100
john doe <johndoe65534@mail.com> wrote:

> >
> > What do I do to automate that?
> >  
> 
> 
> 
> Is your '/etc/crypttab' file properly populated?

Well, I thought it was....

At first I got the UUID for the RAID device, /dev/md0:

root@hawk:~# mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Thu Nov 12 12:06:28 2020
        Raid Level : raid1
        Array Size : 3906884416 (3725.90 GiB 4000.65 GB)
     Used Dev Size : 3906884416 (3725.90 GiB 4000.65 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sat Nov 14 11:52:39 2020
             State : clean 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : hawk:0  (local to host hawk)
              UUID : 0d3ec9c1:2bc5b3e8:24a27283:c0cad01b
            Events : 12270

    Number   Major   Minor   RaidDevice State
       0       8       33        0      active sync   /dev/sdc1
       1       8       49        1      active sync   /dev/sdd1
root@hawk:~# 

and set that up as a line in /etc/crypttab:

encryptedRaid UUID=0d3ec9c1-2bc5-b3e8-24a2-7283c0cad01b none luks

Didn't work, and gave a 90 second timeout.

Note that the UUID in crypttab is re-formatted to agree with the other
UUIDs in that file, dashes rather than colons. Is that relevant?

Or (afterthought here) did I give it the wrong UUID?

root@hawk:~# ll /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 300 Nov 14 11:52 ./
drwxr-xr-x 8 root root 160 Nov 14 11:51 ../
lrwxrwxrwx 1 root root  10 Nov 14 11:52 343ed59e-ae41-4733-8277-f1b77de67479 -> ../../sda5
lrwxrwxrwx 1 root root  10 Nov 14 11:52 52be92ca-795f-46ef-9c52-074fceedc53c -> ../../dm-1
lrwxrwxrwx 1 root root   9 Nov 14 11:52 57de8169-da6c-4952-b6ac-25e6c87dbf1a -> ../../md0
...
root@hawk:~#

Anyway, I tried it by device name, and that worked.

encryptedRaid /dev/md0 none luks

Useful tip: that worked without a prompt because I gave /dev/md0's
encryption the same passphrase I gave the other encrypted partitions.

This also works:

encryptedRaid /dev/md0 /root/raid.encrypt.password.txt luks


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#228661

I have more or less the same configuration. I am a no-systemd user
(yet?) so I cannot show you the full example.
You could verify:
- Is there a mdraid1x module  in your grub menu entry?
- If I not wrong you made your RAID by mdadm metadata version 1.2. I
think in this version metadata is located at first blocks, on the
other hand, version 1.0 places at the end blocks. Somewhere out there
I read blootable partitions could not use 1.2 metadata version. Thus,
for a bootable (and EFI, if exists) partition must be build in
metadata version 1.0. I did and it works. This you could solve your
problem.

To force a specific metadata version, I used:
mdadm --create --metadata=1.0 --verbose /dev/md2....

Toni Mas

Missatge de Charles Curley <charlescurley@charlescurley.com> del dia
ds., 14 de nov. 2020 a les 20:40:
>
> On Sat, 14 Nov 2020 08:12:41 +0100
> john doe <johndoe65534@mail.com> wrote:
>
> > >
> > > What do I do to automate that?
> > >
> >
> >
> >
> > Is your '/etc/crypttab' file properly populated?
>
> Well, I thought it was....
>
> At first I got the UUID for the RAID device, /dev/md0:
>
> root@hawk:~# mdadm --detail /dev/md0
> /dev/md0:
>            Version : 1.2
>      Creation Time : Thu Nov 12 12:06:28 2020
>         Raid Level : raid1
>         Array Size : 3906884416 (3725.90 GiB 4000.65 GB)
>      Used Dev Size : 3906884416 (3725.90 GiB 4000.65 GB)
>       Raid Devices : 2
>      Total Devices : 2
>        Persistence : Superblock is persistent
>
>      Intent Bitmap : Internal
>
>        Update Time : Sat Nov 14 11:52:39 2020
>              State : clean
>     Active Devices : 2
>    Working Devices : 2
>     Failed Devices : 0
>      Spare Devices : 0
>
> Consistency Policy : bitmap
>
>               Name : hawk:0  (local to host hawk)
>               UUID : 0d3ec9c1:2bc5b3e8:24a27283:c0cad01b
>             Events : 12270
>
>     Number   Major   Minor   RaidDevice State
>        0       8       33        0      active sync   /dev/sdc1
>        1       8       49        1      active sync   /dev/sdd1
> root@hawk:~#
>
> and set that up as a line in /etc/crypttab:
>
> encryptedRaid UUID=0d3ec9c1-2bc5-b3e8-24a2-7283c0cad01b none luks
>
> Didn't work, and gave a 90 second timeout.
>
> Note that the UUID in crypttab is re-formatted to agree with the other
> UUIDs in that file, dashes rather than colons. Is that relevant?
>
> Or (afterthought here) did I give it the wrong UUID?
>
> root@hawk:~# ll /dev/disk/by-uuid/
> total 0
> drwxr-xr-x 2 root root 300 Nov 14 11:52 ./
> drwxr-xr-x 8 root root 160 Nov 14 11:51 ../
> lrwxrwxrwx 1 root root  10 Nov 14 11:52 343ed59e-ae41-4733-8277-f1b77de67479 -> ../../sda5
> lrwxrwxrwx 1 root root  10 Nov 14 11:52 52be92ca-795f-46ef-9c52-074fceedc53c -> ../../dm-1
> lrwxrwxrwx 1 root root   9 Nov 14 11:52 57de8169-da6c-4952-b6ac-25e6c87dbf1a -> ../../md0
> ...
> root@hawk:~#
>
> Anyway, I tried it by device name, and that worked.
>
> encryptedRaid /dev/md0 none luks
>
> Useful tip: that worked without a prompt because I gave /dev/md0's
> encryption the same passphrase I gave the other encrypted partitions.
>
> This also works:
>
> encryptedRaid /dev/md0 /root/raid.encrypt.password.txt luks
>
>
> --
> Does anybody read signatures any more?
>
> https://charlescurley.com
> https://charlescurley.com/blog/
>

[toc] | [prev] | [next] | [standalone]

#228664

On Sat, 14 Nov 2020 23:00:35 +0100
Toni Mas Soler <antomassol@gmail.com> wrote:

> I have more or less the same configuration. I am a no-systemd user
> (yet?) so I cannot show you the full example.
> You could verify:
> - Is there a mdraid1x module  in your grub menu entry?
> - If I not wrong you made your RAID by mdadm metadata version 1.2. I
> think in this version metadata is located at first blocks, on the
> other hand, version 1.0 places at the end blocks. Somewhere out there
> I read blootable partitions could not use 1.2 metadata version. Thus,
> for a bootable (and EFI, if exists) partition must be build in
> metadata version 1.0. I did and it works. This you could solve your
> problem.

Thank you. An interesting thought, but in my setup the RAID array is not
necessary to boot. That is handled on a different drive entirely.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#228816 — [Solved] Re: RAID installation at boot questions

On Sat, 14 Nov 2020 12:15:47 -0700
Charles Curley <charlescurley@charlescurley.com> wrote:

> Or (afterthought here) did I give it the wrong UUID?

A week later, I came back to this. It appears I did use the wrong UUID
in /etc/crypttab.

root@hawk:~# ll /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 180 Nov 20 10:25 ./
drwxr-xr-x 7 root root 140 Nov 20 10:24 ../
lrwxrwxrwx 1 root root  10 Nov 20 10:40 343ed59e-ae41-4733-8277-f1b77de67479 -> ../../sda5
lrwxrwxrwx 1 root root  10 Nov 20 10:36 52be92ca-795f-46ef-9c52-074fceedc53c -> ../../dm-1
lrwxrwxrwx 1 root root   9 Nov 20 10:41 57de8169-da6c-4952-b6ac-25e6c87dbf1a -> ../../md0
lrwxrwxrwx 1 root root  10 Nov 20 10:40 85936b4c-4088-4365-9c93-6a7cd8a025c6 -> ../../sda1
lrwxrwxrwx 1 root root  10 Nov 20 10:36 a3cc28cf-fb2f-4ef5-803e-2fcce7006d05 -> ../../dm-2
lrwxrwxrwx 1 root root  10 Nov 20 10:36 aef1882d-714d-41da-865e-f5cc161473e6 -> ../../dm-5
lrwxrwxrwx 1 root root  10 Nov 20 10:36 e297096c-1336-4f9f-8da0-025da7190d7b -> ../../dm-3
root@hawk:~# 

A quick experiment shows that this UUID for /dev/md0 is the one that
works. This is also the UUID that gparted shows for /dev/md0.

encryptedRaid UUID=57de8169-da6c-4952-b6ac-25e6c87dbf1a none luks

As previously noted, using the device name also works, with or without
a password file:

encryptedRaid /dev/md0 /root/raid.encrypt.password.txt luks

or

encryptedRaid /dev/md0 none luks


And that leaves the question of whether mdadm has a bug or whether it
is showing some other UUID. Which question I am not going to pursue.


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web