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
Created attachment 978831 [details] File: anaconda-tb
Created attachment 978832 [details] File: anaconda.log
Created attachment 978833 [details] File: dnf.log
Created attachment 978834 [details] File: environ
Created attachment 978835 [details] File: lsblk_output
Created attachment 978836 [details] File: nmcli_dev_list
Created attachment 978837 [details] File: os_info
Created attachment 978838 [details] File: storage.log
Created attachment 978839 [details] File: syslog
Created attachment 978840 [details] File: ifcfg.log
Created attachment 978841 [details] File: packaging.log
Created attachment 978842 [details] File: program.log
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.
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?
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.
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.
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.
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*...
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.
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?
*** This bug has been marked as a duplicate of bug 1158975 ***