[Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

MaxT · 2014-09-09 12:03:52

Hi there,

My notebook came with Win8 installed. It has two 128G SSDs and a Raid0. I want to keep the Raid but also have full disk encryption. So I plan to do the setup mentioned in the title, using this blogpost as a guide: http://jasonwryan.com/blog/2012/02/11/lvm/

However, something strange happened right at the start: After executing dd if=/dev/random of=/dev/sd[a,b], I looked at the output of lsblk -f and it did not change. In fact, Windows could still boot as usual. It should have been wiped, right?

Then I wanted to take a closer look at the current preinstalled setup, but as a Linux newbie I have problems interpreting what I see. So perhaps someone could assist me in finding out, how the current setup looks like. Also, I would like to have a strategy on how to best tackle the installation.

Perhaps the Raid can remain as it is? But then, how to handle the boot partition? Partition both disks and build two Raids? Or the other way round? I am really not sure about the implications of these choices despite quite a bit of reading around the Wiki and other sources.

Here is some more info, to help you understand what's going on. I will gladly provide more.

Output of lsblk -f (sdc is the usb-stick from which I am running Arch right now. But I do not intent to keep that install, but to make a fresh one)

NAME          FSTYPE          LABEL             UUID                                 MOUNTPOINT
sda           isw_raid_member                                                        
└─md126                                                                              
  ├─md126p1   ntfs            Recovery          D21200E61200D181                     
  ├─md126p2   vfat            ESP               FA02-EE7D                            
  ├─md126p3                                                                          
  ├─md126p4   ntfs            Acer              32FC05BBFC0579FD                     
  ├─md126p5   ntfs                              6E10176810173695                     
  └─md126p6   ntfs            Push Button Reset 0E7407CD7407B68D                     
sdb           isw_raid_member                                                        
└─md126                                                                              
  ├─md126p1   ntfs            Recovery          D21200E61200D181                     
  ├─md126p2   vfat            ESP               FA02-EE7D                            
  ├─md126p3                                                                          
  ├─md126p4   ntfs            Acer              32FC05BBFC0579FD                     
  ├─md126p5   ntfs                              6E10176810173695                     
  └─md126p6   ntfs            Push Button Reset 0E7407CD7407B68D                     
sdc                                                                                  
├─sdc1        vfat                              B8C6-5B2B                            /boot
└─sdc3        crypto_LUKS                       ef005a67-3fcb-40f4-9a1f-114a157b0094 
  └─cryptroot ext4                              6efbed44-eb88-40bc-8a29-3494c64c9b11 /

Putput of cat /proc/mdstat

Personalities : [raid0] 
md126 : active raid0 sda[1] sdb[0]
      250060800 blocks super external:/md127/0 64k chunks
      
md127 : inactive sda[1](S) sdb[0](S)
      6306 blocks super external:imsm
       
unused devices: <none>

Output of ls -l /dev | grep md

drwxr-xr-x  2 root root        200 Sep  9 12:15 md
brw-rw----  1 root disk     9, 126 Sep  9 12:15 md126
brw-rw----  1 root disk   259,   0 Sep  9 12:15 md126p1
brw-rw----  1 root disk   259,   1 Sep  9 12:15 md126p2
brw-rw----  1 root disk   259,   2 Sep  9 12:15 md126p3
brw-rw----  1 root disk   259,   3 Sep  9 12:15 md126p4
brw-rw----  1 root disk   259,   4 Sep  9 12:15 md126p5
brw-rw----  1 root disk   259,   5 Sep  9 12:15 md126p6
brw-rw----  1 root disk     9, 127 Sep  9 12:15 md127

Output of ls /dev/md

HDD0_0  HDD0_0p1  HDD0_0p2  HDD0_0p3  HDD0_0p4  HDD0_0p5  HDD0_0p6  imsm0

I hope, someone can give me some advice.

Cheers,
Max

Last edited by MaxT (2014-09-10 08:23:04)

throwaway2014 · 2014-09-09 13:16:40

If I had to guess the partitions probably still appear because the partition table has not been reloaded.

Basically, /proc/prartitions contains a cached list of all of your devices and the partitions on them. You may have seen that after writing a partition table with fdisk, it says something like "reloading partition table, caling ioctl()". This is because fdisk just changed the partition table, and it's instructing Linux to check it again. However, since dd doesn't know that you're overwriting a device, much less a device with a partition table, so it doesn't know to have Linux check the partition tables again.

Similarly for mdadm, it doesn't notice that you're overwriting the underlying drives (and their superblocks), so everything seems to be functional. However, upon closer inspection (e.g. using mdadm -Dvv /dev/md126) would indicate a problem.

In any case, restarting your computer or following these instructions should reload the partition table, and reveal that they do not exist. Furthermore, on restart (or after stopping the RAID array with mdadm --stop, then trying to start it again with mdadm -As) the mdadm RAID arrays should disappear.

All of this assumes that you succeIn any case, the partition table will be reloaded on restart, or ssfully wiped the devices with dd. If this is not the case I would not recommend keeping the RAID arrays as they are anyways, because it is using the imsm metadata format. While this useful for portability between Windows and Linux, I would rather use the mdadm Linux specific metadata format that mdadm defaults to when creating a new array.

MaxT · 2014-09-09 17:17:11

It seems like that wasn't it. The thing is that after the (failed?) wipe of sd[a,b], I rebooted without the installation medium and it booted right into windows, as if nothing happened.

Anyway, I now have stopped the raid first, via mdadm --stop, as you suggested. This resulted in the following outputs:

cat /proc/mdstat

Personalities : [raid0] 
md127 : inactive sda[1](S) sdb[0](S)
      6306 blocks super external:imsm
       
unused devices: <none>

lsblk -f

NAME          FSTYPE          LABEL UUID                                 MOUNTPOINT
sda           isw_raid_member                                            
sdb           isw_raid_member                                            
sdc                                                                      
├─sdc1        vfat                  B8C6-5B2B                            /boot
└─sdc3        crypto_LUKS           ef005a67-3fcb-40f4-9a1f-114a157b0094 
  └─cryptroot ext4                  6efbed44-eb88-40bc-8a29-3494c64c9b11 /

I then attempted another wipe via dd if=/dev/random of=/dev/sd[a,b]. It is still underway, but I think it takes longer then last time. Not sure though.

Let's see, what happens...

And thanks for your thoughts!

throwaway2014 · 2014-09-09 23:02:57

Sorry, completely forgot the part about Windows successfully booting. It was very late where I live.

Really not sure why overwriting wouldn't work, then. Remember you can always check if the RAID array is still intact by reassembling it with something like mdadm -As (if you wipe the drives correctly it shouldn't). Another thing you might try is using shred to overwrite the drives, for example shred -n1 --random-source=/dev/urandom -v /dev/sd{a,b}

MaxT · 2014-09-10 07:16:26

Alright, yesterday I let the dd run for quite a while until I grew impatient and looked for how to get a progress report from a running dd. I used sudo kill -USR1 `pgrep ^dd` and saw that only a few kB have been copied. Unfortunatedly I did not save the output but powered down for the night. But trying it right now again, you can see, how the copying just does not happen:

0+47 records in
0+0 records out
0 bytes (0 B) copied, 237.636 s, 0.0 kB/s

What could preventing it?
Well, I will try shred and see, if it is more successful. Still, I would be very interested in what is going on, but have no idea how to find out.

MaxT · 2014-09-10 07:25:19

Quick update, I got it working now!

The problem was that I used /dev/random. With /dev/urandom, I get 10MB/s. I would not have thought that /dev/random is so slow!

jasonwryan · 2014-09-10 07:33:57

Only ever use the official installation documentation; random blogs are untrustworthy and should be considered harmful...

Glad you got it sorted. Please remember to mark your thread as [Solved] by editing your first post and prepending it to the title.

ewaller · 2014-09-10 15:16:57

MaxT wrote:

The problem was that I used /dev/random. With /dev/urandom, I get 10MB/s. I would not have thought that /dev/random is so slow!

https://en.wikipedia.org/?title=/dev/random
Be aware that /dev/random is intended to be cryptographically secure. Use it when creating keys and other things for which pseudo random numbers are not random enough.
urandom does not depend on hardware random number generators or collection of entropy. It is great for things that have to be fast that appear random. For the purposes of wiping a disk, pseudo random numbers are more than adequate.

MaxT · 2014-09-11 16:25:20

@jasonwryan: As a general rule, that is certainly true. However, this is your own blog. You probably don't consider that harmful, do you? ;-)

@ewaller: Thanks, I am very well aware of the difference between randomness and pseudo-randomness. I just did not expect /dev/random to be that slow.

jasonwryan · 2014-09-11 17:54:32

Well, in my defence, I did warn that it took several days for it to complete the write on a 1TB drive.

MaxT · 2014-09-12 11:50:54

Well, true.

Anyway, I got another question:
I totally forgot the EFI System partition. It must not be part of a raid, LVM or something like that. And then I need the /boot partition, which must not be encrypted obviously.

Now I wonder which approach is better:
1. Create three partitions on each disk: sda1 as EFI System partition, sd[a,b]2 with raid0 as the unencrypted /boot partition, sd[a,b]3 with raid0, LUKS and LVM.
2. Create only two partitions on each disk: sda1 as EFI System partition and /boot partition, sd[a,b]2 with raid0, LUKS and LVM.
(sdb1 would remain unused in both cases)

Would case 1 work? Can the /boot partition be on a raid? If yes, it would speed up the boot-process.

And lastly: can you think of any other pitfalls with such a setup?

Thanks!
Max

teateawhy · 2014-09-12 12:36:45

The directory /boot can be on a RAID, if you use a bootloader that supports it. See https://wiki.archlinux.org/index.php/GRUB#RAID .
The ESP can be a RAID1 component partition, because it looks like a normal ESP to the firmware. Therefore when the files are loaded from the ESP, no speed up is possible due to RAID. You still get the advantage of having two copies of the ESP for backup reasons.
Case 1. and case 2. should work if set up correctly.
In case 1. you either need to use a bootloader that loads the kernel from /boot, or make sure the kernel is copied from /boot to the ESP on each update.
In case 2. the boot directory and ESP are on the same partition, therefore no copying of kernels is necessary.
I recommend you to use option 2., as it is simpler.
EDIT:
There are some points where you need to pay attention when the ESP is a RAID component partition.
Also see:
https://bbs.archlinux.org/viewtopic.php?id=179210
https://bbs.archlinux.org/viewtopic.php … 1#p1390741

Last edited by teateawhy (2014-09-12 12:42:29)

MaxT · 2014-09-13 21:13:21

Thanks for the links and your recommendations. They helped a lot.

I now used sda1 directly as ESP and /boot partition. It is always possible to create some automated backup from sda1 to sdb1 later.

I got pretty far with the installation now. However, I am running into problems with the installation of Grub. I added the following to /etc/default/grub on the line that says GRUB_CMDLINE_LINUX_DEFAULT:

cryptdevice=/dev/md0:vgroup resume=/dev/mapper/vgroup-lvswap

When I run grub-mkconfig -o /boot/grub/grub.cfg I get several errors and warnings:

/run/lvm/lvmetad.socket: connect failed: No such file or directory
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.
error: cannot seek '/dev/mapper/lvm': Invalid argument.

There errors repeat a few times.

It took me quite some time to collect all the information on how to configure Grub and mkinitcpio in my specific case. I probably missed something...

Any idea?

Edit: Well, I just rebooted without the installation medium and it works! Nice!
Although I still would like to know what those errors are about.

Last edited by MaxT (2014-09-13 21:16:16)

jasonwryan · 2014-09-13 21:22:11

Now that you have rebooted, is there an lvmetad.socket? Have you enabled it in /etc/lvm/lvm.conf?

MaxT · 2014-09-13 23:32:47

Yes, the socket is there. It is in fact the only file in /run/lvm.
I did the installation from chroot as described in the Beginner's Guide. So I guess, that somehow made the difference, right?

Does that mean that everything is allright now? Or should I maybe build the grub.cfg again from the now running system? I haven't tested suspent-to-disk yet, so I am not sure, if that makes problems. But it's late here, so everything else will have to wait till tomorrow

jasonwryan · 2014-09-13 23:44:35

If the socket is there, you are all good. I don't use Grub, so I can't be sure, but I would be surprised if running it again could have a deleterious effect.

Arch Linux

#1 2014-09-09 12:03:52

[Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#2 2014-09-09 13:16:40

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#3 2014-09-09 17:17:11

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#4 2014-09-09 23:02:57

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#5 2014-09-10 07:16:26

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#6 2014-09-10 07:25:19

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#7 2014-09-10 07:33:57

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#8 2014-09-10 15:16:57

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#9 2014-09-11 16:25:20

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#10 2014-09-11 17:54:32

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#11 2014-09-12 11:50:54

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#12 2014-09-12 12:36:45

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#13 2014-09-13 21:13:21

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#14 2014-09-13 21:22:11

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#15 2014-09-13 23:32:47

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

#16 2014-09-13 23:44:35

Re: [Solved] LVM on LUKS on Raid0 on my Acer Aspire S7

Board footer