65

During the installation of Ubuntu Server 20.04.1 LTS I chose to use the entire disk as partition (default partitioning that's recommended for beginners, since I don't need any other partitions anyway.

Output of fdisk -l:

Device           Start        End    Sectors   Size Type
/dev/nvme0n1p1    2048    1050623    1048576   512M EFI System
/dev/nvme0n1p2 1050624    3147775    2097152     1G Linux filesystem
/dev/nvme0n1p3 3147776 2000406527 1997258752 952.4G Linux filesystem

But when I check with df -h, the biggest partition I have is around 200GB. Where are the rest roughly 750GB that are missing?

Output of df -h:

Filesystem                         Size  Used Avail Use% Mounted on
udev                                32G     0   32G   0% /dev
tmpfs                              6.3G  1.7M  6.3G   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv  196G   12G  175G   7% /
tmpfs                               32G     0   32G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
tmpfs                               32G     0   32G   0% /sys/fs/cgroup
/dev/nvme0n1p2                     976M  104M  805M  12% /boot
/dev/nvme0n1p1                     511M  7.8M  504M   2% /boot/efi
/dev/loop1                          56M   56M     0 100% /snap/core18/1885
/dev/loop2                          71M   71M     0 100% /snap/lxd/16922
/dev/loop0                          55M   55M     0 100% /snap/core18/1880
/dev/loop3                          30M   30M     0 100% /snap/snapd/8542
/dev/loop4                          30M   30M     0 100% /snap/snapd/8790
/dev/loop5                          72M   72M     0 100% /snap/lxd/16099
overlay                            196G   12G  175G   7% /var/lib/docker/overlay2/33a73507dae561e19ce713e1a10bd44f68b6d231a7d27d7db5c2ae971dae834a/merged
tmpfs                              6.3G     0  6.3G   0% /run/user/1000

As asked, the output of lsblk:

NAME                      MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0                       7:0    0    55M  1 loop /snap/core18/1880
loop1                       7:1    0  55.3M  1 loop /snap/core18/1885
loop2                       7:2    0  70.6M  1 loop /snap/lxd/16922
loop3                       7:3    0  29.9M  1 loop /snap/snapd/8542
loop4                       7:4    0  29.9M  1 loop /snap/snapd/8790
loop5                       7:5    0  71.3M  1 loop /snap/lxd/16099
nvme0n1                   259:0    0 953.9G  0 disk 
├─nvme0n1p1               259:1    0   512M  0 part /boot/efi
├─nvme0n1p2               259:2    0     1G  0 part /boot
└─nvme0n1p3               259:3    0 952.4G  0 part 
  └─ubuntu--vg-ubuntu--lv 253:0    0   200G  0 lvm  /

Any help is appreciated, thanks in advance!

Improve this question
4
  • 1
    It is really weird that /dev/nvmen1p3 doesn't show up at all. can you run lsblk and df -h /
    – user1119410
    Commented Aug 23, 2020 at 17:26
  • df -h just gives the /dev/mapper/ubuntu--vg-ubuntu--lv part from above.
    – user1119603
    Commented Aug 25, 2020 at 10:20
  • I'm guessing here: The installer is set to leave drive space to allow for snapshots.
    – sudodus
    Commented Oct 13, 2021 at 11:33
  • 1
    See also the discussion here: How is the size the LVM container decided?
    – sudodus
    Commented Oct 13, 2021 at 16:45

7 Answers 7

Reset to default
127

I also used the default Ubuntu 20.04 install from ISO w/ lvm option selected. I had the same problem with the OS disk not occupying what I had allocated. Eddie's suggestion and the provided link did it for me. To summarize:

root@util:~# vgdisplay
<snip>
root@util:~# lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
<snip>
root@util:~# resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
<snip>

Before

root@util:~# df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                               3.9G     0  3.9G   0% /dev
tmpfs                              795M  1.1M  793M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv   98G  6.5G   86G   8% /
tmpfs                              3.9G     0  3.9G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
tmpfs                              3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/xvda2                         976M  105M  805M  12% /boot
/dev/loop2                          56M   56M     0 100% /snap/core18/1944
/dev/loop0                          32M   32M     0 100% /snap/snapd/10707
/dev/loop1                         132M  132M     0 100% /snap/docker/796
/dev/loop3                          70M   70M     0 100% /snap/lxd/19188
/dev/loop4                          33M   33M     0 100% /snap/snapd/11588
/dev/loop5                          56M   56M     0 100% /snap/core18/1997
/dev/loop6                          71M   71M     0 100% /snap/lxd/19647
tmpfs                              795M     0  795M   0% /run/user/1000

After

root@util:~# df -h
Filesystem                         Size  Used Avail Use% Mounted on
udev                               3.9G     0  3.9G   0% /dev
tmpfs                              795M  1.1M  793M   1% /run
/dev/mapper/ubuntu--vg-ubuntu--lv  196G  6.5G  180G   4% /
tmpfs                              3.9G     0  3.9G   0% /dev/shm
tmpfs                              5.0M     0  5.0M   0% /run/lock
tmpfs                              3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/xvda2                         976M  105M  805M  12% /boot
/dev/loop2                          56M   56M     0 100% /snap/core18/1944
/dev/loop0                          32M   32M     0 100% /snap/snapd/10707
/dev/loop1                         132M  132M     0 100% /snap/docker/796
/dev/loop3                          70M   70M     0 100% /snap/lxd/19188
/dev/loop4                          33M   33M     0 100% /snap/snapd/11588
/dev/loop5                          56M   56M     0 100% /snap/core18/1997
/dev/loop6                          71M   71M     0 100% /snap/lxd/19647
tmpfs                              795M     0  795M   0% /run/user/1000
Improve this answer
8
  • 2
    Yes, this worked, lvextend alone didn't do anything
    – Madeo
    Commented Jul 14, 2021 at 9:12
  • 2
    Wow, this solution is amazing. I had no idea you could do these things live and so quickly with LVM.
    – Manchineel
    Commented Dec 1, 2021 at 21:23
  • 1
    This has worked for me, and took only a few seconds to raise the volumes from 200 GB to ~1024 GB on multiple production Elasticsearch nodes during a massive import.
    – Moonchild
    Commented Dec 2, 2021 at 10:41
  • 1
    Thank you very much. Definitely works!
    – newbieee
    Commented Dec 24, 2021 at 8:22
  • 7
    This worked on Ubuntu Server 22.04. Thanks! I have no idea why it didn't use the "full disk" when I definitely chose "use full disk".
    – phocks
    Commented Dec 1, 2022 at 10:08
15

I had this problem also. The link below has instructions on how to extend the LVM partition to use all available space.

https://www.linuxtechi.com/extend-lvm-partitions/

Not mentioned in the above link is this command to use all remaining space rather than specifying a specific amount to add:

lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv

The installation is misleading because I specifically selected the option to use all available space, but not all available space was utilized.

Improve this answer
1
  • Your lvextend command was all I needed for my new Ubuntu server install to use the entire disk.
    – M. K.
    Commented Jul 29, 2021 at 21:15
3

Your root filesystem is on an LVM logical volume (LV) /dev/mapper/ubuntu--vg-ubuntu--lv (196 GB).

The LVM volume group (VG) that provides disk space for that LV probably has one single physical volume (PV), presumably that third partition on that SSD (/dev/nvme0n1p3 with 952.4G).

The VG probably still has a lot of disk space that you could use to make that LV bigger or to create another LV. It might be a disk space allocation strategy of the Ubuntu installer not to simply use all available disk space straight away for the root filesystem, giving you some leeway to decide what to do with the remaining disk space.

You didn't use the "-T" argument to the "df" command, so it doesn't tell the filesystem type; but most modern Linux filesystems have a tool to resize them. ext4 certainly supports that.

Here is a tutorial on the LVM tools: https://www.digitalocean.com/community/tutorials/how-to-use-lvm-to-manage-storage-devices-on-ubuntu-18-04

If you didn't explicitly select using LVM during installation, this might also be a result of choosing encryption; that is typically done via LVM.

HTH

Improve this answer
1
  • 2
    I rechecked the installer and indeed "use lvm" is pre-ticked and then I might have been taken it. However, it's still a strange strategy from Canonical, doing it that way and calling it "use full partition", and mark it as recommended for beginners.
    – user1119603
    Commented Aug 25, 2020 at 10:23
3

Just run this command from the terminal:

sudo resize2fs -p /dev/mapper/ubuntu--vg-ubuntu--lv`

That did it for me. Then check it with:

df -h
Improve this answer
2

So I have accomplished resize of drive without restarting...

What I had to do, after deploying virtual machine template with 45gb hard drive to 80gb machine...

resized drive to maximum capacity using parted

type following commands into parted
list (shows you which partitions are used)
resizepart 3 80G (number 3 was my partition can be different for you)

then exit parted and type following as root (do sudo su if you don't know how to root)

pvresize /dev/sda3
lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv
resize2fs /dev/mapper/ubuntu--vg-ubuntu--lv
df -H
Improve this answer
2
  • This did nothing for me. I just installed latest Debian netinst. It is also more than 4 times smaller.
    – GTodorov
    Commented Mar 4, 2023 at 3:56
  • I was doing this on Ubuntu 20, but the process should be the same
    – Aleksandar Pavić
    Commented Mar 6, 2023 at 11:00
1

You probably hit the "bug" described in Ubuntu Server Install only uses half of availabe space for root partition

That seems to be by design because they know better than you do. If you want it changed, you'd need to follow the link on that page in the answer to the bug report and tell them they need to reconsider.

Improve this answer
1

Have to run first

lvextend -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv

After that

sudo resize2fs -p /dev/mapper/ubuntu--vg-ubuntu--lv

First one extend the lv and second one resize.

Then Check df -h

Improve this answer

You must log in to answer this question.