Refresh Linux Partition Knowledge Safely with partprobe

You will finish with a cautious way to ask Linux to re-read a partition table after an approved partitioning change, including a dry run, a targeted device invocation and a post-change check. The examples use GNU parted 3.6, installed here as package parted version 3.6-4build1.

Allow about ten minutes. You need a shell, the parted package and the exact block-device path whose partition table changed. The normal operation can require elevated privileges. It does not create, resize or delete partitions: it informs the kernel about a table that has already been changed by another tool.

1. Confirm the installed command

Start with read-only checks. These do not need sudo:

$ command -v partprobe
/usr/sbin/partprobe
$ partprobe --version
partprobe (GNU parted) 3.6
$ dpkg-query -W -f='${Package} ${Version}\n' parted
parted 3.6-4build1

The local manual describes partprobe as a program that informs the operating system kernel of partition table changes. Its options are short Unix-style options, with long names available as documented equivalents. The installed help also says that omitting a device probes all partitions.

Checkpoint: identify the device, not merely one of its partitions:

$ lsblk -o NAME,TYPE,SIZE,RO,MOUNTPOINTS
NAME   TYPE  SIZE RO MOUNTPOINTS
DEVICE disk  ...

Replace DEVICE below with a real path such as /dev/sdb. Do not guess from an old inventory. A partition path such as /dev/sdb1 is not interchangeable with the disk or other whole device whose partition table was changed.

2. Preview the request

Use --dry-run when you are checking a script, reviewing a command or confirming the device path. The manual defines this option as not updating the kernel:

$ partprobe --dry-run /dev/DEVICE
$ printf 'exit status: %s\n' "$?"
exit status: 0

A successful dry run may print nothing. The useful result here is the exit status. A non-zero status means that the request was not accepted; keep the diagnostic text instead of replacing it with a generic success message.

For a first attempt on an unfamiliar host, this is the safest checkpoint because it does not ask the kernel to change its view of the device. It also does not prove that the real probe will succeed. Permissions, a busy device and the device's current state can still affect the non-dry run.

3. Probe only the changed device

After you have verified the path and the preceding partitioning operation has completed, run a targeted probe:

$ sudo partprobe /dev/DEVICE
$ printf 'exit status: %s\n' "$?"
exit status: 0

Use elevated privileges only when the host requires them. On this machine, an unprivileged probe of /dev/sda reports Error: Error opening /dev/sda: Permission denied and returns status 1. That is an access failure, not evidence that the partition table is damaged. If your account already has the required device access, omit sudo.

Do not run a broad, device-less probe as a reflex on a busy production host. The command then considers all partitions, while a named device limits the scope and makes the operation easier to review. The probe itself is not a replacement for checking that the earlier partitioning tool completed successfully.

4. Ask for a partition summary

Add --summary when you want the command to show a summary of the device and its partitions:

$ sudo partprobe --summary /dev/DEVICE
$ printf 'exit status: %s\n' "$?"
exit status: 0

The exact summary is device-dependent, so do not write a script that expects a particular line or column from it. The manual promises a summary, not a stable machine-readable format. For automation, use the exit status for the probe and a separate inventory command for structured inspection.

You can combine the two options while testing:

$ sudo partprobe --dry-run --summary /dev/DEVICE
$ printf 'exit status: %s\n' "$?"
exit status: 0

Because --dry-run means not to update the kernel, this combined command is a review step. It is not the final refresh.

5. Verify what Linux now sees

Once the real probe returns status 0, inspect the device and its partitions with a separate command:

$ lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS /dev/DEVICE
NAME       TYPE  SIZE FSTYPE MOUNTPOINTS
DEVICE     disk  ...
DEVICE1    part  ...

Compare the names and sizes with the partition table you intended to create. The output is host-specific, and a successful partprobe status only says that the probe completed; it is not a review of your partitioning design.

If a newly created partition is not visible, stop before formatting or mounting anything. Recheck the exact device path, inspect the partitioning tool's output and review kernel messages using your normal operating procedure. Do not repeatedly probe a path chosen from memory, and do not assume that a missing partition is safe to recreate.

6. Handle the common traps

• Permission denied: rerun the same targeted command with the privilege required by your system, usually through sudo. Do not make the command-wide probe your first escalation.
• No output: this can be normal for a successful probe. Check the exit status, then verify with lsblk; do not treat silence as failure.
• Wrong scope: omitting devices asks the command to probe all partitions. Name the changed device unless you have a reason to refresh everything.
• Confusing options: --dry-run suppresses the kernel update, while --summary requests displayed information. Neither option edits a partition table.

There is no undo command for a successful probe because it does not reverse the partition-table change. Recovery belongs to the partitioning operation: keep its records and backups, and do not delete or recreate a partition merely because the first kernel refresh did not show the expected result. Formatting, mounting, or changing a live service's storage path can be destructive or service-disrupting, so treat those as separate approved steps.