Results 1 to 10 of 10

Thread: Sketchy on LVM + Encryption - seeking documentation and pointers

  1. #1

    Question Sketchy on LVM + Encryption - seeking documentation and pointers

    Hello when I installed OpenSuse 12.1 I chose to utilize LVM + the default encryption. At the time I simply went along with the 20 GB partition for /home (on a 500 GB disk) because I know one of the features of LVM is supposed to be the easy ability to resize partitions. Now I am reading some materials here (forum search) and I don't quite feel confident with this. This is my first time using LVM and the encryption I used to use before was simply Truecrypt on separate partitions.

    Is there any good documentation available which covers OpenSUSE 12.1 LVM+encryption? I have read many things for one or the other but in thinking I believe that the encryption might complicate the standard ways of working with LVM (I am for instance hesitant to attempt to use the partitioner utility to resize it due to 1. the partition obviously being mounted and 2. The complication of the encryption) . I need to know how to resize my /home partition and I also would like to know in advance of some of what will be necessary to recover from say a bad kernel update or such should it occur. Is there perhaps a reasonablyt up to date guide available or do I need to research this on my own and perhaps make one?

  2. #2
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,370
    Blog Entries
    3

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    I haven't tried any resizing.

    There's one or more partitions assigned to an LVM group. And then there are logical volumes within that group. I'm not sure about resizing the partition itself - that might affect the encrytion, since there is a LUKS header with parameters to use for various parts of the partition.

    Once decrypted, the logical volume will appear as "/dev/mapper/volume-name". If you are wanting to change the size of logical volumes within that, you should treat "/dev/mapper/volume-name as the device for the LVM.

    To work when the partition is not in use, boot from a live CD or a rescue CD or DVD. If you look at my blog post on encryption I have a section "care and feeding of the beast" where I indicate how to decrypt and access the logical volumes in it.

    Since I have not done any resizing myself, I can't give more detailed advice.
    openSUSE Leap 15.1; KDE Plasma 5;

  3. #3
    Join Date
    Nov 2009
    Location
    West Virginia Sector 13
    Posts
    15,651

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    LVM does not resize partitions!

    LVM allow you to stitch together multiple partitions into a single expandable file system.

    start here at command line type man lvm

  4. #4

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    There are others here much more knowledgeable in LVM2 than i that will hopefully respond with more detailed information, but i have done resizing a couple of times and the thing to remember is that a logical volume(s) reside inside a physical volume (PV) and during resizing you must do things in the correct order.

    expand the PV prior to expanding the residing LV, or, shrink the LV before shrinking the PV. This is on unmounted devices.

    also in my limited dabbling, after doing the resizing operations it was necessary to run resize2fs on the LV to correct the ext4 filesystem for the new size.

    i have not resized any of my LUKS encrypted volumes, so others will have to confirm that it can be done the same way.

    additional tip: i primarily converted to LVM2 to do on-the-fly snapshot/backups and it is NOT clear during setup that you need to leave empty space on the PV to accommodate the temporary snapshot volume (not the backup, it can go anywhere that has space for it). How much space is up to you and your needs.

    these suggestions pertain to doing the operations from CLI, i was unable to ascertain how yast2 handles resizing operations and went with what i knew would work.

    good luck

  5. #5

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    as usual when i reply from memory, i leave out things (pre-alzheimers).....

    in shrinking, the resize2fs operation should be done first before the LV to relocate any used extents that might be residing on the portion to be removed.

    also, came up with a link discussing encrypted volumes here.....

    https://help.ubuntu.com/community/Re...ptedPartitions

  6. #6

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    j xavier wrote lots of good stuff but also:

    > the thing to remember is that a logical
    > volume(s) reside inside a physical volume (PV)


    That's not quite right. PVs are collected together into volume groups
    (VG). Each LV is created inside a single VG. But a LV can span multiple PVs.

    > during resizing you must do things in the correct order.


    Absolutely!

    Here's a couple of links about LVM:
    http://www.enterprisenetworkingplane...d-Smartctl.htm
    http://www.markus-gattol.name/ws/lvm.html
    http://tldp.org/HOWTO/LVM-HOWTO/

    BTW, I liked the link you later posted about encryption.

  7. #7

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    Thanks everyone. Please keep it coming if you have any additional information. Given that this seems pretty complex and a road not often traveled as well as the fact that I have other disks to backup existing data to and barely anything on my current 20 GB /home partition it seems most time efficient now to simply reinstall using the correct size. I think I will at least make one best effort attempt to do it prior to the full reinstall though so as to possibly learn a thing or two and get experienced with it. Who knows, I just might pull it off.


    Quote Originally Posted by gogalthorp View Post
    LVM does not resize partitions!

    LVM allow you to stitch together multiple partitions into a single expandable file system.

    start here at command line type man lvm
    Hmmm. Well this is my first experience with LVM. Basically I just browsed through Wikipedia and this forum for some basic information prior to using it. I did however note:

    On small systems (like a desktop at home), instead of having to estimate at installation time how big a partition might need to be in the future, LVM allows you to resize your disk partitions easily as needed.
    Logical Volume Manager (Linux) - Wikipedia, the free encyclopedia

    This is what I based my statement on. Based on this I presumed (incorrectly it seems) that this would be far simpler.

  8. #8

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    This was actually FAR easier than I had thought. Since two things were true in my case I was able to do this without even unmounting my LUKS encrypted /home partition.

    1. When OpenSUSE did the partioning of the LVM it used the entire disk for the logical volume group. So no resizing of the logical volume group was necessary and the space was already allocated within it.

    2. I had used the default ext4fs which apparently is able to be resized online while mounted.

    Here is all I that I had to do:

    (output cleaned up a bit for readability)

    Code:
    # lvextend -L+400G /dev/mapper/system-home  Extending logical volume home to 425.00 GiB
    
      Logical volume home successfully resized
    
    # resize2fs /dev/mapper/system-home
    
    resize2fs 1.41.14 (22-Dec-2010)
    Filesystem at /dev/mapper/system-home is mounted on /home; on-line resizing required
    old desc_blocks = 2, new_desc_blocks = 27
    Performing an on-line resize of /dev/mapper/system-home to 111411200 (4k) blocks.
    The filesystem on /dev/mapper/system-home is now 111411200 blocks long.
    This might be a good thing for a FAQ or such as I'd be surprised if I were the only one who needed to do this. All the existing doc sources posted here plus the Gentoo Wiki Entry for LVM were a big help but I imagine all the documentation is overwhelming to many people and they don't know where to start.

    Here's some more output showing before and after to help people like me who were coming into this with no idea whatsoever about LVM and LUKS:

    Relevant fdisk -l output before:

    Code:
    # fdisk -l
    
    Disk /dev/sdd: 500.1 GB, 500107862016 bytes
    255 heads, 63 sectors/track, 60801 cylinders, total 976773168 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 identifier: 0x000ec776
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/sdd1   *        2048      321535      159744   83  Linux
    /dev/sdd2          321536   976773119   488225792   8e  Linux LVM
    
    Disk /dev/mapper/cr_sdd2: 499.9 GB, 499941113856 bytes
    255 heads, 63 sectors/track, 60781 cylinders, total 976447488 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 identifier: 0x00000000
    
    Disk /dev/mapper/cr_sdd2 doesn't contain a valid partition table
    
    Disk /dev/mapper/system-home: 26.8 GB, 26843545600 bytes
    255 heads, 63 sectors/track, 3263 cylinders, total 52428800 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 identifier: 0x00000000
    
    Disk /dev/mapper/system-home doesn't contain a valid partition table
    
    Disk /dev/mapper/system-root: 21.5 GB, 21474836480 bytes
    255 heads, 63 sectors/track, 2610 cylinders, total 41943040 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 identifier: 0x00000000
    
    Disk /dev/mapper/system-root doesn't contain a valid partition table
    
    Disk /dev/mapper/system-swap: 2147 MB, 2147483648 bytes
    255 heads, 63 sectors/track, 261 cylinders, total 4194304 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 identifier: 0x00000000
    
    Disk /dev/mapper/system-swap doesn't contain a valid partition table
    BEFORE:

    Code:
    # vgs
    
      VG     #PV #LV #SN Attr   VSize   VFree  
      system   1   3   0 wz--n- 465.61g 418.61g
    
    # vgdisplay
    
      --- Volume group ---
      VG Name               system
      System ID             
      Format                lvm2
      Metadata Areas        1
      Metadata Sequence No  4
      VG Access             read/write
      VG Status             resizable
      MAX LV                0
      Cur LV                3
      Open LV               3
      Max PV                0
      Cur PV                1
      Act PV                1
      VG Size               465.61 GiB
      PE Size               4.00 MiB
      Total PE              119195
      Alloc PE / Size       12032 / 47.00 GiB
      Free  PE / Size       107163 / 418.61 GiB
      VG UUID               UbYoJA-r15f-PTXo-AkAa-8HiE-YoV3-eUAZGE
       
    # lvs
    
      LV   VG     Attr   LSize  Origin Snap%  Move Log Copy%  Convert
      home system -wi-ao 25.00g                                      
      root system -wi-ao 20.00g                                      
      swap system -wi-ao  2.00g                        
                  
    # df
    Filesystem              1K-blocks     Used Available Use% Mounted on                                          
    rootfs                   20642428  4548504  15045348  24% /                                                   
    devtmpfs                  1024108       40   1024068   1% /dev                                                
    tmpfs                     1030796      644   1030152   1% /dev/shm                                            
    tmpfs                     1030796      748   1030048   1% /run
    /dev/mapper/system-root  20642428  4548504  15045348  24% /                                                   
    tmpfs                     1030796        0   1030796   0% /sys/fs/cgroup                                      
    tmpfs                     1030796      748   1030048   1% /var/run                                            
    tmpfs                     1030796        0   1030796   0% /media
    tmpfs                     1030796      748   1030048   1% /var/lock
    /dev/mapper/system-home  25803068  7109196  17645296  29% /home
    /dev/sdd1                  154691    31421    115283  22% /boot
    AFTER:

    Code:
    # lvs
    
      LV   VG     Attr   LSize   Origin Snap%  Move Log Copy%  Convert
      home system -wi-ao 425.00g                                      
      root system -wi-ao  20.00g                                      
      swap system -wi-ao   2.00g           
                               
     # vgs
    
      VG     #PV #LV #SN Attr   VSize   VFree 
      system   1   3   0 wz--n- 465.61g 18.61g
    
    # df
    
    df
    Filesystem              1K-blocks    Used Available Use% Mounted on
    rootfs                   20642428 4546032  15047820  24% /
    devtmpfs                  1024108      40   1024068   1% /dev
    tmpfs                     1030796     484   1030312   1% /dev/shm
    tmpfs                     1030796     704   1030092   1% /run
    /dev/mapper/system-root  20642428 4546032  15047820  24% /
    tmpfs                     1030796       0   1030796   0% /sys/fs/cgroup
    tmpfs                     1030796     704   1030092   1% /var/lock
    tmpfs                     1030796       0   1030796   0% /media
    tmpfs                     1030796     704   1030092   1% /var/run
    /dev/sdd1                  154691   31421    115283  22% /boot
    /dev/mapper/system-home 438652384 6680220 414155588   2% /home

    I probably should have backed up first (but it was a newish install so I did not care) and I suppose it would have been more proper to check the filesystem first before a resize operation. Also to shrink a partition is slightly different (see docs such as the Gentoo wiki already posted) and some filesystem types such as ext2 and ext3 MUST be unmounted first.

    Thanks again everyone for your help and I hope I passed it along somewhat and that this will help someone else in turn.
    Last edited by davidmfl; 08-Feb-2012 at 18:01. Reason: cleaned up

  9. #9

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    davidmfl wrote:
    > This was actually FAR easier than I had thought. Since two things were
    > true in my case I was able to do this without even unmounting my LUKS
    > encrypted /home partition.


    That's great. It's really good to hear that you solved your issue.

    > 1. When OpenSUSE did the partioning of the LVM it used the entire disk
    > for the logical volume group.


    Just for the benefit of anybody else reading this thread later, the
    statement above isn't true as evidenced by the fdisk -l output. OpenSUSE
    divided the disk into two partitions and used one for /boot and the
    other filled the rest of the disk and was used as an LVM PV.

    That matters because:
    (a) it avoids the complications that come with trying to boot using LVM

    (b) although it is possible to format an entire disk as LVM, as opposed
    to formatting a partition that occupies the whole disk as LVM, it's
    generally not recommended. One reason is that grub is quite capable of
    overwriting the LVM metadata in some circumstances.

  10. #10

    Default Re: Sketchy on LVM + Encryption - seeking documentation and pointers

    Quote Originally Posted by djh-novell View Post

    Just for the benefit of anybody else reading this thread later, the
    statement above isn't true as evidenced by the fdisk -l output. OpenSUSE
    divided the disk into two partitions and used one for /boot and the
    other filled the rest of the disk and was used as an LVM PV.

    That matters because:
    (a) it avoids the complications that come with trying to boot using LVM

    (b) although it is possible to format an entire disk as LVM, as opposed
    to formatting a partition that occupies the whole disk as LVM, it's
    generally not recommended. One reason is that grub is quite capable of
    overwriting the LVM metadata in some circumstances.
    Sorry you are of course correct, I should have been more precise. It did create the /boot partition as well which isn't a part of the the Volume Group.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •