Description of problem:
The new partition created by parted can't be accessed without reboot. The ioctl call with parameter BLKRRPART returns EBUSY, so kernel can't rescan the partition table after changing the partition table. No partition is mounted, used as swap, raid, or pv, so it shouldn't be busy.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.# parted -s /dev/sda unit MiB print
Model: LSI MegaRAID SAS RMB (scsi)
Disk /dev/sda: 100000MiB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 0.03MiB 500MiB 500MiB primary ext3 boot
2 500MiB 40500MiB 40000MiB primary ext3
3 40500MiB 44500MiB 4000MiB primary linux-swap(v1)
<There is no 4th partition yet.>
2.parted -s /dev/sda mkpart primary 44502MiB 100000MiB
Warning: WARNING: the kernel failed to re-read the partition table
on /dev/sda (Device or resource busy). As a result, it may not reflect
all of your changes until after reboot.
3.[root@localhost ~]# partprobe
Warning: WARNING: the kernel failed to re-read the partition table on /dev/sda (Device or resource busy). As a result, it may not reflect all of your changes until after reboot.
can't see the partition new created in /proc/partitions
The new created partition can be accessed without reboot
Even without change of partition table, partprobe reports the same warning message.
This problem has been reported on Fedora 12:
Unfortunately, when I try to use systemtap to debug it, kernel panicked.
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.
** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
If you get an ebusy error something is using the disk in some way. You can try the following to find the culprit:
lsof | grep sda
Of *course* sda is in use. It will typically contain /boot, swap, and at least one LVM PV. So what? At least in RHEL5, I could add a new partition and expect it to be recognized without a reboot. (Heck, I'm pretty sure this could be done live on RHEL 3 and 4, but I don't have them handy to test.) Now if I add a new partition I have to re-boot. This is a loss of functionality that makes it more likely a customer has to re-boot a box. Why would this be OK?
Sure, everyone should be using LVM, which reduces the impact of the problem. But not everyone is.
(In reply to comment #5)
> NOTABUG? Seriously?
Yes I'm afraid so.
> Of *course* sda is in use. It will typically contain /boot, swap, and at least
> one LVM PV. So what? At least in RHEL5, I could add a new partition and expect
> it to be recognized without a reboot.
Correct, in RHEL-5 you can also change an in use partition, and parted will happily report that it had told the kernel about the changes, even though it did not. The problem with the RHEL-5 way of doing things is there was no error checking, so sometimes it worked sometimes it did not work, but did not report this.
So in Parted 2.x (2.1 I think) the code was changed from trying to be clever
to doing things the same way fdisk does them. Which is a single ioctl asking
the kernel to re-read the partition-table, which fails with -EBUSY when any partition is in use.
> Now if I add a new
> partition I have to re-boot. This is a loss of functionality that makes it more
> likely a customer has to re-boot a box. Why would this be OK?
Given the choice between silent failure and then creating for example a FS on a changed partition with the wrong size, or making it more likely a customer has to re-boot a box, the reboot option is indeed OK I'm afraid.
It appears that various RHEL6 partitioning tools have different behaviors. For example, using the graphical palimpsest tool you are able to make and use more primary partitions when RHEL6 fdisk and partprobe fail.
Why the difference between the tools?
Second, the palimpsest tool is unable make a usable extended partition without a reboot, but after the reboot is able to make logical partitions within the extended partition.
I don't see why forcing a reboot on people is a safer option. If I make an overlapping partition and run partprobe I get corruption NOW, if I create an overlapping partition and reboot I get corruption after the reboot. If we want to stoop people from shooting themselves in the foot fdisk/parted etc. should be fixed to warn about overlapping partitions.
Having to reboot a machine to add a partition should be seen as a major regression IMHO, not a NOTABUG.
*** Bug 707149 has been marked as a duplicate of this bug. ***
See comment 16.
I have re-evaluated this problem after discussing it with Jim on IRC:
1. parted 2.3 fixes this. It allows changes to unmounted partitions and blocks changes to both the disk label and mounted partitions.
2. The changes involved in getting from 2.1 to 2.3 are not simple. Back porting those changes could result in different bugs, cause problems with programs using libparted, or some other unknown.
In the interest of not breaking things that are currently working I will not be fixing this on 2.1
*** Bug 717126 has been marked as a duplicate of this bug. ***
*** Bug 783781 has been marked as a duplicate of this bug. ***
(In reply to Wander Boessenkool from comment #21)
> I don't see why forcing a reboot on people is a safer option. If I make an
> overlapping partition and run partprobe I get corruption NOW, if I create an
> overlapping partition and reboot I get corruption after the reboot. If we
> want to stoop people from shooting themselves in the foot fdisk/parted etc.
> should be fixed to warn about overlapping partitions.
> Having to reboot a machine to add a partition should be seen as a major
> regression IMHO, not a NOTABUG.
i agree with you ... i think force reboot "as a safety measure" is pointless because you in fact CAN DELETE all your partitions even while system running, the system will fail for sure at partition update or at reboot, doesnt matter .. just removes functionality
you can even totally mess up your entire disk/partition/filesystem without any warning with dd, so you can bypass this -security measure- if you want, but if you are a good admin you know what are you doing
i think fdisk/partprobe/parted/etc. would check if changing a *partition* in use not whole disk, and if so display a confirmation (think you want live repartioning your disk for system reinstallation at next reboot).. sometimes one intentionally left unpartitioned space for future use on demand .. cannot reboot because a lot of services running, but need disk space NOW
i work in a big TV station and rebooting is not an option, even get the homepage offline a couple seconds would be a catastrophe