Gentoo Archives: gentoo-user

From: Dale <rdalek1967@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Replace 8TB drive with 10TB drive on encrypted LVM
Date: Wed, 14 Sep 2022 15:30:13
Message-Id: 5fdaf423-8953-3198-f788-3cd101a1568d@gmail.com
In Reply to: Re: [gentoo-user] Replace 8TB drive with 10TB drive on encrypted LVM by Frank Steinmetzger
1 Frank Steinmetzger wrote:
2 > Am Wed, Sep 14, 2022 at 08:55:26AM -0500 schrieb Dale:
3 >
4 >> I see the point but wasn't aware there was more than one way to do it
5 >> with cryptsetup.  It seems there is several options for this.  I was
6 >> pretty sure LVM was on bottom and mentioned it in my original post. 
7 > Indeed you did and it confused me at first. Then I gave it some thought and
8 > concluded: why not?
9 >
10 > You do it like so:
11 > Block device --,
12 > Block device --+-- LVM --- LUKS --- File system
13 > Block device --'
14 >
15 >> After reading your post, I got to wondering, did I do this the right
16 >> way?
17 > Your advantage: only one LUKS header to take care of. That means no extra
18 > crypt management when adding or removing disks, except for resizing the
19 > crypt volume. And there is only a single place of storage for your keys (in
20 > case you ever need to change them).
21 >
22 > I’m not sure whether it’s the right™ way. It is *one* way. Perhaps there are
23 > drawbacks that I can’t think of right now.
24
25 By right way, I was talking about the way I moved things around. It
26 seems to be working so I guess I did it the right way, for this setup
27 anyway.  I might have broke things if it was set up some other way. 
28
29
30 >
31 > I would typically have done:
32 > Block device --- LUKS --,
33 > Block device --- LUKS --+-- LVM --- File system
34 > Block device --- LUKS --'
35 >
36 > That’s how my NAS works at the moment (with ZFS instead of LVM + filesystem).
37 > But that’s because ZFS didn’t have built-in encryption when I set it up some
38 > years ago. These days I would do:
39 >
40 > Block device --,
41 > Block device --+-- ZFS
42 > Block device --'
43 >
44 > That’s it. :D Encryption, disk arrays and file system all in one shop.
45 >
46 >> So, I started looking to see how to tell for sure.  I used several
47 >> LVM type commands but didn't see anything that I recognized anyway. 
48 >> Keep in mind, I'm not real sure what I'm looking for either. Then I ran
49 >> lsblk -f and found a clue that I've never noticed before. 
50 >>
51 >>
52 >> sdd                                                                                                    
53 >>
54 >> └─sdd1              LVM2_member LVM2 001         
55 >> pVnP2i-sj48-3co9-nJpa-9tQr-08pa-9JqASR               
56 >>   └─crypt-crypt     crypto_LUKS 2                
57 >> 6e884aae-9377-49ef-a602-e13cba89a377                 
58 >>     └─crypt         ext4        1.0      crypt   
59 >> 76653316-329f-4747-8fed-fc9b1723bd14      3.5T    79%
60 >> /home/dale/Desktop/Crypt
61 >>
62 >>
63 >> I know that is going to be line wrapped and mess up things
64 > You could have redacted the long UUIDs which aren’t relavant anyways. I write my mail in mutt and vim, thus I can rewrap paragraphs individually and at will. That way I can paint ASCII art, paste over-long console output or write one-line paragraphs like this one. ;-)
65
66 I started to but thought it would cause yet another issue.  ROFL 
67
68 >> but the part I noticed was the drive partition "sdd1" and "LVM2 member". 
69 >> On top of that is crypto.  So, LVM is on bottom.  If that is the case, my
70 >> pvmove command should be moving what I think you call "raw data", doesn't
71 >> matter if it is encrypted or not, right?
72 > Yup. This kind of layering is one of the big beauty of Linux for me. It’s
73 > all interchangable and layer X doesn’t care what layer X+1 is doing and vice
74 > versa.
75 >
76 >> Just in case it matters, could I have done everything but the file system
77 >> resize while it was closed?  It seems it is basically encrypted on the
78 >> layer just below the file system to me. 
79 > I think so, yes.
80 >
81 >
82 > PS.: All your LVM threads made me embrace LVM on my PC when I recently
83 > switched it from SATA to NVMe. And because after many years of ignorance, I
84 > finally had an actual use case: my laptop’s root partition became too small
85 > and I had to give it some space from the data partition. In my early Gentoo
86 > years I didn’t use an initrd and didn’t want to, so LVM was never an option.
87 > But when I set up the (then brand-new) laptop, I used Sakaki’s howto for
88 > full-disk encryption, which used an initrd + LVM anyways. This saved the
89 > SSD from a full reformat and rewrite.
90 >
91
92
93 I have to say, before I started using LVM, it was very hard to change
94 storage up.  As it is, /boot and / are on a traditional partition, no
95 LVM.  Everything else is on LVM.  At the time, I was avoiding the init
96 thingy.  Since I have /usr separate, and /var, I ended up having to use
97 one anyway but dracut came along.  Only gave me a problem once so
98 overall, pretty good. 
99
100 I'm not sure who got me started on LVM.  Could be Alan who isn't on this
101 list anymore, Neil or someone else.  It's been a long long time ago.  I
102 tell you what tho, it has made things a LOT easier.  I've read about
103 btrfs(sp?).  It could be the next big thing but I'll likely stick with
104 LVM as long as it works for me.  ZFS seems to be getting popular too.
105 I'm not sure who is winning the race between them tho.  I think they all
106 each have their use case. 
107
108 My biggest thing, I couldn't find hardly anything to do that with it
109 encrypted and what I did find was not very clear.  I couldn't imagine it
110 not being doable tho.  After all, this is Linux.  :-) 
111
112 I'm just glad it worked out and if anyone runs up on this thread, this
113 additional info will help someone else.  Now, people can see what the
114 setup is.  See if it matches what they have or not. 
115
116 Dale
117
118 :-)  :-) 
119
120 P. S.  My second move is almost 90% done with pvmove.