Description of problem: trying to install from LIVE USB to another USB Version-Release number of selected component: anaconda-core-24.13-1.fc24.x86_64 The following was filed automatically by anaconda: anaconda 24.13-1 exception report Traceback (most recent call first): File "/usr/lib/python3.5/site-packages/blivet/devices/storage.py", line 697, in _setFormat raise errors.DeviceError("cannot replace active format", self.name) File "/usr/lib/python3.5/site-packages/blivet/devices/storage.py", line 742, in <lambda> lambda d,f: d._setFormat(f), File "/usr/lib/python3.5/site-packages/blivet/deviceaction.py", line 669, in apply self.device.format = None File "/usr/lib/python3.5/site-packages/blivet/devicetree.py", line 324, in registerAction action.apply() File "/usr/lib/python3.5/site-packages/blivet/devicetree.py", line 276, in recursiveRemove self.registerAction(ActionDestroyFormat(leaf)) File "/usr/lib/python3.5/site-packages/blivet/blivet.py", line 608, in recursiveRemove self.devicetree.recursiveRemove(device) File "/usr/lib64/python3.5/site-packages/pyanaconda/ui/gui/spokes/lib/resize.py", line 425, in _recursiveRemove self.storage.recursiveRemove(device) File "/usr/lib64/python3.5/site-packages/pyanaconda/ui/gui/spokes/lib/resize.py", line 450, in _scheduleActions self._recursiveRemove(device) blivet.errors.DeviceError: ('cannot replace active format', 'sde1') Additional info: cmdline: /usr/bin/python3 /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img root=live:CDLABEL=Fedora-WS-Live-24_A-7 rd.live.image rd.live.check quiet executable: /sbin/anaconda hashmarkername: anaconda kernel: 4.5.0-0.rc7.git0.2.fc24.x86_64 other involved packages: python3-blivet-1.19-1.fc24.noarch, anaconda-gui-24.13-1.fc24.x86_64 product: Fedora release: Fedora release 24 (Twenty Four) type: anaconda version: 24
Created attachment 1151186 [details] File: anaconda-tb
Created attachment 1151187 [details] File: anaconda.log
Created attachment 1151188 [details] File: environ
Created attachment 1151189 [details] File: journalctl
Created attachment 1151190 [details] File: lsblk_output
Created attachment 1151191 [details] File: nmcli_dev_list
Created attachment 1151192 [details] File: os_info
Created attachment 1151193 [details] File: program.log
Created attachment 1151194 [details] File: storage.log
Created attachment 1151195 [details] File: ifcfg.log
Apr 26 22:44:51 localhost udisksd[1078]: Mounted /dev/sde1 at /run/media/liveuser/ASUSLAPTOP on behalf of uid 1000 Looks like it was mounted. You need to eject it before you can install to it. And I think it's really about time we detect things like this and fail gracefully so I'm going to work on that.
Brian, thanks for solving this error. Unmounting the device allowed installation to proceed.
Proposed as a Freeze Exception for 24-final by Fedora user bcl using the blocker tracking app because: This would reduce the number of errors reported because live mounted partitions on the target device.
https://github.com/rhinstaller/anaconda/pull/613
Similar problem has been detected: Booted F24 Beta 1.4 Server netinst, tried to install over existing firmware RAID install (likely an F23 or F24 install). addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=Fedora-S-dvd-x86_64-24 quiet dnf.rpm.log: May 02 18:33:33 INFO --- logging initialized --- hashmarkername: anaconda kernel: 4.5.2-302.fc24.x86_64 package: anaconda-24.13.4-1 product: Fedora reason: blivet.errors.DeviceError: ('cannot replace active format', 'Volume0_0p2') release: Cannot get release name. reproducible: Not sure how to reproduce the problem version: 24
Created attachment 1153041 [details] my anaconda.log Adding my logs, since this may not be the same case. Here's anaconda.log
Created attachment 1153042 [details] my program.log
Created attachment 1153043 [details] my storage.log
Created attachment 1153044 [details] my anaconda-tb (with logs stripped)
Nominating as a Beta blocker for my case, possible violation of "The installer must be able to detect and install to hardware or firmware RAID storage devices." in the case of a firmware RAID with an existing Fedora install. Will re-test this a couple of times to verify.
adamw, yours is ultimately caused by a duplicate vg: 22:33:24,895 INFO program: Running [21] lvm lvchange -an fedora/home --config= devices { preferred_names=["^/dev/mapper/", "^/dev/md/", "^/dev/sd"] filter=["r|/sdc1$|","r|/sdc2$|","r|/sdc3$|"] } log {level=7 file=/tmp/lvm.log} ... 22:33:24,911 INFO program: stdout[21]: 22:33:24,913 INFO program: stderr[21]: Multiple VGs found with the same name: skipping fedora Use the VG UUID with --select vg_uuid=<uuid> 22:33:24,913 INFO program: ...done [21] (exit code: 1280) So rather than having a filesystem mounted it is a pv with an active lvm stack on it. We should be able to detect that. We have code to detect it which used to work, in fact.
hum, so see also https://bugzilla.redhat.com/show_bug.cgi?id=1332321 , which I hit when I tried to re-test this. starting from this point, I went into the Intel RAID interface, destroyed the RAID set, re-created it (with the same name and settings), proceeded to do a successful F24 install which saw the set as empty, then tried immediately to install over *that* install, and ran into 1332321, where it seemed to be somehow finding both the 'fedora' VG from the install I'd just done *and* the 'fedora' VG from the previous successful install, way back at F23 Final time, before I destroyed the RAID set...
Lets open bugs for both those new issues and keep this limited to mounted partitions.
Both? I filed bugs for everything mentioned in #c22 already. I can file a new bug for #c15 if that's what you meant?
My case here was caused, I think, by one of the disks in the RAID set having stale LVM metadata from when I did a test install to that disk alone, so the installer was seeing a 'fedora' VG from then. I'm gonna remove the blocker nomination for this particular scenario as it's kind of a corner case.
Discussed during the 2016-05-30 blocker review meeting: [1] Decision to classify this an AcceptedFreezeException was made as a fix would eliminate certain crashes during installation. [1] https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2016-05-30/f24-blocker-review.2016-05-30-16.01.txt
*** Bug 1341273 has been marked as a duplicate of this bug. ***
anaconda-24.13.6-1.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-b0494cdc04
anaconda-24.13.6-1.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-b0494cdc04
anaconda-24.13.6-1.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1337014 has been marked as a duplicate of this bug. ***
Similar problem has been detected: multipath installation under KVM addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: root=live:https://kojipkgs.fedoraproject.org/compose/24/Fedora-24-20160614.0/compose/Server/x86_64/os/images/install.img dnf.rpm.log: Jun 15 08:12:08 INFO --- logging initialized --- hashmarkername: anaconda kernel: 4.5.5-300.fc24.x86_64 package: anaconda-24.13.7-1 product: Fedora reason: _ped.IOException: Partition(s) 2 on /dev/mapper/mpatha 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
Dan, could you open a new bug and attach the logs? Thanks!
Dan: btw, I couldn't reproduce the crash when following the procedure on your blog: http://sharkcz.livejournal.com/12846.html I ran an install using the qemu-kvm command there (as current virt-manager refuses to boot if you attach two SCSI disks with the same serial number), like this: qemu-kvm -m 2048 -device virtio-scsi-pci,id=scsi -drive if=none,id=hda,file=/share/data/isos/vms/desktop_test_1.qcow2,serial=0001 -device scsi-hd,drive=hda -drive if=none,id=hdb,file=/share/data/isos/vms/desktop_test_1.qcow2,serial=0001 -device scsi-hd,drive=hdb -cdrom /share/data/isos/24/Final/RC-1.2/Fedora-Server-dvd-x86_64-24-1.2.iso and it's working fine, no crash. Thanks for documenting that approach, btw :)
Yeah, I will open a new bug. IMHO anaconda/ABRT (?) should ask whether to open a new bug when the duplicate has been already closed. The installation succeeds when the disk image is new (zero-ed or wipefs-ed), but fails (for me) when reusing it for second time. I've used virt-manager on F-22
"Yeah, I will open a new bug. IMHO anaconda/ABRT (?) should ask whether to open a new bug when the duplicate has been already closed." It'd be libreport...I can see that, but I can also see it leading to some unnecessary dupes... "The installation succeeds when the disk image is new (zero-ed or wipefs-ed), but fails (for me) when reusing it for second time. I've used virt-manager on F-22" Yeah, I suspected that would be it. It's similar to my case where I had a RAID set built out of disks which had stale metadata on them, I guess.
*** Bug 1381757 has been marked as a duplicate of this bug. ***
Similar problem has been detected: F25 on USB stick. Try to install F24 over that using autopart + reclaim space -> delete all. This is the final live workstation ISO. cmdline: /usr/bin/python3 /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-base cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz root=live:CDLABEL=Fedora-WS-Live-24-1-2 rd.live.image quiet hashmarkername: anaconda kernel: 4.5.5-300.fc24.x86_64 other involved packages: python3-blivet-1.20.3-1.fc24.noarch, anaconda-gui-24.13.7-1.fc24.x86_64 package: anaconda-core-24.13.7-1.fc24.x86_64 packaging.log: product: Fedora reason: blivet.errors.DeviceError: ('cannot replace active format', 'sdc1') release: Fedora release 24 (Twenty Four) reproducible: Not sure how to reproduce the problem version: 24
Similar problem has been detected: When I am trying to install fedora 24 workstation x86-64 in Lenovo T430s I am not able to create user. addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: initrd=/distrotrees/72961/initrd method=http://download.eng.pnq.redhat.com/pub/fedora/linux/releases/24/Workstation/x86_64/os/ repo=http://download.eng.pnq.redhat.com/pub/fedora/linux/releases/24/Workstation/x86_64/os/ BOOT_IMAGE=/distrotrees/72961/kernel dnf.rpm.log: Nov 18 06:49:31 INFO --- logging initialized --- hashmarkername: anaconda kernel: 4.5.5-300.fc24.x86_64 package: anaconda-24.13.7-1 product: Fedora reason: _ped.IOException: Input/output error during write on /dev/sda release: Cannot get release name. reproducible: Not sure how to reproduce the problem version: 24
Similar problem has been detected: I tried to install Fedora25 after a MacOS Sierra partition on a macbook pro (2015) and I encountered the same crash (see Bug 1393985). Before I installed a fresh MacOS Sierra, I was using El Capitan, and Fedora 24 managed to install very well. Then, I decided to try again a complete fresh install with MacOS Sierra, and Fedora 24 and it crashes the same way as when I tried Fedora 25. I'm sure it is because of some changes in MacOS Sierra bootloader addons: com_redhat_kdump cmdline: /usr/bin/python3 /sbin/anaconda cmdline_file: BOOT_IMAGE=/images/pxeboot/vmlinuz inst.stage2=hd:LABEL=Fedora-WS-dvd-x86_64-24 quiet dnf.rpm.log: Nov 28 06:02:47 INFO --- logging initialized --- hashmarkername: anaconda kernel: 4.5.5-300.fc24.x86_64 package: anaconda-24.13.7-1 product: Fedora reason: blivet.errors.FSError: mount failed: 32 release: Cannot get release name. reproducible: Not sure how to reproduce the problem version: 24