Bug 1135493 - parted clobbers in-memory state of extended partitions
Summary: parted clobbers in-memory state of extended partitions
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: parted
Version: 22
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Brian Lane
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1139380
TreeView+ depends on / blocked
 
Reported: 2014-08-29 13:08 UTC by Marius Vollmer
Modified: 2015-07-29 01:45 UTC (History)
4 users (show)

Fixed In Version: parted-3.2-8.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-22 18:11:00 UTC


Attachments (Terms of Use)

Description Marius Vollmer 2014-08-29 13:08:25 UTC
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.

Comment 1 Marius Vollmer 2014-08-29 13:09:05 UTC
Forgot the kernel version: 3.16.1-301.fc21.x86_64

Comment 2 Marius Vollmer 2014-08-29 13:36:05 UTC
I could also reproduce this on a second Fedora 21 installation with /dev/loop0.

Comment 3 Brian Lane 2014-08-29 16:24:04 UTC
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.

Comment 4 Brian Lane 2014-08-29 17:56:08 UTC
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.

Comment 5 Marius Vollmer 2014-09-04 12:38:22 UTC
(In reply to bcl@redhat.com 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.

Comment 6 Marius Vollmer 2014-09-04 12:42:14 UTC
> 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.

Comment 7 Marius Vollmer 2014-09-05 06:53:00 UTC
(In reply to bcl@redhat.com 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.

Comment 8 Brian Lane 2015-04-30 19:14:12 UTC
Still unable to reproduce this, closing for now.

Comment 9 Marius Vollmer 2015-05-04 07:14:29 UTC
> 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?)

Comment 10 Marius Vollmer 2015-05-04 07:33:07 UTC
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.

Comment 11 Brian Lane 2015-05-04 18:06:15 UTC
I haven't been able to reproduce this on f21 or 22. I may have also tried f20 originally, but don't remember.

Comment 12 Marius Vollmer 2015-05-05 07:05:40 UTC
(In reply to bcl@redhat.com 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@192.168.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@192.168.100.5's password: 
# ssh root@192.168.100.5
root@192.168.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 ~]#

Comment 13 Marius Vollmer 2015-05-05 07:08:27 UTC
(The ip address and root password is printed by "virt-deploy create", in case you missed that.)

Comment 14 Brian Lane 2015-06-05 18:41:27 UTC
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).

Comment 15 Marius Vollmer 2015-06-15 08:58:33 UTC
(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?)

Comment 16 Brian Lane 2015-06-15 20:40:27 UTC
I'm not sure why, it is always telling it the same thing.

Comment 17 Fedora Update System 2015-07-22 17:45:39 UTC
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

Comment 18 Fedora Update System 2015-07-29 01:45:50 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.