Description of problem: While configuring the installation environment on a new fresh rawhide anaconda installation on toshiba chromebook 2 Version-Release number of selected component: anaconda-24.1-1 The following was filed automatically by anaconda: anaconda 24.1-1 exception report Traceback (most recent call first): File "/usr/lib64/python3.4/site-packages/parted/disk.py", line 212, in commit return self.__disk.commit() File "/usr/lib64/python3.4/site-packages/parted/decorators.py", line 42, in new ret = fn(*args, **kwds) File "/usr/lib/python3.4/site-packages/blivet/formats/disklabel.py", line 253, in commit self.partedDisk.commit() File "/usr/lib/python3.4/site-packages/blivet/devices/partition.py", line 669, in _destroy self.disk.originalFormat.commit() File "/usr/lib/python3.4/site-packages/blivet/devices/storage.py", line 491, in destroy self._destroy() File "/usr/lib/python3.4/site-packages/blivet/deviceaction.py", line 363, in execute self.device.destroy() File "/usr/lib/python3.4/site-packages/blivet/actionlist.py", line 280, in process action.execute(callbacks) File "/usr/lib/python3.4/site-packages/blivet/devicetree.py", line 380, in processActions callbacks=callbacks) File "/usr/lib/python3.4/site-packages/blivet/blivet.py", line 164, in doIt self.devicetree.processActions(callbacks=callbacks) File "/usr/lib/python3.4/site-packages/blivet/osinstall.py", line 1062, in turnOnFilesystems storage.doIt(callbacks) File "/usr/lib64/python3.4/site-packages/pyanaconda/install.py", line 195, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall, callbacks=callbacks_reg) File "/usr/lib64/python3.4/threading.py", line 868, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.4/site-packages/pyanaconda/threads.py", line 253, in run threading.Thread.run(self, *args, **kwargs) _ped.IOException: Partition(s) 8 on /dev/mmcblk0 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/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-rawhide-x86_64 quiet executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.2.0-1.fc24.x86_64 product: Fedora release: Cannot get release name. type: anaconda version: Rawhide
Created attachment 1070140 [details] File: anaconda-tb
Created attachment 1070141 [details] File: anaconda.log
Created attachment 1070142 [details] File: dnf.log
Created attachment 1070143 [details] File: dnf.rpm.log
Created attachment 1070144 [details] File: environ
Created attachment 1070145 [details] File: lsblk_output
Created attachment 1070146 [details] File: nmcli_dev_list
Created attachment 1070147 [details] File: os_info
Created attachment 1070148 [details] File: program.log
Created attachment 1070149 [details] File: storage.log
Created attachment 1070150 [details] File: syslog
Created attachment 1070151 [details] File: ifcfg.log
Created attachment 1070152 [details] File: packaging.log
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Similar problem has been detected: This bug is the same as bug 1331630 only with updated lvmpv.py so it doesn't crash totally but just like normal nice anaconda should. addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/syslinux/vmlinuz inst.repo=hd:UUID=CBE7-B1EB:/ inst.stage2=hd:UUID=CBE7-B1EB quiet inst.updates=http://vpodzime.fedorapeople.org/1331630_updates.img dnf.rpm.log: Apr 29 07:36:11 INFO --- logging initialized --- hashmarkername: anaconda kernel: 4.5.2-302.fc24.x86_64 package: anaconda-24.13.4-1 product: Fedora reason: _ped.IOException: Partition(s) 3 on /dev/md/Volume0_0 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. release: Cannot get release name. reproducible: Not sure how to reproduce the problem version: 24
Similar problem has been detected: I tried to install Fedora Server from dvd (f24 beta 1.6). I reused raid5 disk (firmware raid) where I selected to delete all. There was default installation of Fedora 24 beta 1.4. addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet dnf.rpm.log: May 04 09:15:51 INFO --- logging initialized --- hashmarkername: anaconda kernel: 4.5.2-302.fc24.x86_64 package: anaconda-24.13.4-1 product: Fedora reason: _ped.IOException: Partition(s) 3 on /dev/md/Volume0_0 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. release: Cannot get release name. reproducible: Not sure how to reproduce the problem version: 24
I propose this as beta blocker. The reasoning is the same as in bug 1332326 comment 4. Reproducers are the same as bug 1331630 only the new blivet is used (from f24 Beta 1.6). I will attach /tmp.
Created attachment 1153753 [details] tar from tmp
When this bug appears the disks are already erased. So when you restart and try to install again, there will be empty space where you want Fedora to be installed. So only thing that user have to do when he run to this issue is restart installation and try again. I'm -1 blocker for this bug because it won't be probably common issue and it has easy workaround (just restart installation). I think that Common bugs will be enough.
Convincing a chromebook to boot a Linux installation image is non-trivial. The user is already praying for the hardware not to brick itself before the end of the installation. Adding undocumented reboot steps there is hardly helpful.
pschindl: we'll probably want a new bug for your case, I think.
So I managed to hit this too, testing a default-install-on-firmware-RAID over an existing default-install-on-firmware-RAID, after zeroing my test disks to stop running into *other* bugs along the way. So I confirm pschindl's result and I think this suggests this problem is pretty reproducible: 1. Start with completely blank disks 2. Create an Intel firmware RAID set from them 3. Do a default (LVM) install of F24 Beta to the RAID set 4. Immediately reboot to the installer 5. Try again to do a default (LVM) install, using the guided partition 'Reclaim space' tool to delete all existing volumes 6. Observe crash at start of install process I also confirm pschindl's result that immediately rebooting and trying *again* works (as the volumes have been destroyed by this time), so that's a viable workaround for this case.
Discussed at a go/no-go meeting [1]. Voted as RejectedBlocker (Beta) AcceptedFreezeException (Beta) - this is annoying but it's a fairly specific scenario with an apparently safe workaround that we can document, which we reckon is sufficiently good enough for Beta [1] https://meetbot.fedoraproject.org/fedora-meeting-1/2016-05-05/f24-beta-go_no_go-meeting.2016-05-05-17.30.html
From the traceback this looks to me more as Blivet problem then error in Anaconda. So I'm changing the component here.
Please try the following updates.img: http://vpodzime.fedorapeople.org/1259953_updates.img that contains changes from the commit https://github.com/vpodzime/blivet/commit/884f3206d16adfc61372cb4712fd2cbcf1209f09 which could potentially fix these issues.
*** Bug 1447975 has been marked as a duplicate of this bug. ***
This message is a reminder that Fedora 24 is nearing its end of life. Approximately 2 (two) weeks from now Fedora will stop maintaining and issuing updates for Fedora 24. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '24'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 24 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.