TL;DR: I messed up a LUKS partition resize operation and need help restoring it. Below is all relevant information I could think of. If you think any other information might be relevant, or if anything is unclear, let me know.

Continued from my other (self-closed) question

The problem

Can't mount my LUKS encrypted partition due to (at least) that its' physical size is different from its' filesystem size, after a failed attempt at shrinking the partition according to this guide

The solution

I think the (at least partial) solution is ensure the filesystem and LV sizes are equal, and that the PV size is greater than both.

Presumption of no data loss

Please correct me if I'm wrong. Between 0 and ~62.14GB of data has been lost, due to the LVM being ~62.14GB smaller than the filesystem. If I'm very lucky, none of the reduced-away blocks contained data, if I'm very unlucky then all of them did.

The Question and sub questions

Could someone please help me understand the correct and safe way to regain access to the contents of my LUKS-encrypted partition? I wan't to understand what I'm doing and be confident I won't mess anything up any further before I do anything else.

First of all, I'm not sure if I can use the steps of the guide at all with my current starting point, as it probably expects a functional LUKS partition to begin with. These are sizes of different devices.

PV Size     900.00 GiB / not usable 3.00 MiB # pvdisplay
LV Size     842.62 GiB # lvdisplay
Filesystem  904.75331584 GB # disks

Filesystem  241858560 blocks # e2fsck
Physical    220887040 blocks # e2fsck 

here it says the filesystem and logical volume must have the same size, and common sense tells me the physical volume must be of greater or equal size. Here none of these are the case, so I need to either decrease the Filesystem to equal LV (842.62GB) or increase the LV to 904.75331584 GB and increase PV to somewhere above this.

  • Still disks is claiming the LUKS is 999GB. Why?
  • Is it better to just decrease Filesystem or to increase both PV and LV?
  • If the latter, does order matter?
  • How come disks/pvdisplay and e2fsck disagree on the size of the PV and filesystem? (241858560/220887040 != 904.75331584/900.00)

Status quo (screenshots and outputs of various commands)

Command outputs

ubuntu@ubuntu:~$ sudo e2fsck -f /dev/mapper/ubuntu--vg-root
e2fsck 1.43.5 (04-Aug-2017)
The filesystem size (according to the superblock) is 241858560 blocks
The physical size of the device is 220887040 blocks
Either the superblock or the partition table is likely to be corrupt!
Abort<y>? yes

ubuntu@ubuntu:~$ sudo mount /dev/ubuntu-vg/root /mnt 
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/ubuntu--vg-root, missing codepage or helper program, or other error.

ubuntu@ubuntu:~$ sudo pvdisplay 
  --- Physical volume ---
  PV Name               /dev/mapper/crypt1
  VG Name               ubuntu-vg
  PV Size               900.00 GiB / not usable 3.00 MiB
  Allocatable           yes 
  PE Size               4.00 MiB
  Total PE              230399
  Free PE               14561
  Allocated PE          215838
  PV UUID               K3BIz8-FXNn-FYTU-jap6-Ri5X-Ilfq-ZLrwjk

ubuntu@ubuntu:~$ sudo lvdisplay 
  --- Logical volume ---
  LV Path                /dev/ubuntu-vg/root
  LV Name                root
  VG Name                ubuntu-vg
  LV UUID                HxqT5o-zJUq-RVBA-D8v2-YqpS-D685-FkvAbx
  LV Write Access        read/write
  LV Creation host, time ubuntu, 2017-11-15 17:38:16 +0000
  LV Status              available
  # open                 0
  LV Size                842.62 GiB
  Current LE             215710
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

  --- Logical volume ---
  LV Path                /dev/ubuntu-vg/swap_1
  LV Name                swap_1
  VG Name                ubuntu-vg
  LV UUID                ybnQLA-5CKp-W2JS-62At-94kE-i8iT-jkrqx1
  LV Write Access        read/write
  LV Creation host, time ubuntu, 2017-12-29 20:44:49 +0000
  LV Status              available
  # open                 0
  LV Size                512.00 MiB
  Current LE             128
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

ubuntu@ubuntu:~$ sudo resize2fs -p /dev/mapper/ubuntu--vg-root
resize2fs 1.43.5 (04-Aug-2017)
Please run 'e2fsck -f /dev/mapper/ubuntu--vg-root' first.


Hard drive before unlocking crypt

Hard drive after unlocking crypt

Root partition after unlocking cry

Swap partition after unlocking crypt

What I did / cause of the problem

I was following the guide, but didn't save the bash log. Reviewing the guide, these are probably the commands I ran.

# install requirements
sudo apt-get update && sudo apt-get install lvm2 cryptsetup

# unlock encrypted partition 
sudo modprobe dm-crypt
sudo cryptsetup luksOpen /dev/sda3 crypt1
sudo vgscan --mknodes
sudo vgchange -ay

# check that all is ok
sudo e2fsck -f /dev/mapper/ubuntu--vg-root # no problem
# no problem!

# resize file system
sudo resize2fs -p /dev/mapper/ubuntu--vg-root <900-ish>g

# check that everything is still ok 
sudo e2fsck -f /dev/mapper/ubuntu--vg-root 
# no problem!

# display LVMs 
sudo lvdisplay 

# 'Note how much you need to reduce your root (LVM) Logical Volume by'
# I stupidly didn't understand what I should take note of, and hoped it wouldn't matter

# shrink the LVM
# guide says 'ubuntu--vg' in the guide, but only 'ubuntu-vg' existed for me
sudo lvreduce -L -80G /dev/ubuntu-vg/root 

# show size of physical volume
sudo pvdisplay 

# delete the swap partition (may have run with sudo, not sure)
lvremove /dev/ubuntu-vg/swap_1

# change physical size
sudo pvresize --setphysicalvolumesize <900-ish>G /dev/mapper/crypt1

# set permissions of LVM
sudo pvchange -x y /dev/mapper/crypt1

# create new swap partition (either 'ubuntu--vg' or 'ubuntu-vg', not sure)
sudo lvcreate -L 512m -n swap_1 ubuntu--vg
sudo mkswap -L swap_1 /dev/ubuntu-vg/swap_1

# mount the LVM
sudo mount /dev/ubuntu-vg/root /mnt 
# fail!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.