Reread partition table without rebooting?
Solution 1
IMHO the most reliable/best answer is
partprobe /dev/sdX
Solution 2
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.
Solution 3
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.)
Solution 4
On Centos7 :
According to https://access.redhat.com/solutions/199573
You should try :
partx -u <partition>
It worked for me.
Solution 5
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.
Related videos on Youtube
Teddy
Updated on September 17, 2022Comments
-
Teddy over 1 year
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. Thepartprobe
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.-
Tom Hale over 7 years
man sfdisk
says:Since version 2.26 sfdisk no longer provides the -R or --re-read option to force the kernel to reread the partition table. Use blockdev --rereadpt instead.
-
-
Teddy almost 15 yearsSome partitions might be in use, but none of them are the ones that I am actually changing, though they might be in the same partition table.
-
womble almost 15 yearsThe kernel isn't that smart. If any partition in the table is in use, the kernel doesn't rescan. Getting that wrong in the other direction could be catastrophic, so it's being safe. If you want to stuff around with partitions at will, use LVM.
-
Peter Grote almost 13 yearshdparm worked for me.
-
Zachw6 almost 12 yearsThis does not reread the partition table. It just updates the geometry information, cache mode, etc. SCSI IDENTIFY_DRIVE is being issued.
-
voretaq7 about 11 years...he's mentioned nothing about using
oracleasm-scandisks
-
Mwuanno almost 10 yearsI just expanded a dev under Ubuntu Server, this dev is a hardware raid. After expanding the underlying raid using the raidcontroller, I dismounted the filesystem and tried "partprobe /dev/sda" - this did not work. "fdisk -l" still showed the old size. I then ran "hdparm -z /dev/sda" and this did the trick. I could then mount and resize my filesystem with no reboot. I know I'm not adding anything really other than YMMV.
-
Teddy about 9 yearsTwo times? Do you also run “
sync; sync; sync
”? ☺ I smell superstition… -
hookenz almost 9 yearsthe sfdisk -R option doesn't exist.
-
Max almost 9 yearsi'm on centos 6.5 ; kernel 2.6.32 . all the following commands did not make kernel reread partition : - partprobe /dev/sda (warnikg : kernel failed to reread)
-
hookenz over 8 years@Max, I've also noticed that sometimes even partprobe prints out an error that it didn't work. Sometimes a reboot is the only option to be certain. Many times it does seem to work for me though.
-
J. M. Becker over 8 yearsI think this superstition came from the fact that you check if your sync, by doing a second sync. Except that the second one is only valuable for the operator, to confirm it returns to prompt immediately, thus indicating the first sync completed as expected. a few blogs and tutorials later, and ....
-
zaqxen over 8 yearsThis did not work for me because there were some directories still mounted with --bind. The partition itself was already unmounted but the bind-mounts pointing to that partition were still there. Strange that umount worked and partprobe not, but after umounting the bind-mounts too, I could also partprobe the disk.
-
Charles Duffy over 8 years...indeed, it looks like
sfdisk -R
was removed somewhere between util-linux 2.24.2 and 2.26.1 -
NotGaeL about 8 yearsThat was the only one that work for me. Thank you so much for sharing!! Top of the day to you, sir!
-
Mike Andrews about 8 yearsThis worked for me on CentOS 6 after flagellating around with
kpartx
andudevadm trigger
for 10 minutes. Thank you! -
Tom Hale over 7 years
man sfdisk
says:Since version 2.26 sfdisk no longer provides the -R or --re-read option to force the kernel to reread the partition table. Use blockdev --rereadpt instead.
-
Fadi Asbih about 7 yearsAll the above commands did not work for me either.
-
wildhart about 7 yearsThis works even if the device is mounted. Nice! This enabled me to resize a cloud disk, then repartition and resize the ext4 partition on it without interrupting a data import process.
-
Admin almost 7 yearsI think kernel 2.6.32 has issue, I used these before on other machines, it worked just fine, even when adding partitions with higher numbers between older partitions. i.e. sdb1 sdb2 sdb3 - delete sdb2 , then sdb1 sdb4 sdb5 sdb3. In addition to above, partx, kpartx, blockdev didn't work as well.
-
maxschlepzig over 5 yearsI don't think that it's unusual that if one command fails rereading the partitions, all fail - see also my answer for how to eliminate some causes for this.
-
maxschlepzig over 5 yearsThis doesn't work if some sdX partition is part of a started software RAID array (tested under 4.18.18-300.fc29.x86_64).
-
Costin Gușă about 5 yearsThe top accepted answer is incomplete: in the modern
systemd
world, THIS is the correct answer. Please note you also need to restart one of those (or both)systemd-udev-settle
andsystemd-udev-trigger
. Restarting justsystemd-udevd
like Camp said was not enough for me. But restarting also the other two did the trick! -
user3132194 about 4 yearsThis is the only solution, that helped me on vmware vm.
-
Charles Duffy over 3 years666 on a device node is.. not particularly wise. You don't want non-administrative users going straight to the underlying block device to bypass file permissions.
-
Charles Duffy over 3 years@user3132194, I assume you'd just resized the drive? Then you need to rescan the device, not reread the partition table. They're two completely different operations, and only the partition table reread is the one that's on-topic for this question.
-
Charles Duffy over 3 yearsThis is a separate piece of (Oracle-provided) software that's reading
/proc/partitions
. The goal of this question is how to tell the kernel itself to update the data it uses to generate/proc/partitions
. -
Benji over_9000 'benchonaut' about 3 yearsfixed... 660 now ;)
-
Alex Henrie over 2 years
systemctl restart systemd-udev*
worked for me (although it printed a lot of warnings).