The following was filed automatically by anaconda: anaconda 14.22 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 31, in localeC ret = fn(*args, **kwds) File "<string>", line 2, in commit File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/formats/disklabel.py", line 248, in commit self.partedDisk.commit() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 1390, in destroy self.disk.originalFormat.commit() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/deviceaction.py", line 219, in execute self.device.destroy() File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devicetree.py", line 700, in processActions action.execute(intf=self.intf) File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 313, in doIt self.devicetree.processActions() File "/usr/lib64/python2.7/site-packages/pyanaconda/packages.py", line 110, in turnOnFilesystems anaconda.storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 212, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 131, in gotoNext self.moveStep() File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1190, in nextClicked self.anaconda.dispatch.gotoNext() IOException: Failed to add partition 5 (Device or resource busy)
Created attachment 458003 [details] Attached traceback automatically from anaconda.
I was installing F14 with a bootable pen drive created using unetbootin, when i select use custom layout, edit the partitions, and click write changes to disk, i get this bug.
Did you do anything involving disks before or while anaconda was running? Do you have anything mounted, whether automatically or not?
Created attachment 461878 [details] Attached traceback automatically from anaconda.
Created attachment 476930 [details] Attached traceback automatically from anaconda.
hmm i dint like the partition so i selected the first option - use all space and enabled edit layout. then in the layout i did the following: 1. deleted lv_home 2. increased lv_root to maximum size (474GB) 3. renamed lv_root to lv_`hostname -s`
*** Bug 673431 has been marked as a duplicate of this bug. ***
Created attachment 478389 [details] Attached traceback automatically from anaconda.
*** Bug 677007 has been marked as a duplicate of this bug. ***
*** Bug 677002 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > Created attachment 478389 [details] > Attached traceback automatically from anaconda. This is for ultima.ratio.regum69: You are invoking anaconda in a way that is not supported. I will assume you are using a livecd or similar. You start the installer by running the command /usr/bin/liveinst. One of the reasons you must do this is so that we can unmount any filesystems that might be mounted prior to installation.
(In reply to comment #5) > Created attachment 476930 [details] > Attached traceback automatically from anaconda. Mohammed, it looks like you are having hardware issues with your USB drive. The system log is filled with errors like this: ERR kernel:[ 619.735355] Buffer I/O error on device sda1, logical block 2621343 WARNING kernel:[ 619.735357] lost page write due to I/O error on sda1 and this: INFO kernel:[ 633.237229] sd 2:0:0:0: [sda] Unhandled error code INFO kernel:[ 633.237232] sd 2:0:0:0: [sda] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK INFO kernel:[ 633.237234] sd 2:0:0:0: [sda] CDB: Write(10): 2a 00 01 40 05 a0 00 00 f0 00
(In reply to comment #11) > (In reply to comment #8) > > Created attachment 478389 [details] > > Attached traceback automatically from anaconda. > > This is for ultima.ratio.regum69: > You are invoking anaconda in a way that is not supported. I will assume you are > using a livecd or similar. You start the installer by running the command > /usr/bin/liveinst. One of the reasons you must do this is so that we can > unmount any filesystems that might be mounted prior to installation. ok, thanks. I've tried an F15 live CD. As /usr/bin/liveinst doesn't worked (complaining it must be run from a liveCD), i've tried anaconda.
(In reply to comment #13) > ok, thanks. > I've tried an F15 live CD. As /usr/bin/liveinst doesn't worked (complaining it > must be run from a liveCD), i've tried anaconda. Yeah, it's busted -- see bug 672265 for updates on that problem.
For those of you who are hitting this bug by running liveinst on a livecd, please collect the following information from the system while it is still in the failure state, ie: right after you hit the traceback/crash: cat /proc/mounts cat /proc/swaps ls /dev/mapper cat /proc/mdstat Post the full output to this bug report. Thanks in advance.
I'm guilty of trying to use "anaconda" as an attempt as a workaround to bug 672265 when I encountered this..
@Dave Lehman # cat /proc/mounts rootfs / rootfs rw 0 0 /proc /proc proc rw,relatime 0 0 /sys /sys sysfs rw,seclabel,relatime 0 0 udev /dev devtmpfs rw,seclabel,nosuid,relatime,size=1021316k,nr_inodes=214092,mode=755 0 0 devpts /dev/pts devpts rw,seclabel,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /dev/shm tmpfs rw,seclabel,relatime 0 0 /dev/sdb1 /dev/.initramfs/live vfat ro,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0 /dev/mapper/live-rw / ext4 rw,seclabel,noatime,barrier=1,data=ordered 0 0 none /selinux selinuxfs rw,relatime 0 0 udev /dev devtmpfs rw,seclabel,nosuid,relatime,size=1021316k,nr_inodes=214092,mode=755 0 0 tmpfs /sys/fs/cgroup tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,mode=755 0 0 cgroup /sys/fs/cgroup/systemd cgroup rw,nosuid,nodev,noexec,relatime,release_agent=/lib/systemd/systemd-cgroups-agent,name=systemd 0 0 cgroup /sys/fs/cgroup/cpuset cgroup rw,nosuid,nodev,noexec,relatime,cpuset 0 0 cgroup /sys/fs/cgroup/ns cgroup rw,nosuid,nodev,noexec,relatime,ns 0 0 cgroup /sys/fs/cgroup/cpu cgroup rw,nosuid,nodev,noexec,relatime,cpu 0 0 cgroup /sys/fs/cgroup/cpuacct cgroup rw,nosuid,nodev,noexec,relatime,cpuacct 0 0 cgroup /sys/fs/cgroup/memory cgroup rw,nosuid,nodev,noexec,relatime,memory 0 0 cgroup /sys/fs/cgroup/devices cgroup rw,nosuid,nodev,noexec,relatime,devices 0 0 cgroup /sys/fs/cgroup/freezer cgroup rw,nosuid,nodev,noexec,relatime,freezer 0 0 cgroup /sys/fs/cgroup/net_cls cgroup rw,nosuid,nodev,noexec,relatime,net_cls 0 0 cgroup /sys/fs/cgroup/blkio cgroup rw,nosuid,nodev,noexec,relatime,blkio 0 0 systemd-1 /dev/mqueue autofs rw,relatime,fd=25,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /sys/kernel/debug autofs rw,relatime,fd=26,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=28,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /dev/hugepages autofs rw,relatime,fd=29,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 systemd-1 /sys/kernel/security autofs rw,relatime,fd=30,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 tmpfs /var/run tmpfs rw,rootcontext=system_u:object_r:var_run_t:s0,seclabel,nosuid,nodev,noexec,relatime,mode=755 0 0 tmpfs /var/lock tmpfs rw,rootcontext=system_u:object_r:var_lock_t:s0,seclabel,nosuid,nodev,noexec,relatime,mode=775,gid=54 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,seclabel,relatime 0 0 mqueue /dev/mqueue mqueue rw,seclabel,relatime 0 0 /dev/sdb1 /mnt/live vfat ro,relatime,fmask=0022,dmask=0022,codepage=cp437,iocharset=ascii,shortname=mixed,errors=remount-ro 0 0 varcacheyum /var/cache/yum tmpfs rw,rootcontext=system_u:object_r:rpm_var_cache_t:s0,seclabel,relatime,mode=755 0 0 /tmp /tmp tmpfs rw,rootcontext=system_u:object_r:tmp_t:s0,seclabel,relatime 0 0 vartmp /var/tmp tmpfs rw,rootcontext=system_u:object_r:tmp_t:s0,seclabel,relatime 0 0 /tmp /tmp tmpfs rw,rootcontext=system_u:object_r:tmp_t:s0,seclabel,relatime 0 0 vartmp /var/tmp tmpfs rw,rootcontext=system_u:object_r:tmp_t:s0,seclabel,relatime 0 0 /dev/mapper/live-rw /home ext4 rw,seclabel,noatime,barrier=1,data=ordered 0 0 gvfs-fuse-daemon /home/liveuser/.gvfs fuse.gvfs-fuse-daemon rw,nosuid,nodev,relatime,user_id=500,group_id=500 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 cat /proc/swaps Filename Type Size Used Priority ls /dev/mapper control live-rw cat /proc/mdstat Personalities : unused devices: <none>
Hello Dave That is strange. What I had done was my physical /dev/sda was going bad and so I bought a replacement. I then created a kvm guest and added my brand new /dev/sdb via usb to the guest to make it /dev/sda in the kvm guest and installed f14 there to allow me to migrate my data. (note the device: _model: QEMU_DVD-ROM) i just double checked the smart data on the same disk and its healthy with no errors.
Created attachment 482996 [details] Attached traceback automatically from anaconda.
Here is some additional info FYI. The net result of this effort for me has been to adopt F-14 desktop instead of F-14 XFCE. The host is an IBM G-40 laptop HD=40GB with dual-boot [MS XP-Pro is second OS]. HD partition table prior to install was: sda1=XP-OS, sda2=/boot, sda3=FAT for XP D:\, 4=expansion, sda5=/ for Linux Ubuntu8.04, sda6=/home, sda7=swap. To preserve sda1 & 3 was of paramount importance. The first attempt at F-14XFCE failed per the former posts to this bug. My HD strategy was to replace sda4 thru 7 with Virtual. Per my not-perfect memory, at the time of failure no "Formatting" pop-up windows appeared and I submitted the above attachment detail prior to reading the above. Following the post, the system booted both original OSes and all seemed well suggesting the new partition table was not written to HD prior to failure. My second attempt at F-14XFCE failed with slightly different presentation. My HD strategy this time was to preserve all partitions as-is. I requested re-format for sda2, sda5. During this work I discovered sda7 (swap) had become garbaged and the partitions table required re-definition of sda7 as swap [and re-formatted]. This time prior to failure the three pop-up windows did display "formatting" activity. Following failure I inspected alt consoles for feedback. I also attempted to submit the Comment #15 requested data. I failed to create the data, the login request caused me to abandon the attempt. Therefore I abandon the failure detail. Following this attempt, the system failed to boot [grub error 15]. My last attempt was to install F-14 live desktop instead of XFCE. It proceeded normally. Until I have further need for XFCE I will not attempt to install again. I do hope the above is of some small value.
Created attachment 485647 [details] Attached traceback automatically from anaconda.
I am getting message: :unable to find group information: problem with install tree, filed to Bugzilla 677002 677002 is closed says this bug 650064 is a duplicate. I am not sure that is true. In terminal:# yum groupinfo shows groups and symantic refreshes lists properly? my setup shows ethernet working as pci2p1 not eth0? Is Anaconda not able to handle pci2pl name? http://serverbeach1.fedoraproject.org/pub/alt/stage/15-Beta.TC1/Fedora/i386/iso/Fedora-15-Beta-i386-DVD.iso gnome2.91.93 (fallback mode) updated today: (VirtualBox 4.0.4 OSX intel i7 TC F15 DVD install to VirtualBox HD trying to install it external usb 320 GB HD) This has always worked in fedora before.
This bug is for tracking one specific error condition - the traceback you see in the original comment. Please do not just dump every single problem you are seeing into an unrelated bug. It makes it extremely difficult to track the status of things.
My traceback originally landed on bug 677002 but it was marked as closed as a duplicate of this bug. I noted this in my comments what should I have done.? the other bug was directing me here? And it is not a duplicate it now appears.: (
please re-open closed 67702 or instruct me how to deal with this.
(In reply to comment #24) > My traceback originally landed on bug 677002 but it was marked as closed as a > duplicate of this bug. I noted this in my comments what should I have done.? > the other bug was directing me here? And it is not a duplicate it now appears.: > ( The bug you filed as 677002 is very similar to this one, and neither of them is the place to discuss group information or network interface device names. In comment 22 you noted mostly things completely unrelated to this bug report -- that is why you were asked to stay on topic.
Created attachment 495994 [details] Attached traceback automatically from anaconda.
Created attachment 500221 [details] Attached traceback automatically from anaconda.
Has anyone seen this bug in Fedora 15 or later? If so, please provide logs from the failed attempt.
This message is a notice that Fedora 14 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 14. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '14' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 14 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping