Bug 1135493
Summary: | parted clobbers in-memory state of extended partitions | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Marius Vollmer <mvollmer> |
Component: | parted | Assignee: | Brian Lane <bcl> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 22 | CC: | agk, bcl, mvollmer, stefw |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | parted-3.2-8.fc22 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-07-22 18:11:00 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 1139380 |
Description
Marius Vollmer
2014-08-29 13:08:25 UTC
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. |