Sometimes, when resizing or otherwise mucking about with partitions on a disk, cfdisk will say:
Wrote partition table, but re-read table failed. Reboot to update table.
(This also happens with other partitioning tools, so I'm thinking this is a Linux issue rather than a cfdisk issue.) Why is this, and why does it only happens sometimes, and what can I do to avoid it?
Note: Please assume that none of the partitions I am actually editing are opened, mounted or otherwise in use.
Update:
cfdisk uses ioctl(fd, BLKRRPART, NULL)
to tell Linux to reread the partition table. Two of the other tools recommended so far (hdparm -z
DEVICE
, sfdisk -R
DEVICE
) does exactly the same thing. The partprobe
DEVICE
command, on the other hand, seems to use a new ioctl called BLKPG, which might be better; I don't know. (It also falls back on BLKRRPART if BLKPG fails.)
BLKPG seems to be a "this partition has changed; here is the new size" operation, and it looked like partprobe
called it individually on all the partitions on the device passed, so it should work if the individual partitions are unused. However, I have not had the opportunity to try it.
IMHO the most reliable/best answer is
Rereading partition table information doesn't always work, but try
or
If it works the values in /proc/partitions will change.
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:(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.)
On Centos7 :
According to https://access.redhat.com/solutions/199573
You should try :
It worked for me.
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.With all mount points unmounted, running Yocto 2.4:
Still failed to re-load the partition table after partitions had been deleted on the device. Also tried -- and failed were:
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:
And suddenly my disk is available again, without a reboot!
i'm on centos 6.5 x64 ; kernel 2.6.32 . and i'm testing the fdisk trick to resize.
All the following commands did not make kernel reread partition :
i still need a reboot to make it work
When a command like
blockdev --rereadpt /dev/sdX
fails withthis usually means that some (old) partition is indeed still somehow used by the kernel.
Possible causes/fixes:
sdX1
- is still mounted - check withmount
and umount it/dev/sdX1
is part of a software raid - checkcat /proc/mdstat
and possibly stop the relevant arrays, e.g.mdadm --stop /dev/md126
/dev/sdX1
is part of an LVM physical volume - check withpvdisplay
/vgdisplay
and possibly deactivate withvgchange
/dev/sdX1
is part of some device mapping - e.g. viacryptsetup
- check/dev/mapper
andlsblk
and possibly remove the mapping (e.g.cryptsetup luksClose
)ps
and possibly kill oneIf 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.You can also try:
(But might not work, see the comment below)