Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

7 Answers

up vote 28 down vote accepted

IMHO the most reliable/best answer is

partprobe /dev/sdX
share|improve this answer
add comment

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.

share|improve this answer
    
hdparm worked for me. –  Prof. Falken Jun 9 '11 at 22:03
add comment

"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.

share|improve this answer
    
Some 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. –  Teddy Jul 11 '09 at 1:22
4  
The 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. –  womble Jul 11 '09 at 2:05
add comment

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.

share|improve this answer
add comment

You can also try:

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

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

share|improve this answer
3  
This does not reread the partition table. It just updates the geometry information, cache mode, etc. SCSI IDENTIFY_DRIVE is being issued. –  Dmitri Chubarov Jun 9 '12 at 8:27
add comment

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.)

share|improve this answer
add comment

If you read the manpage for 'man oracleasm-scandisks' you will note the text below. oracleasm is using /proc/partitions as the source of all scanning it performs. You must get your raw devices listed in /proc/partitions before you can do a scandisk. The Scanorder and Scanexclude parameters you place in /etc/sysconfig/oracleasm relate to the names found in /proc/partitions (!!!!).

---------- man oracleasm-scandisks ------ ...

HOW SCANNING HAPPENS The scan proceeds in four basic stages.

   First, the list of disks to scan is created. If disks were specified on the command line, this is the list.
   If not, /proc/partitions is read, and each block device is added, subject to the -o and -x options.

   Second, the partition tables of each disk in the scan are reloaded unless the -s option was specified. Any
   disks that no longer exist are dropped.

   Third, the list of disks is recreated based on the new partition tables.

   Finally, each disk in the list is checked to see if it is marked for ASM use. Disks that are marked are
   instantiated.
share|improve this answer
    
...he's mentioned nothing about using oracleasm-scandisks –  voretaq7 Apr 26 '13 at 17:45
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.