Linux Data Disk Partitioning, Formatting, and Automatic Mounting at Boot: Complete Guide

After connecting a new data disk, the system will not automatically use it. You must partition, format, and mount it, and add an entry to fstab for automatic mounting at boot—skipping the last step means the data disk will “disappear” after a reboot.

A critical risk in the fstab step is that incorrect entries can prevent the system from booting. We will explain how to avoid this below.

Step 1: Verify the Disk Exists

# List all block devices (most intuitive)
lsblk

# View detailed info and filesystem types
lsblk -f

# Traditional method
fdisk -l

# Check capacity usage
df -h

New data disks typically appear as /dev/vdb or /dev/sdb (no partitions, no filesystem, no mount point).

Double-check the device name: /dev/vda is usually the system disk; operating on it will destroy your system. If unsure, check capacity with lsblk—system disks are usually smaller and mounted at /.

Step 2: Partitioning

First, decide on the partition table type:

# Use parted (recommended, supports GPT)
parted /dev/vdb

# Inside the interactive prompt:
#   mklabel gpt              # Create GPT partition table
#   mkpart primary 0% 100%   # Create one partition spanning the whole disk
#   print                    # Confirm
#   quit

# Or use fdisk (for MBR scenarios)
fdisk /dev/vdb
# Interactive steps: n → p → Enter → Enter → w

# Verify the partition was created
lsblk
# You should see /dev/vdb1

Step 3: Formatting

# ext4 (universal, stable)
mkfs.ext4 /dev/vdb1

# xfs (commonly used for large files and high concurrency)
mkfs.xfs /dev/vdb1

# Verify the result
lsblk -f /dev/vdb1

Formatting erases all data—only execute this if you are sure the disk is empty or data has been backed up.

Step 4: Mounting

# Create the mount point
mkdir -p /data

# Mount the disk
mount /dev/vdb1 /data

# Verify
df -h /data
lsblk

Step 5: Automatic Mounting at Boot (Critical)

Manual mounts do not persist after a reboot; you must add an entry to /etc/fstab.

# ① Get the UUID (Crucial: Do NOT use /dev/vdb1 directly)
blkid /dev/vdb1
# Output example: /dev/vdb1: UUID="xxxx-xxxx" TYPE="ext4"

# ② Backup fstab (Always backup before editing to allow recovery)
cp /etc/fstab /etc/fstab.bak

# ③ Add entry (Use UUID, not device name)
echo 'UUID=xxxx-xxxx  /data  ext4  defaults,nofail  0  2' >> /etc/fstab

# ④ Verify (This step is mandatory and must be done before rebooting)
mount -a
df -h /data

Why Use UUID?

The device name /dev/vdb1 may change after a reboot (especially with multiple cloud disks). Using UUID ensures it always points to the same filesystem.

If fstab uses a device name and that name changes after reboot, the system will fail to mount, potentially entering emergency mode.

Why Recommend Adding nofail?

The purpose of nofail is: if the disk fails to mount, the system still boots normally, rather than hanging during the startup process.

For data disks (non-essential), this parameter prevents a chain reaction where “disk failure → entire machine won’t boot.” The cost is zero, but the benefit is avoiding a severe incident.

Verification and Troubleshooting

# Test fstab syntax and mounting (Mandatory after changes)
mount -a && echo OK

# Verify mount results
df -h
lsblk -f

# Simulate reboot to check if fstab finds the device
findmnt --verify

# Check if mount options are applied
mount | grep /data

Decision Tree

New Data Disk
├─ Confirm device name with lsblk (Don't touch system disk!)
├─ Capacity > 2TB?
│  ├─ Yes → Must use GPT
│  └─ No → GPT or MBR both work
├─ Partition: parted mklabel gpt + mkpart
├─ Format: mkfs.ext4 / mkfs.xfs
├─ Mount: mount to directory
└─ fstab (Critical)
   ├─ Backup /etc/fstab first
   ├─ Use UUID, not device name
   ├─ Add nofail for data disks
   └─ Verify with mount -a before reboot

Disk Missing After Reboot
├─ Check if UUID changed with blkid
├─ Check fstab with findmnt --verify
└─ Restore using fstab.bak

Scenario Analysis: Data Disk Disappears After Reboot

Symptom: A server had a new data disk manually mounted and working fine.
After a reboot, applications started reporting directory not found—the data is still there, but the mount relationship is gone.

1. Check if the device still exists → Block device recognition is normal, indicating the disk wasn’t lost,
   it just wasn’t mounted to the directory.
2. Confirm filesystem integrity → Partitions and filesystem are normal, can be mounted directly,
   no repair needed.
3. Manually mount to verify data integrity → Directory contents are normal after mounting, ruling out data corruption.
4. Find why auto-mount failed → Only manual mounting was done previously; no boot-time auto-mount configuration was written.
5. Add auto-mount configuration → The key is must fill in correct mount options; missing them leads to uncertain behavior during anomalies.
6. Verify configuration syntax → Use the reload command to remount based on config;
   this step catches errors before a real reboot.

# Is the device still there?
lsblk -f
fdisk -l | grep -E '^Disk /dev'

# Manually mount and confirm data integrity
mkdir -p /data
mount /dev/vdb1 /data
ls -la /data | head

# Get UUID and write to boot mount config (device names may become invalid due to order changes)
blkid /dev/vdb1
# Append line to /etc/fstab:
# UUID=obtained_value  /data  ext4  defaults,nofail  0  2

# Verify syntax without rebooting—this step cannot be skipped
mount -a
df -h | grep /data

Root Cause: Only manual mounting was performed; no boot-time auto-mount configuration was written.
Manual mounts only last until the next reboot; they are “active now” rather than “permanent.”

Two Key Takeaways:

• The acceptance criterion for mounting is not “works now,” but “persists after reboot.”
  The verification method is simple: test with mount -a after configuration, then consider rebooting.
• Recommend using UUID instead of device names in auto-mount configs.
  Device names may change with recognition order, while UUIDs correspond one-to-one with partitions;
  also add the option to prevent boot failure if mounting fails, avoiding machine startup issues if the config is wrong.

8 Common Pitfalls

1. Wrong device name: Running mkfs on the system disk destroys the system. Double-check with capacity and mount points.
2. Using MBR for disks > 2TB: Only recognizes up to 2TB; must use GPT.
3. Not writing to fstab: Mount is lost after reboot.
4. Using device names in fstab: Names may change after reboot, causing mount failure.
5. Omitting nofail: System won’t boot if the disk has issues.
6. Not backing up fstab before editing: No fallback if errors occur.
7. Rebooting without running mount -a: Syntax errors are only exposed at reboot, making them harder to fix.
8. Mount point directory doesn’t exist: Run mkdir -p first.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations services on Alibaba Cloud, Tencent Cloud, and Huawei Cloud marketplaces (service providers include our store and competitors, provided solely for reference of genuine feedback, not fictitious tickets from this site):

b****4 Rating: 5.0 Jun 23, 2025 16:57 b****4 Rating: 5.0 Jun 23, 2025 16:56 Jian****Wei Rating: 5.0 Jan 20, 2021 15:03 Tech skills are awesome, speed is fast! It turned out to be a Trojan causing global Baidu hijacking!!!!!! f****u Rating: 5.0 Jan 02, 2021 20:43 Thanks for assisting in maintaining Yuncai’s normal operation. 1****1 Rating: 5.0 Nov 20, 2020 10:03 Consistently good service as always 1****1 Rating: 5.0 Nov 17, 2020 09:13 Thanks for the consistently good service. 1****1 Rating: 5.0 Sep 25, 2020 15:42 Many thanks. 1****1 Rating: 5.0 Aug 24, 2020 15:34 Many thanks to your company’s technical staff 1****1 Rating: 5.0 Jul 24, 2020 09:49 Many thanks! 1

d****9 Rating: 5.0 Feb 15, 2023 09:11 Yong****Ying Rating: 5.0 Mar 29, 2021 11:04

1****4 Rating: 5.0 May 08, 2023 11:53 1****3 Rating: 5.0 Sep 22, 2022 22:01 r****u Rating: 5.0 Jul 07, 2020 15:05