Bug 1180913

Summary: IOException: Partition(s) 2 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 ...
Product: [Fedora] Fedora Reporter: Sandra McCann <scmccann2000>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: anaconda-maint-list, awilliam, g.kaviyarasu, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Unspecified   
Whiteboard: abrt_hash:aefa773b2dc15883b93379bedc1be2c6446bbf1cadec52b49db5eda858b0d0d3
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-25 18:33:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
File: anaconda-tb
none
File: anaconda.log
none
File: dnf.log
none
File: environ
none
File: lsblk_output
none
File: nmcli_dev_list
none
File: os_info
none
File: storage.log
none
File: syslog
none
File: ifcfg.log
none
File: packaging.log
none
File: program.log none

Description Sandra McCann 2015-01-11 19:25:42 UTC
Description of problem:
Testing 64 bit netinstall for Fedora 22-Rawhide 01/07/2015 image.

Platform - MacBook 2,1 - OS X 10.6.8, 4G RAM
 VM - Attempting netinstall in VirtualBox 4.3.20, with 2G RAM and 20G disk space allocated.

Anaconda comes up and I get to the point of adding root password, etc while it sets up the installation environment.

Failed twice, the first time it locked up my laptop so could not get a bug report, but it got to the point of:
 "creating ext4 on /dev/mapper/fedora-root" before it hung.

This time, it is hung at 'Setting up the installation environment".

Version-Release number of selected component:
anaconda-22.14-1

The following was filed automatically by anaconda:
anaconda 22.14-1 exception report
Traceback (most recent call first):
  File "/usr/lib64/python2.7/site-packages/parted/disk.py", line 215, in commit
    return self.__disk.commit()
  File "/usr/lib64/python2.7/site-packages/parted/decorators.py", line 41, in new
    ret = fn(*args, **kwds)
  File "/usr/lib/python2.7/site-packages/blivet/formats/disklabel.py", line 269, in commit
    self.partedDisk.commit()
  File "/usr/lib/python2.7/site-packages/blivet/devices/partition.py", line 665, in _destroy
    self.disk.originalFormat.commit()
  File "/usr/lib/python2.7/site-packages/blivet/devices/storage.py", line 538, in destroy
    self._destroy()
  File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 346, in execute
    self.device.destroy()
  File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 361, in processActions
    action.execute(callbacks)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 356, in doIt
    self.devicetree.processActions(callbacks)
  File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 207, in turnOnFilesystems
    storage.doIt(callbacks)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 187, in doInstall
    turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg)
  File "/usr/lib64/python2.7/threading.py", line 766, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 227, in run
    threading.Thread.run(self, *args, **kwargs)
IOException: Partition(s) 2 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.

Additional info:
addons:         com_redhat_kdump
cmdline:        /usr/bin/python  /sbin/anaconda
cmdline_file:   BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-rawhide-x86_64 quiet
dnf.rpm.log:    Jan 11 19:09:09 INFO --- logging initialized ---
executable:     /sbin/anaconda
hashmarkername: anaconda
kernel:         3.19.0-0.rc3.git2.1.fc22.x86_64
product:        Fedora"
release:        Cannot get release name.
type:           anaconda
version:        Fedora

Comment 1 Sandra McCann 2015-01-11 19:25:45 UTC
Created attachment 978831 [details]
File: anaconda-tb

Comment 2 Sandra McCann 2015-01-11 19:25:46 UTC
Created attachment 978832 [details]
File: anaconda.log

Comment 3 Sandra McCann 2015-01-11 19:25:47 UTC
Created attachment 978833 [details]
File: dnf.log

Comment 4 Sandra McCann 2015-01-11 19:25:48 UTC
Created attachment 978834 [details]
File: environ

Comment 5 Sandra McCann 2015-01-11 19:25:49 UTC
Created attachment 978835 [details]
File: lsblk_output

Comment 6 Sandra McCann 2015-01-11 19:25:50 UTC
Created attachment 978836 [details]
File: nmcli_dev_list

Comment 7 Sandra McCann 2015-01-11 19:25:51 UTC
Created attachment 978837 [details]
File: os_info

Comment 8 Sandra McCann 2015-01-11 19:25:52 UTC
Created attachment 978838 [details]
File: storage.log

Comment 9 Sandra McCann 2015-01-11 19:25:54 UTC
Created attachment 978839 [details]
File: syslog

Comment 10 Sandra McCann 2015-01-11 19:25:55 UTC
Created attachment 978840 [details]
File: ifcfg.log

Comment 11 Sandra McCann 2015-01-11 19:25:56 UTC
Created attachment 978841 [details]
File: packaging.log

Comment 12 Sandra McCann 2015-01-11 19:25:57 UTC
Created attachment 978842 [details]
File: program.log

Comment 13 Sandra McCann 2015-01-11 21:15:28 UTC
forgot to mention - the install attempt was for Fedora workstation.  I repeated the install for the default of fedora server and that seems to have completed with no errors.

Comment 14 Adam Williamson 2015-01-12 16:53:59 UTC
the difference between the two is likely live vs. non-live, not actually workstation vs. server.

What was on the disk prior to the attempt to install Workstation? can you still reproduce this if you try again to install Workstation, over Server in the same VM, or in a new VM?

Comment 15 Adam Williamson 2015-01-12 17:13:16 UTC
ah, you used the netinst image both times - so I guess what happened is you just needed a second attempt, it probably didn't matter what package set you picked.

Comment 16 Adam Williamson 2015-01-12 17:30:34 UTC
Tried to reproduce this in the most obvious way (just install over an existing default F21 install) but couldn't, there must be something more specific about it.

Comment 17 David Lehman 2015-01-12 17:58:07 UTC
Probably related to the pre-existing lvm that was on the disk, which would have been cleared by this attempt, thus allowing the second attempt to succeed. It probably has something to do with lvmetad or, more likely, systemd or udev holding the PV (sda2) open when we try to remove the partition.

Comment 18 Adam Williamson 2015-01-12 18:03:29 UTC
yeah, that's what I figured - but when you install over an existing F21 there's an existing LV called 'fedora', right? So there must have been something odd/unique about this person's specific existing install or the VBox environment or *something*...

Comment 19 Sandra McCann 2015-01-14 14:11:32 UTC
Answering from a few comments back:

The initial attempt failed 3x. The first time it was a new VM so nothing else was present afaik.  The two times after that on workstation, there was a 'reclaim space' option when selecting the same disk so I used that.

For the attempt that succeeded (4th try) with cloud server default, again, I picked the same disk and did a reclaim space.

I tried now with a new VM for workstation and that did install all the way. I'm not getting the GUI after rebooting, but I'm guessing that's something to do with a netinstall that I need to dig up on. (My first netinstall...does it show :-)

I will try to reproduce by using the same disk that failed and will post results here.

Comment 20 Sandra McCann 2015-01-15 00:50:40 UTC
Okay used the same virtual disk as the first time and the workstation install worked.  I can't reproduce this problem.

Should I close this ticket?

Comment 21 David Shea 2015-02-25 18:33:17 UTC

*** This bug has been marked as a duplicate of bug 1158975 ***