20.04 Set up LVM but df -h shows the wrong volume group name

**matthew54** · April 28th, 2020

I set up LVM with 1 volume group (vg01) with several logical volumes underneath it. After the install, I ran a df -h. All of the logical volumes showed the correct /dev/mapper/vg01-partition, except for the /usr volume. This instead shows a strange string /dev/disk/by-id/dm-uuid-LVM-heGFM9zmo1GSbygTAJcFLiOIzjkcI5drkAopUUojgDkpr2v7qu tkXuksA1RGiGx8. Why is this and how to I fix it? I set it up exactly the same as the other logical volumes. I even created a new VM and ran into the same issue on the same logical volume.

Here are screenshots of my LVM setup and the output of df -h.
EDIT: Interestingly enough lvdisplay shows the correct information but df -h does not. I added a 3rd screenshot.

https://drive.google.com/open?id=1X6...CscO1-QTndv3rp

**TheFu** · April 30th, 2020

Please post text for the following commands:

Code:

sudo pvs
sudo vgs
sudo lvs
lsblk -e 7 -o name,size,type,fstype,mountpoint

Also, please use code tags like I have or the output won't be readable.

No images.

**matthew54** · April 30th, 2020

Originally Posted by TheFu

Please post text for the following commands:

Code:

sudo pvs
sudo vgs
sudo lvs
lsblk -e 7 -o name,size,type,fstype,mountpoint

Also, please use code tags like I have or the output won't be readable.

No images.

sudo pvs

Code:

  PV         VG   Fmt  Attr PSize   PFree
  /dev/sda2  vg01 lvm2 a--  <24.00g    0

sudo vgs

Code:

  VG   #PV #LV #SN Attr   VSize   VFree
  vg01   1   6   0 wz--n- <24.00g    0

lsblk -e 7 -o name,size,type,fstype,mountpoint

Code:

NAME           SIZE TYPE FSTYPE      MOUNTPOINT
sda             24G disk
├─sda1           1M part
└─sda2          24G part LVM2_member
  ├─vg01-root    7G lvm  xfs         /
  ├─vg01-usr     5G lvm  xfs         /usr
  ├─vg01-home    4G lvm  xfs         /home
  ├─vg01-var     4G lvm  xfs         /var
  ├─vg01-swap    2G lvm  swap        [SWAP]
  └─vg01-tmp     2G lvm  xfs         /tmp
sr0           1024M rom

Just for kicks I'll add /etc/fstab

Code:

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/disk/by-id/dm-uuid-LVM-heGFM9zmo1GSbygTAJcFLiOIzjkcI5dr9KYjQYJI8VVWzN8MO7ErVYTNPVTRe2hT none swap sw 0 0
# / was on /dev/vg01/root during curtin installation
/dev/disk/by-id/dm-uuid-LVM-heGFM9zmo1GSbygTAJcFLiOIzjkcI5drTYmeeHzD1IrqfmC0xYSi14ehddJZAPy2 / xfs defaults 0 0
# /usr was on /dev/vg01/usr during curtin installation
/dev/disk/by-id/dm-uuid-LVM-heGFM9zmo1GSbygTAJcFLiOIzjkcI5drkAopUUojgDkpr2v7qutkXuksA1RGiGx8 /usr xfs defaults 0 0
# /var was on /dev/vg01/var during curtin installation
/dev/disk/by-id/dm-uuid-LVM-heGFM9zmo1GSbygTAJcFLiOIzjkcI5drtuunBaLYD7T8ofJu4e0iNx031zY9EXcH /var xfs defaults 0 0
# /tmp was on /dev/vg01/tmp during curtin installation
/dev/disk/by-id/dm-uuid-LVM-heGFM9zmo1GSbygTAJcFLiOIzjkcI5drZrOBn0nXEHumFAWAJcjYSz2fYB9W5RUF /tmp xfs defaults 0 0
# /home was on /dev/vg01/home during curtin installation
/dev/disk/by-id/dm-uuid-LVM-heGFM9zmo1GSbygTAJcFLiOIzjkcI5drzkvaxltCDKCtUE7WhgrPfv2hXYgvBE4L /home xfs defaults 0 0
/swap.img       none    swap    sw      0       0

**TheFu** · May 1st, 2020

xfs - yuck. That file system can't be shrunk.
You allocated the entire VG already? Why use LVM at all? The flexibility comes from NOT allocating everything, leaving room for snapshots, etc.

The mapper process created a number of different linked files to the /dev/dm-1-999 devices. These links are created in a few different places.

/dev/mapper/{vg}--{lv} with some funky alterations

/dev/{vg}/{lv} which is preferred for all human uses (especially in the fstab)

/dev/disks/by-whatever ..... which can be handy if there are hundreds of mounts and the physical path for the storage-controller-slot are consistent.

In the end, all these are symlinks, dynamically generated, pointing back to /dev/dm-{something}
For example:

Code:

/dev/hadar-vg$ ll
total 0
drwxr-xr-x  2 root root  280 Apr 28 08:48 ./
drwxr-xr-x 21 root root 4540 Apr 30 20:05 ../
lrwxrwxrwx  1 root root    7 Apr 28 08:48 libvirt-lv -> ../dm-2
lrwxrwxrwx  1 root root    7 Apr 28 09:00 lv-blog44-1604 -> ../dm-5
lrwxrwxrwx  1 root root    7 Apr 28 09:00 lv-lubuntu11-1604 -> ../dm-6
lrwxrwxrwx  1 root root    7 Apr 28 09:01 lv-spam3 -> ../dm-8
lrwxrwxrwx  1 root root    8 Apr 28 08:48 lv-udesk2004 -> ../dm-10
lrwxrwxrwx  1 root root    7 Apr 28 08:57 lv-vpn09-1604 -> ../dm-3
lrwxrwxrwx  1 root root    7 Apr 28 09:00 lv-xen41-1604 -> ../dm-4
lrwxrwxrwx  1 root root    7 Apr 28 09:02 lv-zcs45-1604 -> ../dm-7
lrwxrwxrwx  1 root root    7 Apr 28 08:48 lxd-lv -> ../dm-9
lrwxrwxrwx  1 root root    8 Apr 28 08:48 regulus -> ../dm-11
lrwxrwxrwx  1 root root    7 Apr 28 08:48 root -> ../dm-0
lrwxrwxrwx  1 root root    7 Apr 28 08:48 swap_1 -> ../dm-1

$ uptime
 20:49:24 up 2 days, 12:01,  5 users,  load average: 0.85, 0.70, 2.42

They were created at boot, see?

BTW, you probably want temp to have some security options if going to the effort to separate that out. nodev,noexec come to mind to keep the attackers slightly limited, though not really. I'm not a fan of over complicating storage by having lots of LVs. When HDDs started having more than 8GB of storage, it just hasn't been the same issue is was back when people needed to split up their 240MB HDDs carefully to prevent Unix system crashes. I remember those days and had some systems crash.

**yungdelta** · June 5th, 2020

Bump to the OP as I am also experiencing this issue on a newly provisioned VM for Ubuntu 20.04. I've used the same LVM scheme from Xenial and Bionic and never had an issue.

df -h

Code:

Filesystem                                                                                    Size  Used Avail Use% Mounted on
udev                                                                                          700M     0  700M   0% /dev
tmpfs                                                                                         149M  1.2M  148M   1% /run
/dev/sda3                                                                                     2.4G   13M  2.3G   1% /
/dev/disk/by-id/dm-uuid-LVM-jYkvnAp4wuH8aeneXeyPhf2tmRoDGscVJJIsYB8RB5ZArIggpnDptLuGTZCmqZ2n  3.9G  1.7G  2.1G  44% /usr
tmpfs                                                                                         742M     0  742M   0% /dev/shm
tmpfs                                                                                         5.0M     0  5.0M   0% /run/lock
tmpfs                                                                                         742M     0  742M   0% /sys/fs/cgroup
/dev/sda2                                                                                     976M  103M  806M  12% /boot
/dev/mapper/OSVG-home_lv                                                                      976M  2.6M  907M   1% /home
/dev/mapper/OSVG-tmp_lv                                                                       976M  2.6M  907M   1% /tmp
/dev/mapper/OSVG-var_lv                                                                       2.9G  443M  2.3G  16% /var
/dev/loop0                                                                                     55M   55M     0 100% /snap/core18/1705
/dev/loop1                                                                                     28M   28M     0 100% /snap/snapd/7264
/dev/loop2                                                                                     69M   69M     0 100% /snap/lxd/14804
tmpfs                                                                                         149M     0  149M   0% /run/user/1000

pvs

Code:

  PV         VG   Fmt  Attr PSize   PFree
  /dev/sdb   OSVG lvm2 a--  <10.00g    0

lvs

Code:

  LV      VG   Attr       LSize    Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home_lv OSVG -wi-ao----    1.00g                                                    
  swap_lv OSVG -wi-ao---- 1020.00m                                                    
  tmp_lv  OSVG -wi-ao----    1.00g                                                    
  usr_lv  OSVG -wi-ao----    4.00g                                                    
  var_lv  OSVG -wi-ao----    3.00g

vgs

Code:

  VG   #PV #LV #SN Attr   VSize   VFree
  OSVG   1   5   0 wz--n- <10.00g    0

lsblk -e 7 -o name,size,type,fstype,mountpoint

Code:

NAME            SIZE TYPE FSTYPE      MOUNTPOINT
sda             3.5G disk             
├─sda1            1M part             
├─sda2            1G part ext4        /boot
└─sda3          2.5G part ext4        /
sdb              10G disk LVM2_member 
├─OSVG-usr_lv     4G lvm  ext4        /usr
├─OSVG-var_lv     3G lvm  ext4        /var
├─OSVG-home_lv    1G lvm  ext4        /home
├─OSVG-tmp_lv     1G lvm  ext4        /tmp
└─OSVG-swap_lv 1020M lvm  swap        [SWAP]
sr0            1024M rom

**c_xy** · April 2nd, 2021

I've experienced this same exact problem installing Ubuntu 20.04.02 from DVD.

I created 5 logical volumes: /var, /home, /usr, /files/, /tmp

Only the /usr shows this long /dev/dis/by-id/dm-uuid-LVM....... output from the df command. The rest of the of the logical volumes display properly: /dev/mapper/vg01-tmp, /dev/mapper/vg02-home, etc.

Does this reflect a problem with installation or is there a simple workaround/fix?

Thanks.

c.

**TheFu** · April 3rd, 2021

For tiny HDDs, say under 20G, probably just virtual machines, there is little reason to split up the storage into all those LVs. You'll never have the correctd amount where you need it. Whatever guide is being followed ... isn't providing good advice. On a tiny disk, root and /var and swap are about the only LVs that should be created. Anything more and the system will just have storage in the wrong place. I don't think a system with 5G for /usr can even be upgraded. OS upgrades need 2-4G.

There's no right or wrong way to link the dm-{1...999} devices. There are many choices and they all work. The /dev/disk/by-id/dm-uuid-LVM will work and will be repeatable between reboots. Because I have OCD, I want my fstab to be short and have as much detailed information as possible. For me - it is a matter of taste - the LVM links I prefer are

Code:

# /dev/{VGname}/{LVname}
/dev/hadar-vg/root
/dev/hadar-vg/libvirt-lv
/dev/hadar-vg/lxd-lv 
/dev/hadar-vg/swap_1
/dev/vg-hadar/lv-backups

That's my personal taste, but there are lots of "correct" links in /dev/disk/by-*/ that are also fine. Pick your poison. You could even use UUIDs if you like (but why?).

As to what the installer chooses - open a bug. Complain if you must. I find the /dev/mapper/* links distasteful, but they aren't wrong.
While we are complaining, if you use Plex Media Server, complain about their default root path that is 50 characters deep for no good reason too.
"/var/lib/plexmediaserver/Library/Application\ Support/Plex\ Media\ Server/"
What's the point? /var/lib/plex would be just as descriptive.

**c_xy** · April 16th, 2021

Thanks, TheFu.

Is there an easy way to change the output of the df command from this:

/dev/dis/by-id/dm-uuid-LVM.......

to

Code:

/dev/mapper/vg-01-usr

Just like it looks for my other logical volumes

/dev/mapper/vg04-var
/dev/mapper/vg03-home
/dev/mapper/vg02-tmp
/dev/mapper/vg05-data

Thanks

c.

**rakesh4osdd** · July 24th, 2021

I have faced the same issue and solved it like this by editing /etc/fstab as

# /usr was on /dev/ubuntu-vg/lv-usr during curtin installation
#/dev/disk/by-id/dm-uuid-LVM-ebMSAha13YVUnMLwVO8bBKcntfKedF87ppK5r75hoaSd9KHMQP nBAuAHR0hHfRdU /usr xfs defaults 0 0
/dev/mapper/ubuntu--vg-lv--usr /usr xfs defaults 0 0

then reboot the system then df -h does not show the uuid ids in print.

**TheFu** · July 24th, 2021

I don't see any connection between what the fstab uses and what shows up in df output.

Code:

$ less /etc/fstab
UUID=9CE4-930A          /boot/efi vfat   utf8,umask=007,gid=46 0       1
/dev/vgubuntu-mate/root /         ext4   noatime,errors=remount-ro 0 1
/dev/vgubuntu-mate/home /home     ext4   noatime,errors=remount-ro 0 1
/dev/vgubuntu-mate/swap_1 none    swap   sw      0       0

Code:

$ df -Th
Filesystem                      Type  Size  Used Avail Use% Mounted on
/dev/mapper/vgubuntu--mate-root ext4   19G   15G  3.6G  80% /
/dev/mapper/vgubuntu--mate-home ext4   12G  6.4G  4.9G  57% /home
/dev/vda1                       vfat  511M  7.1M  504M   2% /boot/efi

No connection, at least on 20.04 or 18.04. I don't run non-LTS releases.

And just to clarify exactly the LVM situation:

Code:

$ sudo lvs
  LV     VG            Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  home   vgubuntu-mate -wi-ao---- 12.00g                                                    
  root   vgubuntu-mate -wi-ao---- 19.00g                                                    
  swap_1 vgubuntu-mate -wi-ao----  4.10g 

 $ sudo pvs
  PV         VG            Fmt  Attr PSize   PFree
  /dev/vda5  vgubuntu-mate lvm2 a--  <29.50g    0 
  /dev/vdb1  vgubuntu-mate lvm2 a--  <10.00g 4.39g