refresh partition table

Harald Becker ralda at
Mon May 16 16:29:12 UTC 2011

 Hallo David!

On 16.05.2011 18:05, David Henderson wrote:
> On 05/16/2011 11:20 AM, David Henderson wrote:
>> On 05/16/2011 11:09 AM, David Henderson wrote:
>>> On 05/16/2011 10:52 AM, David Henderson wrote:
>>>> On 05/15/2011 04:27 PM, Sergey Naumov wrote:
>>>>> blockdev --rereadpt
>>>>> Sergey Naumov.
>>>> I've run into an interesting problem by using the above syntax. 
>>>> Apparently when I issue that command "blockdev --rereadpt
>>>> /dev/sde", it removes all the device's partition files (e.g.
>>>> /dev/sde1) and leaves the one for the drive itself (e.g.
>>>> /dev/sde).  If I unplug the device and plug it back in, the correct
>>>> device files populate again.  So it appears that mdev is working
>>>> right, but the blockdev is not.  Any ideas why blockdev would be
>>>> doing this?
>>>> Dave
>>> Just to add a few more details.  I have a card reader that occupies
>>> /dev/sda through /dev/sdd.  If I insert an SD card with 2 partitions
>>> and wait for mdev to populate the device files, wait a few seconds,
>>> then issue the blockdev command, it wipes out those partition files
>>> too (e.g. /dev/sdb1).  If I issue the blockdev command on the device
>>> files for the card reader that don't have any inserted media, I get
>>> the error message "blockdev: can't open '/dev/sda': No medium
>>> found".  This tells me that blockdev can actually see if a device is
>>> present and that the devices files are populated correctly.  I just
>>> have no idea why it wouldn't be working correctly.  I've also tried:
>>> # hdparm -z /dev/sde
>>> /dev/sde:
>>> So you can see that it's failing too.  I think, however, hdparm
>>> isn't the best choice to use for USB attached devices.  Thoughts
>>> anyone?
>>> Dave
>> Even more details - I wanted to see what dmesg was giving me, so I
>> browsed the output, tried the blockdev command again and noticed that
>> for every attempt at running it, I get the following entry appended
>> to the dmesg output:
>> sd 5:0:0:0: [sde] Assuming drive cache: write through
>>  sde: sde1
>> So perhaps blockdev is working correctly, there just happens to be a
>> problem getting the device files to populate.  Are the device files
>> created by blockdev itself as opposed to a helper of some type (e.g.
>> mdev)?
>> Dave
> Ok, I thought I'd narrowed it down to a problem in the mdev processing
> script.  Since blockdev seemed like it was working correctly (per the
> output of dmesg), I decided to take a shot and change the mdev rule
> from using my script to just simply creating the device files on it's
> own (e.g. >%1).  Once I made that change and re-ran blockdev, the
> device files were populated correctly.  So... it appears as though
> there was a problem with the custom mdev script when creating the
> devices.  I have, however, tested and tested this script (not to say
> it's 100% bug free) so I decided to output the environment once again
> as a start to troubleshooting.  To my surprise I realized that the
> blockdev call is triggering both the add and remove actions of mdev. 
> This is why the device files were being removed (as part of the file
> system cleanup upon detaching devices).  Is this a bug in the blockdev
> or mdev applets?  I can't imagine why the add and remove actions would
> be triggered upon running a partition re-read via blockdev.  Thoughts?

IMHO wrong mailing list ... ask this the kernel guys.

blockdev just triggers partition reread in kernel, and doesn't deal with
device files either. mdev is a simple hotplug handler, called whenever
the kernel needs some help from a user space program to finish device
changes (etc). Neither of those programs is the originator of the
trouble you described.

... in my eyes that hotplug-ing stuff isn't perfect yet (not to call it
buggy in some cases) ... one of the reasons why I try to stay at more
statical solutions, at least where possible ... but those decisions are
like philosophy or religion, they depend on what you believe.


More information about the busybox mailing list