Bug 729640 - IOException: Partition(s) 3 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further
Summary: IOException: Partition(s) 3 on /dev/sda have been written, but we have been u...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 17
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:c7c9befd9826bf6ea3d904c134a...
: 730862 731212 751449 768110 (view as bug list)
Depends On:
Blocks: 494832
TreeView+ depends on / blocked
 
Reported: 2011-08-10 12:54 UTC by bsfmig
Modified: 2013-05-10 00:40 UTC (History)
32 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-05-10 00:40:33 UTC


Attachments (Terms of Use)
anaconda log from test in comment 34 (186.39 KB, text/plain)
2012-03-05 19:30 UTC, Patrick C. F. Ernzer
no flags Details
Comment (713.85 KB, text/plain)
2011-08-18 13:56 UTC, bsfmig
no flags Details

Description bsfmig 2011-08-10 12:54:51 UTC
abrt version: 2.0.5
executable:     /usr/bin/python
hashmarkername: anaconda
kernel:         3.0.0-1.fc16.x86_64
product:        Fedora
reason:         IOException: Partition(s) 3 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.
time:           Wed Aug 10 20:53:32 2011
version:        16

description:
:The following was filed automatically by anaconda:
:anaconda 16.14.3 exception report
:Traceback (most recent call first):
:  File "/usr/lib64/python2.7/site-packages/parted/disk.py", line 213, in commit
:    return self.__disk.commit()
:  File "/usr/lib64/python2.7/site-packages/parted/decorators.py", line 32, in new
:    ret = fn(*args, **kwds)
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/disklabel.py", line 263, in commit
:    self.partedDisk.commit()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 1547, in _destroy
:    self.disk.originalFormat.commit()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 825, in destroy
:    self._destroy()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 286, in execute
:    self.device.destroy()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 316, in processActions
:    action.execute(intf=self.intf)
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 383, in doIt
:    self.devicetree.processActions()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/packages.py", line 122, in turnOnFilesystems
:    anaconda.storage.doIt()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 348, in dispatch
:    self.dir = self.steps[self.step].target(self.anaconda)
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 235, in go_forward
:    self.dispatch()
:  File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1198, in nextClicked
:    self.anaconda.dispatch.go_forward()
:IOException: Partition(s) 3 on /dev/sda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use.  As a result, the old partition(s) will remain in use.  You should reboot now before making further changes.

Comment 1 bsfmig 2011-08-10 13:00:07 UTC
It's an Alpha3-RC3 live CD. Previously I ran an anaconda on the same session (w/o reboot) but it failed. When attempting to re-run anaconda, it crashes writing out new partition table.

Comment 2 Chris Lumens 2011-08-10 14:11:09 UTC
Please attach the complete /tmp/anaconda-tb-* to this bug report.

Comment 3 Brian Lane 2011-08-17 00:57:09 UTC
*** Bug 730862 has been marked as a duplicate of this bug. ***

Comment 4 Brian Lane 2011-08-17 00:57:44 UTC
*** Bug 731212 has been marked as a duplicate of this bug. ***

Comment 5 Robert Lightfoot 2011-08-17 20:25:39 UTC
For my duplicate of this 731212 it occurred when I was going from an already formatted drive with LVM to a non-LVM layout called for by the ks.  Will try and repeat but the reboot went ahead and installed.

Comment 6 David Lehman 2011-08-18 01:27:24 UTC
(In reply to comment #5)
> For my duplicate of this 731212 it occurred when I was going from an already
> formatted drive with LVM to a non-LVM layout called for by the ks.  Will try
> and repeat but the reboot went ahead and installed.

The kickstart partitioning looks fine to me. You are the only reporter not using live media, so yours may be a different issue.

I think the problem here, at least for the non-live case, is fedora-storage-init.target. It starts all the raid arrays, lvm volume groups, &c it can, which is undesirable in the installer environment. Now I just need to figure out how to keep it from running there.

Comment 7 bsfmig 2011-08-18 13:56:27 UTC
Created attachment 915359 [details]
Comment

(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).

Comment 8 bsfmig 2011-08-18 13:59:51 UTC
Sorry, but due to a misoperation, I indeed attached the content of anaconda-tb-G0g9Qb file instead of uploading it as an attachment.

Comment 9 David Lehman 2011-08-18 15:13:15 UTC
(In reply to comment #8)
> Sorry, but due to a misoperation, I indeed attached the content of
> anaconda-tb-G0g9Qb file instead of uploading it as an attachment.

Why are you running anaconda directly? You should be running liveinst.

Comment 10 bsfmig 2011-08-18 16:21:45 UTC
it is a reproduce.
yes, when i first reported the issue a week ago, i first ran anaconda as a hobby act (to discover its options) ,when the first anaconda process failed, i used liveinst --lang=zh_CN to get a simplified chinese installer interface.

Comment 11 birger 2011-08-29 13:16:35 UTC
In my case I ran from the live cd (386), did a yum install wipe and wiped the disk before starting the installer. I did not mount the disk in any way. Just ran a quick wipe on /dev/sda

After a reboot the install went through smoothly.

Comment 12 David Lehman 2011-08-30 21:43:34 UTC
Can anyone attach a /tmp/anaconda-tb-* file from an occurrence of this that began by running liveinst?

Comment 13 David Lehman 2011-09-01 18:53:16 UTC
My expectation is that this will be resolved, for most of you, in F16-Beta.TC1. The fix was a change to lorax which appeared in lorax-16.4.2-1.

Comment 14 Chris Murphy 2011-10-10 04:25:56 UTC
Still 100% reproducible in the currently available beta (from fedoraproject.org homepage) Fedora-16-Beta-x86_64-Live-Desktop.iso.

1. Boot from the Live CD.
2. dd for a few seconds to zero out the beginning of the drive.
3. Run installer (Install to Harddrive).
4. Accept US English, Basic Storage...

resulting message: We could not detect partitions or filesystem on this disk.

5. Choose "Yes, discard any data" keeping the "apply my choice to all...." checked.
6. Name computer, set time zone, set password.
7. Installation type "Use All Space" keeping "Use LVM" checked.
8. Confirm partitioning options dialog by clicking on "Write changes to Disk"

Exception occurs.

If I reverse steps 1 and 2, the problem does not occur.

Comment 15 Brian Lane 2011-10-10 22:42:20 UTC
What happens if you run partprobe after step 2?

Comment 16 Chris Murphy 2011-10-10 23:26:00 UTC
So much for 100% reproducible. Yesterday it was each of 6 times with the original sequence in #14, and not reproducible each of 6 times with 1 and 2 reversed. Today, neither reproduces the exception. Kooky. Bug in the electricity.

Comment 17 Chris Murphy 2011-10-10 23:56:48 UTC
Strange and funny because it was anaconda that found this BUG ID when I gave it bugzilla login information to self-report the exception, which kept happening while I was testing installs; blowing away previous installations with dd each time. And seemingly doing the exact same thing today - nothing. Same hardware, same LiveCD disk.

Comment 18 Brian Lane 2011-11-07 18:13:01 UTC
*** Bug 751449 has been marked as a duplicate of this bug. ***

Comment 19 Brian Lane 2011-11-07 22:16:02 UTC
summary:
biosboot on 2 drives results in an error because the kernel thinks something is still using one of the partitions.

/boot on RAID does not work with grub2

Comment 20 Adam Williamson 2011-11-08 04:58:25 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 21 Adam Williamson 2011-11-08 05:15:41 UTC

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 22 Brian Lane 2011-11-08 18:16:30 UTC
Ok, more information on this. The problem isn't the biosboot partitions.

This error is reproducible if you re-install over the top of a pre-existing RAID partitioning scheme. It is activating the partitions before it tries to re-partition things. This can be checked by looking at the output of cat /proc/mdstat

A workaround is to use mdadm --zero-subperblock /dev/sdX on the component partitions of the array to remove the metadata and re-try the install.

Comment 23 Brian Lane 2011-12-16 01:56:38 UTC
*** Bug 768110 has been marked as a duplicate of this bug. ***

Comment 24 Paul Alesius 2012-02-29 20:57:33 UTC
Still happens in Fedora 17 Alpha, while I try to install it from the HD and try to re-format the entire disk.

Comment 25 Patrick C. F. Ernzer 2012-03-02 16:14:57 UTC
adjusting release based on comment #24

Comment 26 Paul Alesius 2012-03-02 16:46:07 UTC
Actually, this happens to me when trying to do an install on btrfs subvolumes on an encrypted partition; Automatic bug reporting tool said this was a duplicate, despite the error being DeviceCreateError('could not find disk (or something like tat', 'f17')

My kickstart:

clearpart --all --drives=sda --initlabel 

part biosboot --fstype=biosboot --ondisk=sda --size=1
part /boot --asprimary --size=512 --fstype=ext4 --ondisk=sda
part swap --fstype=swap --ondisk=sda --size=4096
part btrfs.01 --asprimary --encrypted --passphrase="pass" --fstype=btrfs --ondisk=sda --size=1 --grow

btrfs none --data=0 --metadata=1 --label=f17 btrfs.01
btrfs / --subvol --name=root LABEL=f17
btrfs /home --subvol --name=home LABEL=f17

Comment 27 Patrick C. F. Ernzer 2012-03-02 16:54:35 UTC
(In reply to comment #26)
> Actually, this happens to me when trying to do an install on btrfs subvolumes
> on an encrypted partition;
[...]

It seems you ran into http://fedoraproject.org/wiki/Common_F17_bugs#Installation_crashes_if_btrfs_chosen_as_format_for_any_target_partition.2C_or_any_btrfs-formatted_partition_is_already_present_on_a_target_disk
which would be bug 787341

Comment 28 Paul Alesius 2012-03-02 17:56:41 UTC
Patrick, I had several anaconda errors while trying multiple installation methods with btrfs, If I remember correctly the method which I described caused the error for me which abrt suggested was already reported here. In any case, abrt (prhaps erroneously) added me automatically to this bug report on F17.

Comment 29 David Lehman 2012-03-02 19:03:15 UTC
This should be resolved for the md case in anaconda-17.8-1 by commit 9cf40ae163610c2ef042d63.

Comment 30 Patrick C. F. Ernzer 2012-03-03 19:56:33 UTC
Thanks David. I presume 17.8 will make it into beta and I'll retest then. If this can be put into an updates.img, I'll be happy to test before beta comes out.

Comment 31 Patrick C. F. Ernzer 2012-03-04 16:39:16 UTC
ignore my last comment; F17 Alpha comes up stating 'anaconda 17.11'.
David, can you please clarify, I am now unsure what you meant by comment 29

Comment 32 David Lehman 2012-03-05 13:50:59 UTC
(In reply to comment #31)
> ignore my last comment; F17 Alpha comes up stating 'anaconda 17.11'.
> David, can you please clarify, I am now unsure what you meant by comment 29

The case where this particular bug is caused by preexisting md devices being auto-started by udev/systemd should be handled better in anaconda-17.8.

The case in comment 28 is related to btrfs and is generally not relevant to this bug report AFAICT. If it included logs I might be able to verify this, but it does not.

Patrick, is that clear enough for you? I'm not sure what the source of your confusion is. Are you saying (without saying) that you are seeing this problem in F17 Alpha?

Comment 33 Patrick C. F. Ernzer 2012-03-05 17:03:58 UTC
David,

(In reply to comment #32)
> (In reply to comment #31)
> > ignore my last comment; F17 Alpha comes up stating 'anaconda 17.11'.
> > David, can you please clarify, I am now unsure what you meant by comment 29
> 
> The case where this particular bug is caused by preexisting md devices being
> auto-started by udev/systemd should be handled better in anaconda-17.8.

OK, re-testing is for me to do then. I ran into what looked like autostarted md devices when doing repeated kickstarts of a KVM guest with 2 defined disks (I was trying to see how /boot on RAID1 was going in 17 Alpha).

Upon seeing comment 24 I made wrong assumptions and stopped my testing. Clearly my bad.

[...]
> Patrick, is that clear enough for you? I'm not sure what the source of your
> confusion is. Are you saying (without saying) that you are seeing this problem
> in F17 Alpha?

Yes, much clearer. It means I need to retest (dropping /boot on RAID1 from the test), as opposed to wait for F17 beta (which I had understood first). Thanks for the clarification.

Comment 34 Patrick C. F. Ernzer 2012-03-05 19:28:53 UTC
David,

re-tested. I still can not kickstart with the following partition setup twice in a row;

[start part of kickstart]
clearpart --all

part biosboot        --fstype=biosboot --size=1    --ondisk=vda
part /boot           --fstype=ext4     --size=500  --ondisk=vda
part raid.bigonvda              --grow --size=4096 --ondisk=vda
part raid.bigonvdb              --grow --size=4096 --ondisk=vdb

raid pv.bigstripe --level=0 --device=md0 raid.bigonvda raid.bigonvdb

volgroup vg_bz729640 --pesize=32768 pv.bigstripe

logvol swap --name=lv_swap --vgname=vg_bz729640 --size=4224
logvol / --fstype=ext4 --name=lv_slash_f17_alpha --vgname=vg_bz729640 --size=10240

bootloader --location=mbr --timeout=5 --driveorder=vda,vdb --append="rhgb quiet"
[end]

The installation was started with
[start]
label F17-x86_64-raid-ks
  MENU LABEL Fedora 17 ^RAID x86_64 kickstart
  TEXT HELP
This will WIPE all your DISKS
  ENDTEXT
  IPAPPEND 2
  kernel images/F17-Alpha-x86_64/vmlinuz
  append initrd=images/F17-Alpha-x86_64/initrd.img ks=ftp://hp-microserver.internal.pcfe.net/pub/kickstart/F17-alpha-raid-x86_64-ks.cfg rd.luks=0 rd.md=0 rd.dm=0 ksdevice=bootif root=live:http://hp-microserver/pub/redhat/Fedora/linux/releases/test/17-Alpha/Fedora/x86_64/os/LiveOS/squashfs.img
[end]
rd.luks=0 rd.md=0 rd.dm=0 added because of bug 7887744

extract from virsh dumpxml of the used KVM guest
[start]
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/VG_morn/KVM_F17-Alpha'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>
    <disk type='block' device='disk'>
      <driver name='qemu' type='raw'/>
      <source dev='/dev/VG_morn/KVM_F17-Alpha-2nd-disk'/>
      <target dev='vdb' bus='virtio'/>
      <alias name='virtio-disk1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/>
    </disk>
[end]

the error I get is
DeviceTreeError: MD RAID device md127 not in devicetree after scanning all slaves

I'll attach the full log momentarily

Comment 35 Patrick C. F. Ernzer 2012-03-05 19:30:46 UTC
Created attachment 567724 [details]
anaconda log from test in comment 34

note to self: if full tarball requested, morn:/home/pcfe/tmp/abrt-upload-2012-03-05-19:24:18-773.tar.gz

Comment 36 David Lehman 2012-03-05 20:14:43 UTC
That bug ("device ... not in devicetree after scanning all slaves") should be better handled in anaconda-17.12-1, which has not yet been built. It is caused by a somehow broken md array's presence on the system. At some point, something decided that starting broken/incomplete arrays was a good idea, and anaconda has had to play catch-up and decide how to deal with them. More systemd/udev love.

Comment 37 bsfmig 2012-03-11 23:08:47 UTC
It seems that unmounting /mnt/sysimage/* manually after a failed anaconda session helped to avoid the issue. I found it when trying to upgrade an existing Fedora 16 to 17 by running anaconda in another installed Fedora 17 Beta-TC1.

(ps.Just append "upgradeany enforcing=0" in kernel parameter and run
su -c 'anaconda --repo=http://mirrors.sohu.com/fedora/development/17/x86_64/os/ --selinux --noipv6'
in gnome-terminal and it seems to be working.
I just want to use neither preupgrade nor a burned DVD.)

Comment 38 bsfmig 2012-03-11 23:17:31 UTC
ps2.For F16->17, additionally run 
dracut --force --add convertfs
before actually upgrading.

Comment 39 David Lehman 2012-03-15 15:40:21 UTC
(In reply to comment #37)
> It seems that unmounting /mnt/sysimage/* manually after a failed anaconda
> session helped to avoid the issue. I found it when trying to upgrade an
> existing Fedora 16 to 17 by running anaconda in another installed Fedora 17
> Beta-TC1.
> 
> (ps.Just append "upgradeany enforcing=0" in kernel parameter and run
> su -c 'anaconda --repo=http://mirrors.sohu.com/fedora/development/17/x86_64/os/
> --selinux --noipv6'
> in gnome-terminal and it seems to be working.
> I just want to use neither preupgrade nor a burned DVD.)

You are running anaconda to upgrade the same system it is running from? This is not, never has been and, most likely will never be supported. If you try this and it breaks you will be on your own to sort it out.

Comment 40 bsfmig 2012-03-15 15:56:59 UTC
(In reply to comment #39)
> (In reply to comment #37)
> > It seems that unmounting /mnt/sysimage/* manually after a failed anaconda
> > session helped to avoid the issue. I found it when trying to upgrade an
> > existing Fedora 16 to 17 by running anaconda in another installed Fedora 17
> > Beta-TC1.
> > 
> > (ps.Just append "upgradeany enforcing=0" in kernel parameter and run
> > su -c 'anaconda --repo=http://mirrors.sohu.com/fedora/development/17/x86_64/os/
> > --selinux --noipv6'
> > in gnome-terminal and it seems to be working.
> > I just want to use neither preupgrade nor a burned DVD.)
> 
> You are running anaconda to upgrade the same system it is running from? This is
> not, never has been and, most likely will never be supported. If you try this
> and it breaks you will be on your own to sort it out.

I'm not that foolish. It's in another Fedora 17 installation where I performed the upgrade from F-16 to F-17.

Comment 41 David Lehman 2012-04-12 16:02:11 UTC
To be clear, this is caused by trying to use disks for install that contain devices already in use somewhere on the system. That could be any of: mounted filesystems, active swap space, active md arrays, active lvm, active luks. Find what's mounted/active and deactivate it before starting the installer. It could be from previously failed install attempts on live media or it could be from systemd or udev or udisks automatically starting everything they can find. We're working on handling this automatically, but it's hard to keep up with all the various software that is bent on automatically starting everything it can.

Comment 42 Herbert Carl Meyer 2012-04-12 17:50:59 UTC
Second try, being careful about checking for mounts, succeeded. This is an experiment, an external disk box, used by two different laptops, booted thru USB. I had F17 Alpha working until this morning. It would not boot this AM, so I downloaded and burned the beta. Updates are in progress.
Laptop in use has an old Nvidia GeoForce 520. It has been working with VESA and gnome3, now the Noveau driver seems to start, but gnome3 is not working. 
Experiment continues.

Comment 43 Mads Kiilerich 2012-04-12 18:14:03 UTC
Some of these reports could seem to have something in common with Bug 758159 "Loop devices not detachable/detached after umount" ... especially the cases where a livecd with cups was used.

Comment 44 Adam Williamson 2013-05-10 00:40:33 UTC
So, this report got pretty confused and messy and then mostly died. It looks like two or three different bugs were fixed along the way, and the report is now dormant. Doesn't seem to be much point in keeping it open: let's close it. If anyone has a case which is still problematic with F19, it would probably be best filed as a new report. Thanks!


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