Add a New Drive to Ubuntu LVM and Mount It Permanently

Adding a new drive to Ubuntu LVM is the most flexible way to expand server storage without downtime. LVM (Logical Volume Manager) sits between your physical disks and the filesystem, letting you stripe across multiple drives, resize volumes live, and add more storage later with a handful of commands. This guide walks through the full workflow, from detecting the disk to a persistent, boot-safe mount, on Ubuntu 24.04 LTS.

The core sequence is: pvcreate → vgcreate → lvcreate → mkfs → mount → fstab. If you follow this order and verify each step, you’ll have a working, persistent data volume in under 10 minutes.

Prerequisites

Before you start, make sure the following are in place:

Install LVM2 on Ubuntu

LVM2 is pre-installed on Ubuntu Server, but minimal or cloud images may not include it:

sudo apt update && sudo apt install lvm2

Verify it’s installed:

lvm version

You should see LVM version: 2.03.16 (or later). If you’re managing a fleet of servers, tools like a self-hosted server panel can help you track what’s installed where.

Confirm the new disk is detected

Use lsblk to see all block devices:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL

Example output with a new 4TB drive:

NAME                      SIZE TYPE MOUNTPOINT MODEL
sda                       3.6T disk            Samsung SSD 870
sdb                       476G disk            RS512GSSD310
├─sdb1                    1.1G part /boot/efi
├─sdb2                      2G part /boot
└─sdb3                  473.9G part
  └─ubuntu--vg-ubuntu--lv 466G lvm  /

If the disk doesn’t show up, check dmesg | tail -20 for detection messages. On hot-added disks (common on cloud servers), you may need to rescan the SCSI bus:

echo "- - -" | sudo tee /sys/class/scsi_host/host0/scan

Repeat for host1, host2, etc. until the disk appears.

If you’re building a home server with multiple drives or need a VPS with expandable block storage, Hetzner Cloud Volumes support online resizing, a natural fit for LVM. You can also benchmark your cloud server’s disk performance after setup to confirm you’re getting the throughput you expect.

Step 1: Identify the new drive with lsblk

Replace the older lshw -C disk approach with lsblk. It’s installed everywhere, shows the block device tree, and is easier to read:

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT,MODEL,SERIAL

Output:

NAME                      SIZE TYPE MOUNTPOINT MODEL              SERIAL
sda                       3.6T disk            Samsung SSD 870    S758NS0W807436T
sdb                       476G disk            RS512GSSD310       EB091502A000561
├─sdb1                    1.1G part /boot/efi
├─sdb2                      2G part /boot
└─sdb3                  473.9G part
  └─ubuntu--vg-ubuntu--lv 466G lvm  /

Here /dev/sda (3.6T Samsung SSD) is the new data drive, and /dev/sdb is the OS disk. The new drive has no partitions and isn’t mounted, exactly what you want to see before creating a physical volume.

For detailed hardware info, sudo lshw -C disk still works, but lsblk gives you everything you need for LVM operations.

Use stable device paths in VPS environments

ls -la /dev/disk/by-id/

This shows persistent paths like scsi-0HC_Volume_12345 that won’t change. You can use these paths directly with pvcreate:

sudo pvcreate /dev/disk/by-id/scsi-0HC_Volume_12345

Once the PV is created, LVM resolves the disk through its own metadata, so this matters most for the initial pvcreate command, not for day-to-day operations.

Step 2: Check existing physical volumes with pvs

Run pvs to see what LVM already knows about:

sudo pvs

Output:

  PV         VG        Fmt  Attr PSize    PFree
  /dev/sdb3  ubuntu-vg lvm2 a--  <473.89g    0

This shows one physical volume (/dev/sdb3) in volume group ubuntu-vg, which is the OS disk. The new drive /dev/sda isn’t listed yet. That’s expected.

Column meanings:

• PV: physical volume device path
• VG: volume group it belongs to
• PSize: total size
• PFree: free space available for new logical volumes

Step 3: Create a physical volume with pvcreate

Create a physical volume on the new disk:

sudo pvcreate /dev/sda

Output:

  Physical volume "/dev/sda" successfully created.

Verify the new PV is registered:

sudo pvs

Output:

  PV         VG        Fmt  Attr PSize    PFree
  /dev/sda             lvm2 ---    <3.64t   <3.64t
  /dev/sdb3  ubuntu-vg lvm2 a--  <473.89g        0

/dev/sda now appears as an LVM physical volume with ~3.64 TB free. For a more detailed view:

sudo pvdisplay /dev/sda

If there’s any data on this disk you need, back it up with dd before this step. Once pvcreate runs, the old partition table is gone.

Step 4: Create a volume group with vgcreate

Create a volume group named mediavg using the new physical volume:

sudo vgcreate mediavg /dev/sda

Output:

  Volume group "mediavg" successfully created

Use descriptive names for volume groups. mediavg tells you what it’s for, unlike vg0 which tells you nothing. You can add more physical volumes to this group later with vgextend.

Step 5: Create a logical volume with lvcreate

Create a logical volume that uses all available space in the volume group:

sudo lvcreate -l +100%FREE -n medialv mediavg

Output:

  Logical volume "medialv" created.

Flag breakdown:

• -l +100%FREE: allocate all free space in the VG to this LV
• -n medialv: name the logical volume

If you want multiple volumes (e.g., separate LVs for media and backups), use specific sizes instead:

sudo lvcreate -L 2T -n medialv mediavg
sudo lvcreate -L 1.6T -n backuplv mediavg

For this guide, we’ll use one LV with all the space.

Step 6: Create an ext4 filesystem (with reserved block tuning)

Format the logical volume with ext4:

sudo mkfs.ext4 -m 0 /dev/mediavg/medialv

Output:

mke2fs 1.47.0 (5-Feb-2023)
Discarding device blocks: done
Creating filesystem with 976753664 4k blocks and 244195328 inodes
Filesystem UUID: 2d665675-4b2e-4a1f-9af6-4652e387d76e
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632,
        2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616,
        78675968, 102400000, 214990848, 512000000, 550731776, 644972544

Allocating group tables: done
Writing inode tables: done
Creating journal (262144 blocks): done
Writing superblocks and filesystem accounting information: done

Step 7: Mount the new filesystem

Create a mount point and mount the volume:

sudo mkdir -p /media/storage
sudo mount /dev/mediavg/medialv /media/storage

Verify the mount:

df -h /media/storage

Output:

Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/mediavg-medialv  3.6T   28K  3.4T   1% /media/storage

The path /dev/mapper/mediavg-medialv is the device-mapper path that LVM creates. You can use either this or /dev/mediavg/medialv. They point to the same device.

For a tree view of all filesystems and their UUIDs:

lsblk -f

Step 8: Make the mount persistent with fstab (using nofail)

Get the UUID of the new filesystem:

sudo blkid /dev/mediavg/medialv

Output:

/dev/mediavg/medialv: UUID="2d665675-4b2e-4a1f-9af6-4652e387d76e" BLOCK_SIZE="4096" TYPE="ext4"

Add an entry to /etc/fstab:

UUID=2d665675-4b2e-4a1f-9af6-4652e387d76e /media/storage ext4 defaults,nofail 0 2

You can use either the UUID or the /dev/mapper path in fstab. Both are persistent under LVM:

/dev/mapper/mediavg-medialv /media/storage ext4 defaults,nofail 0 2

The mapper path is more human-readable, but UUID is the safer default if you ever move the disk between systems. If you hit a kernel panic from a bad fstab entry, boot to recovery mode and fix the line.

Step 9 — Verify fstab before reboot with mount -a

sudo mount -a

If this returns silently (no output), the fstab entry is valid. If you get an error, fix the entry before rebooting.

Confirm the mount is working:

df -h /media/storage

Output:

Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/mediavg-medialv  3.6T   28K  3.4T   1% /media/storage

If mount -a produced no errors and df shows the filesystem, you’re safe to reboot.

Step 10 — Reboot and final verify

sudo reboot

After the system comes back up, verify the mount survived the reboot:

df -h /media/storage

Output:

Filesystem                   Size  Used Avail Use% Mounted on
/dev/mapper/mediavg-medialv  3.6T   28K  3.4T   1% /media/storage

Check the full block device tree:

lsblk -f

You should see mediavg-medialv mounted on /media/storage with the ext4 filesystem and UUID displayed.

If the mount didn’t survive, check the troubleshooting section below — most likely the VG wasn’t activated or there’s a typo in fstab.

Whole-disk vs partition — which approach?

This guide creates a physical volume directly on the raw disk (/dev/sda) without a partition table. This works fine and has advantages. Here’s the trade-off:

Approach	Pros	Cons
Whole-disk PV	Simpler; pvresize works live if the block device grows; no partition table to manage	Other tools/OSes may show the disk as “empty” and offer to format it
Single-partition PV	fdisk -l clearly shows the disk is in use (type 8e or GPT LVM flag)	Resizing requires partition manipulation, often a reboot or partprobe

Do I need a partition table for LVM?

Short answer: no. LVM doesn’t require a partition table. Using the whole disk as a PV is the simpler approach and works well in practice.

When to use a partition anyway:

• If you share this server with other admins, a partition prevents someone from accidentally thinking the disk is unused and reformatting it
• If you plan to boot from the disk (rare for a data drive), you need a partition table
• Some monitoring tools report unpartitioned disks as “unused” — a partition with the LVM flag makes the intent clear

For solo operators and VPS volumes: whole-disk PV is fine. It’s especially good for Hetzner-style volumes that can be resized online, since pvresize on a whole disk is simpler than deleting and recreating a partition.

If you decide to use a partition, create a single Linux LVM partition (type 8e in MBR, or LVM in GPT) that spans the entire disk, then run pvcreate on the partition (/dev/sda1) instead of the raw disk.

How to extend your LVM storage later

One of LVM’s biggest selling points is easy, live resizing. When you need more space, add another disk and extend the volume group — no downtime, no unmount:

# 1. Create a PV on the new disk
sudo pvcreate /dev/sdc

# 2. Add it to the existing volume group
sudo vgextend mediavg /dev/sdc

# 3. Extend the logical volume to use all free space
sudo lvextend -l +100%FREE /dev/mediavg/medialv

# 4. Grow the filesystem to fill the new space (works online, no unmount)
sudo resize2fs /dev/mediavg/medialv

Verify:

df -h /media/storage

Once you have extra storage, you can share your new storage over the network with NFS or set up a Samba share for Windows access. If you’re running containers that need lots of disk space, check out these Docker containers for a home server. You can also reclaim disk space from Docker overlay2 if /var/lib/docker is eating your root volume.

Shrinking a logical volume is also possible but requires unmounting the filesystem and running fsck first — see the LVM documentation for the lvreduce workflow. I’d recommend expanding rather than shrinking whenever possible.

Troubleshooting common LVM issues

pvcreate fails: “Can’t open /dev/sda exclusively”

The disk has an existing partition table, filesystem signature, or is mounted. Fix:

# Remove all signatures from the disk
sudo wipefs -a /dev/sda

# Or zero the first few MB for a clean slate
sudo dd if=/dev/zero of=/dev/sda bs=1M count=10

# Then retry
sudo pvcreate /dev/sda

mount fails: “unknown filesystem type ‘LVM2_member’”

You’re trying to mount the physical volume (the raw disk) instead of the logical volume. Use the LV path, not the disk path:

# Wrong:
sudo mount /dev/sda /media/storage

# Right:
sudo mount /dev/mediavg/medialv /media/storage

LV not active after reboot

The volume group may not have been activated. Check and fix:

# Check VG status
sudo vgdisplay mediavg

# Activate the VG
sudo vgchange -ay mediavg

# Then mount
sudo mount /dev/mediavg/medialv /media/storage

df shows old size after lvextend

You extended the logical volume but forgot to grow the filesystem:

sudo resize2fs /dev/mapper/mediavg-medialv

This works online (no unmount needed) for ext4.

Boot hangs after fstab edit

Boot hangs after fstab edit

If the system hangs at boot after editing fstab, the entry is wrong or the nofail option is missing.

Recovery steps:

1. Boot into recovery mode (hold Shift during boot on BIOS systems, or select recovery in GRUB)
2. Select “root — Drop to root shell prompt”
3. Remount the root filesystem as read-write:

   mount -o remount,rw /

4. Edit fstab:

   nano /etc/fstab

5. Either fix the entry or comment it out with # to boot normally
6. Reboot:

   reboot

If you’re on a remote VPS with no console access, most providers offer a rescue mode or VNC console. Use that to fix fstab remotely. See fix kernel panic from a bad fstab entry for more recovery options.

Disk not detected after hot-add

The kernel didn’t rescan the SCSI bus. Force a rescan:

# Repeat for each host adapter until the disk appears
echo "- - -" | sudo tee /sys/class/scsi_host/host0/scan
echo "- - -" | sudo tee /sys/class/scsi_host/host1/scan
echo "- - -" | sudo tee /sys/class/scsi_host/host2/scan

Check with lsblk after each scan.

Conclusion

You’ve added a new drive to Ubuntu LVM and mounted it permanently. The sequence is always the same:

1. Identify the disk with lsblk
2. Create a physical volume with pvcreate
3. Create a volume group with vgcreate
4. Create a logical volume with lvcreate
5. Format with mkfs.ext4 -m 0
6. Mount and verify
7. Add to fstab with defaults,nofail
8. Test with mount -a before rebooting

The two safety lessons worth remembering: always add nofail to fstab for non-root drives, and always test with mount -a before rebooting a remote server.

From here, you can expand the volume group with vgextend when you need more space, share the storage over NFS, set up Samba for Windows clients, or mount cloud object storage as a filesystem for offsite backups.

Need a VPS with expandable block storage? Hetzner Cloud Volumes expand online with no downtime and work well with LVM.