Ryfujk

Rereading partition table information doesn't always work, but try

hdparm -z /dev/sda

or

sfdisk -R /dev/sda

If it works the values in /proc/partitions will change.

On Centos7 :

According to https://access.redhat.com/solutions/199573

You should try :

partx -u <partition>

It worked for me.

Note: Please assume that none of the partitions I am actually editing
are opened, mounted or otherwise in use.

Given that assumption, the partition table can be successfully rescanned, and the issue won't arise. If you're getting that error, it's because the partition table is currently in use, and hence can't be re-scanned without creating inconsistencies.

It is not based on partition that you are editing.

Suppose you have only one harddisk (/dev/sda) and two partitions (/dev/sda1, /dev/sda2) and you have mounted only one partition (/dev/sda1). If you delete or change anything about other partition which is not even mounted (/dev/sda2) you will get the error that re-reading of partition table failed and kernel will use old table.

But if you have two harddisks (/dev/sda, /dev/sdb) and none of the partitions of (/dev/sdb) are in use. Then you can add / delete / resize /edit partitions of /dev/sdb and they will be re-read without any problem. But even if one partition of /dev/sdb was mounted during change. Then kernel will keep using old table.

I (the original questioner) had a situation a few days ago when none of the other answers (including partprobe /dev/sdX, currently the accepted and highest-voted answer) worked. What did work, however, was this:

blockdev --rereadpt /dev/sdX

(I don't know why this worked and the others didn't, but I'm happy it did work, as it saved me a reboot on a busy server.)

i'm on centos 6.5 x64 ; kernel 2.6.32 . and i'm testing the fdisk trick to resize.

/dev/sda1 /boot

/dev/sda2 /

All the following commands did not make kernel reread partition :

• 
  partprobe /dev/sda (warning : kernel failed to reread ....)


• 
  hdparm -z /dev/sda (BLKRRPART failed : device or resource busy)


• 
  blockdev -rereadpt /dev/sda (BLKRRPART failed : device or resource busy)


• 
  sfdisk -R /dev/sda (BLKRRPART failed : device or resource busy)

i still need a reboot to make it work

With all mount points unmounted, running Yocto 2.4:

partprobe /dev/sda 

Still failed to re-load the partition table after partitions had been deleted on the device. Also tried -- and failed were:

udevadm trigger --subsystem-match=block; udevadm settle

hdparm -z /dev/sda

blockdev --rereadpt /dev/sda

All reported similar "BLKRRPART failed : device or resource busy..." errors instructing me to reboot. Is this failure of previously working methods possibly due to the fact that udev is now under systemd control? Thinking along those lines I tried:

systemctl restart systemd-udevd.service

And suddenly my disk is available again, without a reboot!

You can also try:

echo 1 > /sys/block/sdX/device/rescan

(But won't work, see the comment below)

kpartx -a <partition> can be run two times on newly created partition .... instead of rebooting the system.

Remember to check udev service is running. This is especially useful when partprobe, hdparm, blockdev, and various other commands do not seem to make any difference what device files are available in /dev/ directory.

For me neither partprobe or blockdev solution worked. Although, this one works:

udevadm settle --exit-if-exists=/dev/sdb1

When a command like blockdev --rereadpt /dev/sdX fails with

blockdev: ioctl error on BLKRRPART: Device or resource busy

this usually means that some (old) partition is indeed still somehow used by the kernel.

Possible causes/fixes:

1. an sdX partition - say sdX1 - is still mounted - check with mount and umount it


2. 
   /dev/sdX1 is part of a software raid - check cat /proc/mdstat and possibly stop the relevant arrays, e.g. mdadm --stop /dev/md126
   


3. 
   /dev/sdX1 is part of an LVM physical volume - check with pvdisplay/vgdisplay and possibly deactivate with vgchange
   


4. 
   /dev/sdX1 is part of some device mapping - e.g. via cryptsetup - check /dev/mapper and lsblk and possibly remove the mapping (e.g. cryptsetup luksClose)


5. Race condition with some udev probing - check running processes with ps and possibly kill one

If one tool - say blockdev --rereadpt fails usually similar ones like (partx -uv, kpartx, partprobe, kpartprobe) fail in a similar way until the root cause is eliminated.