Bug 449183

Apart from the type 0 issue there are already errors before that. From
the logs:

/usr/sbin/parted -s '/dev/hda' unit cyl mkpart logical ext2 4961 6135

Error: Error informing the kernel about modifications to partition /dev/hda5 -- Device or resource busy.  This means Linux won't know about any changes you made to /dev/hda5 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.

But creating the extended partition a bit earlier didn't report errors.

I take care of the set type 0 issue i bug #449205.

Petr, please have a look at the parted issue.

(In reply to comment #1 from Arvin Schnell)
> /usr/sbin/parted -s '/dev/hda' unit cyl mkpart logical ext2 4961 6135
> 
> Error: Error informing the kernel about modifications to partition /dev/hda5 --
> Device or resource busy.  This means Linux won't know about any changes you
> made to /dev/hda5 until you reboot -- so you shouldn't mount it or use it in
> any way before rebooting.

When I last saw this error, it was caused by the 'desynchronization' between on-disk partition table and it's representation as seen by the kernel (/proc/partitions).

This does not seem to be the same case since 'parted print' and 'cat /proc/partitions' report the same partition layout on /dev/hda before the first parted warning.

Another strange thing is that despite parted's warning the kernel seems to be well informed about new partition (it shows up in /proc/partitions).

Looking into the kernel sources shows that the only thing that may trigger this error (ioctl() returning EBUSY) are overlapping partitions... 

Any ideas?

(In reply to comment #3 from Petr Uzel)
> Looking into the kernel sources shows that the only thing that may trigger this
> error (ioctl() returning EBUSY) are overlapping partitions...

The above is not true - there are also other codepaths that I've missed previously. Nothing that might help to diagnose what's wrong here, though.

*** Bug 465355 has been marked as a duplicate of this bug. ***

*** Bug 456674 has been marked as a duplicate of this bug. ***

I have found a solution to this problem:
https://bugzilla.redhat.com/show_bug.cgi?id=441244

The patch proposed there solves the 'error informing the kernel' issue, but as noted in some of the comments, it might break installation of the bootloader (it will not be able to see EBR's). Jozef Uhliarik is going to test it.

Fix submitted to Factory. Since it does not solve the issue completely (see [1]), I'm not going to close this for now, but decrease it's severity & priority.

[1] http://www.mail-archive.com/parted-devel@lists.alioth.debian.org/msg02130.html

*** Bug 471279 has been marked as a duplicate of this bug. ***

I used the qemu virtual machine procedure I [1] outlined in the description 
of 471279 with the latest openSUSE factory ISO in place of the OpenSUSE11.1 dvd.

I used the factory mirror that the factory iso itself discovered over the
network for the packages.

I was unable to verify this change because factory is tipping over during
the resize (failing before we get to this problem).  I'll go search for bugs
on that and possibly file one.

In the mean time, I'd be happy to verify this change in the future if someone
pings me. Now that I have the virtualized procedure set up, testing this issue
isn't terribly time consuming.

I have a bit of a passion for this problem because I fell in love with how
easy opensuse made it to resize the windows partition and I'd like to see
it work end-to-end.

[1] I've now started to use erikj@tdkt.org for non-work-related linux fun

The BLKPG ioctl calls (those causing troubles) have been removed from parted development branch, so this bug can be closed.

[*] http://www.mail-archive.com/bug-parted@gnu.org/msg02802.html