Description of problem: Creating a primary partition will often clobber the kernel/udev state of a extended partition on the same disk. This in turn messes up UDisks2 and its clients. (Yeah, I don't care about extended partitions either, but maybe this is a symptom of a more fundamental issue.) Version-Release number of selected component (if applicable): parted-3.2-3.fc21.x86_64 How reproducible: Very often, but not always. Steps to Reproduce: 1. parted /dev/sda mktable msdos 2. parted /dev/sda mkpart extended 0 10 3. parted /dev/sda mkpart primary 10 20 Actual results: # blkid -p /dev/sda1 error: /dev/sda1: No such device or address Expected results: # blkid -p /dev/sda1 dev/sda1: PTTYPE="dos" PART_ENTRY_SCHEME="dos" PART_ENTRY_UUID="dbaa606a-01" PART_ENTRY_TYPE="0xf" PART_ENTRY_NUMBER="1" PART_ENTRY_OFFSET="1" PART_ENTRY_SIZE="19531" PART_ENTRY_DISK="8:0" Additional info: This state can sometimes be cured by running "partprobe", but not always. In fact, running partprobe will most of the time move us into the broken state. Most of the time, running parted interactively cures the broken state, but not always. In one test run, this # partprobe; parted </dev/null would end up 10 times out of 10 in a broken state (blkid failing), while this # partprobe; sleep 2; parted </dev/null would end up 10 times out of 10 in the expected state.
Forgot the kernel version: 3.16.1-301.fc21.x86_64
I could also reproduce this on a second Fedora 21 installation with /dev/loop0.
Are you able to try reproducing it on F20? You should be able to rebuild the parted 3.2 srpm on f20 with no problems. I'm curious to see if this is actually a parted issue or related to the kernel. As an alternative I guess using an older kernel with f21 would work.
Also, if you are running this from a script of any kind you should be passing -s to parted, otherwise you may run into problems with it waiting for user input. Something else to do is to capture the output of udevadm monitor when this fails and see if that shows it missing any events.
(In reply to bcl from comment #3) > Are you able to try reproducing it on F20? I can't reproduce the failure on F20. Can you reproduce it on F21? I have tried four combinations of two kernels and two versions of parted, and it looks like parted 3.2 is the guilty part. Details: The test script "BUG.parted": ------8<------- dd if=/dev/zero of=/disk1.img bs=1M count=50 2>/dev/null l=$(losetup --show -f /disk1.img) parted -s $l mktable msdos parted -s $l mkpart extended 0 10 parted -s $l mkpart primary 10 20 blkid -p ${l}p1 losetup -d $l ------8<------- Test run: ------8<------- for i in $(seq 100); do bash ./BUG.parted; done 2>&1 | grep "No such device" | wc -l ------8<------- Results: kernel 3.16.1-300.fc21 3.15.10-201.fc20 parted 3.2-3.fc21 99 100 3.1-13.fc20 0 0 Thus parted 3.2 fails almost always, on both kernels. For _both_ versions of parted, I get a lot of "Buffer I/O error on device ..." messages on the console.
> I have tried four combinations of two kernels and two versions of parted, > and it looks like parted 3.2 is the guilty part. Or, parted 3.2 is the one that manages to trigger a bug in the kernel that parted 3.1 doesn't trigger. I didn't want to assign blame here, of course.
(In reply to bcl from comment #4) > Something else to do is to capture the output of udevadm monitor when this > fails and see if that shows it missing any events. The problematic part seems to be that the block device for the extended partition can't be opened. If you say that this is expected, I can check what goes wrong further up the stack.
Still unable to reproduce this, closing for now.
> INSUFFICIENT_DATA What data is missing? Could you quickly tell what you have tried? (What versions of parted you have tested on which kernel, etc?)
Running the attached BUG.parted script on Fedora 22 with kernel 4.0.0-1.fc22.x86_64 parted 3.2-5.fc22.x86_64 very easily shows the bug: # ./BUG.parted Warning: The resulting partition is not properly aligned for best performance. error: /dev/loop2p1: No such device or address I'll reopen for Fedora 22.
I haven't been able to reproduce this on f21 or 22. I may have also tried f20 originally, but don't remember.
(In reply to bcl from comment #11) > I haven't been able to reproduce this on f21 or 22. I find this hard to believe. I can reproduce this easily on all kinds of machines that have parted 3.2. If you have virt-deploy, you can try this: # virt-deploy create bugger fedora-21 Formatting 'bugger-fedora-21-x86_64.qcow2', fmt=qcow2 size=21474836480 backing_file='_fedora-21-x86_64.qcow2' encryption=off cluster_size=65536 lazy_refcounts=off [ 0.0] Examining the guest ... [ 9.0] Setting a random seed [ 9.0] Setting the hostname: vm-bugger.mvo.lan [ 9.0] Setting passwords [ 11.0] Finishing off name: bugger-fedora-21-x86_64 root password: M5qXfDLrPv2q mac address: 52:54:00:e5:55:f4 hostname: vm-bugger.mvo.lan ip address: 192.168.100.5 # virt-deploy start bugger-fedora-21-x86_64 # (wait a bit for ssh to work) # scp ~mvo/BUG.parted root.100.5: The authenticity of host '192.168.100.5 (192.168.100.5)' can't be established. ECDSA key fingerprint is b5:18:59:98:65:22:df:c8:0d:2a:36:1d:ff:26:fd:c8. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.100.5' (ECDSA) to the list of known hosts. root.100.5's password: # ssh root.100.5 root.100.5's password: [root@vm-bugger ~]# ./BUG.parted Warning: The resulting partition is not properly aligned for best performance. error: /dev/loop0p1: No such device or address [root@vm-bugger ~]#
(The ip address and root password is printed by "virt-deploy create", in case you missed that.)
ok, sorry to take so long to get back to this. I've been able to reproduce on an updated f22 system with a usb stick and sure enough, it's a parted bug. (It tries to tell the kernel that the extended partition has been resized to 2 bytes instead of 2*sector_size).
(In reply to Brian Lane from comment #14) > I've been able to reproduce > on an updated f22 system with a usb stick and sure enough, it's a parted bug. Ok, thanks! > (It tries to tell the kernel that the extended partition has been resized to > 2 bytes instead of 2*sector_size). Out of interest, do you have any idea why the bug didn't manifest itself all the time? (See comment #0) Does parted only sometimes tells the kernel wrong things?)
I'm not sure why, it is always telling it the same thing.
parted-3.2-9.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/FEDORA-2015-11681/parted-3.2-9.fc22
parted-3.2-9.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.