GNOME Bugzilla – Bug 599078
Unable to re-read partition table
Last modified: 2009-11-24 10:46:16 UTC
Originally reported at Fedora bugzilla, https://bugzilla.redhat.com/show_bug.cgi?id=529901 . Every time I start gparted it greets me with a window telling me that "The kernel is unable to re-read the partition table on ..." and also tells me that I need to unmount all partitions on the device. This is nonsense because the drive contains the root filesystem, which will be mounted in nearly all cases (livecd excluded). Also, this has never been a problem in the past? The console output is actually a bit more informative: ====================== libparted : 1.9.0 ====================== The kernel was unable to re-read the partition table on /dev/sda (Device or resource busy). This means Linux won't know anything about the modifications you made until you reboot. You should reboot your computer before doing anything with /dev/sda. Well, rebooting will of course mount some partitions on sda again. Either don't show this messages or make it that gparted cannot be used on the drive it runs from.
Thank you for posting this report. Your timing could not have been better as I have just been discussing this topic with the parted team. The last message in the thread can be found at the following link: http://lists.alioth.debian.org/pipermail/parted-devel/2009-October/003261.html GParted has contained this warning message code for quite a while. What has changed recently is the way newer versions of parted interact with the kernel and udev when committing changes to a device. Consequently GParted now displays this message frequently. In the past this message was seldom, if ever, displayed.
I tried reading up on this on the parted-devel list but it is a bit too low level for me... :) could you sum up the thread? What really got me: "In other words, isn't it risky (and worthy of a warning) to modify a partition table when one or more of its partitions is mounted?" I really wonder about this, bacause it is what I have been doing since forever, basicly... :/
Hi Michael, I just noticed that you were using parted-1.9.0. If such is the case, then I mistakenly redirected you to the mailing list discussion. That discussion involves a change that impacts BETA parted-2.0, but not parted-1.9.0. The change in question was introduced on August 28, 2009: http://git.debian.org/?p=parted/parted.git;a=commitdiff;h=1d8f9bece138e4d8e58f7b059b4195aff6f39deb;hp=d16300a88d9200e0f1e08d56e39392e028412611 Parted-1.9.0 was release on July 23, 2009 which is prior to the above change date. Hence we are likely dealing with a different problem in your situation. Would you be able to provide additional information such as your kernel version, and drive information? The following commands should provide this data. uname -a parted /path-to-your-device unit s print Also to test if your partition table can be re-read by the kernel with/without partitions mounted, use the following command: blockdev --rereadpt /path-to-your-device Where /path-to-your-device is the hard disk device path such as /dev/sda or /dev/hda.
No problem: $ uname -a Linux enigma 2.6.31.4-88.fc12.i686.PAE #1 SMP Tue Oct 20 16:33:16 EDT 2009 i686 i686 i386 GNU/Linux $ sudo parted /dev/sda unit s print Model: ATA SAMSUNG HD103UJ (scsi) Disk /dev/sda: 1953525168s Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 63s 104872319s 104872257s primary ntfs 2 104872320s 1686214529s 1581342210s extended lba 5 104872383s 209744639s 104872257s logical ext4 boot 6 209744703s 314616959s 104872257s logical ext3 7 314617023s 419489279s 104872257s logical ext2 8 419489343s 427891274s 8401932s logical linux-swap(v1) swap 9 427891338s 847332359s 419441022s logical ext3 10 847332423s 1266773444s 419441022s logical 11 1266773508s 1686214529s 419441022s logical ext3 3 1686214530s 1895927039s 209712510s primary $ sudo blockdev --rereadpt /dev/sda BLKRRPART: Device or resource busy
It looks like you are running a very recent kernel version and I believe this is the reason you are experiencing the problem. Parted-1.9.0 did contain code to "work around kernel dasd problem so we really do BLKRRPART"*. Unfortunately this appears to no longer work with recent Linux kernels. * quote taken from parted source code. I have confirmed that the work around does perform as expected for older kernels such as 2.6.24. I do not know which kernel version stopped working with this work around. Hence it would appear that you are experiencing the similar behaviour from a different angle. In other words instead of not having the work around code in parted, you have come across a situation in which the work around code no longer works. Currently GParted will display a kernel re-read warning message on each and every device scan. Device scans occur when GParted starts up, immediately after a series of actions are applied, and upon manually invoked device refreshes. I think this is excessive notification to the user. From a user interface perspective, do you think GParted should: a) only show this message on startup, b) not show the message at all, or c) some other solution that you suggest?
(In reply to comment #5) > It looks like you are running a very recent kernel version Yes, this is Fedora 12 beta (F12 will be final in about 4 weeks) > In other words instead of not having the work around code in > parted, you have come across a situation in which the work around code no > longer works. Heh :/ > From a user interface perspective, do you think GParted should: > a) only show this message on startup, > b) not show the message at all, or > c) some other solution that you suggest? Well, it really depends. I have used GParted for some years and it never seemed to cause any trouble so I am used to "no notification". The question is, what kind of operation causes problems? "Only" creating, removing or resizing partitions? What about changing labels and flags? Also, are there operations only potentially dangerous, in a "it is very unlikely that anything bad happens" or is the propability of e.g. data loss quite high?
(In reply to comment #6) > The question is, what kind of operation causes problems? "Only" creating, > removing or resizing partitions? What about changing labels and flags? I have done some preliminary testing in a virtual machine and following are the test results: When creating a new partition you will not be able to format it. This is because the kernel does not know about the new partition and hence a new device entry will not be created for it (e.g., /dev/sdb3). Deleting a partition still works, though the kernel won't know it is gone until the next reboot. Moving/Resizing of partitions is disabled and this is probably good. I can see where this would cause confusion if the partition were resized, and then subsequently mounted and used. At this point the kernel would have still have the older view of the partition and this could lead to problems regarding differences in size. This would be even worse in the case of a move because the kernel would think the file system existed in a different location. Changing labels and flags is still permitted and I don't think these changes would lead to any data corruption. Both labels and flags are small pieces of data stored at known locations in the file system and partition table respectively. > Also, are there operations only potentially dangerous, in a "it is very > unlikely that anything bad happens" or is the propability of e.g. data loss > quite high? I think the most dangerous operation would occur if moving/resizing partitions were to be allowed. Other operations should be unlikely to cause something bad to happen. With this in mind I am leaning towards removing the warning message. What are your thoughts?
I decided to remove the "kernel unable to re-read partition table" warning message because it would be displayed excessively and become annoying to users. This update has been committed to the git repository for inclusion in the next release of GParted (0.4.8). The relevant git commit can be viewed at the following link: http://git.gnome.org/cgit/gparted/commit/?id=c85de03ee31c9577ecbfeae33bd66cd254d23fbe Closing this bug.
qtparted-0.4.5-22.fc12.x86_64 parted-1.9.0-17.fc12.x86_64 gparted-0.4.6-1.fc12.x86_64 I get this warning but I'm not sure I have the version with this fix. In any case, I'm concerned that various unmounted partitions cannot be resized. This worked with FC11. Since qtparted also does not allow resizing I could conclude that parted itself is providing information to gparted that the partition cannot be resized. I don't see anything in parted startup to indicate this though. [~]$ sudo parted GNU Parted 1.9.0 Using /dev/sda Welcome to GNU Parted! Type 'help' to view a list of commands. Bottom line: GParted seems badly broken compared to previous versions. I quickly found this thread based on the text of the error message. Without the message I'd only have observed that Resize was disabled.
The ability to resize unmounted partition on a device that has at least one mounted partition is no longer possible with recent Linux kernels and parted code. It is critical that GParted be able to re-read the partition table from the kernel when performing resizing operations. The loss of this ability can cause commands to write outside of the partition boundaries because parted will have one view of the partition table and the kernel will have an older view. Hence this functionality is disabled in GParted for any drive that cannot have it's partition table re-read. With newer Linux kernels and parted code, this appears to include devices that have at least one file system mounted. This change in behaviour is due to changes outside of the GParted code base. With GParted 0.4.8 the warning message you mentioned is not displayed and GParted disables the resize menu option.
gparted-0.4.8-1.fc12 has been submitted as an update to F12 (as well as F10 and F11). Although it will probably remain in the testing repository for another week or so before being push to the stable updates repo.
Curtis, Deji - Thanks! I understand much better now.