The following was filed automatically by anaconda: anaconda 11.5.0.57 exception report Traceback (most recent call first): File "/usr/lib/anaconda/storage/formats/__init__.py", line 289, in setup raise FormatSetupError("invalid device specification") File "/usr/lib/anaconda/storage/formats/swap.py", line 118, in setup DeviceFormat.setup(self, *args, **kwargs) File "/usr/lib/anaconda/storage/__init__.py", line 1581, in turnOnSwap device.format.setup() File "/usr/lib/anaconda/upgrade.py", line 313, in upgradeMountFilesystems anaconda.id.storage.fsset.turnOnSwap(anaconda, upgrading=True) File "/usr/lib/anaconda/dispatch.py", line 205, in moveStep rc = stepFunc(self.anaconda) File "/usr/lib/anaconda/dispatch.py", line 128, in gotoNext self.moveStep() File "/usr/lib/anaconda/dispatch.py", line 227, in currentStep self.gotoNext() File "/usr/lib/anaconda/gui.py", line 1372, in setScreen (step, anaconda) = self.anaconda.dispatch.currentStep() File "/usr/lib/anaconda/gui.py", line 1534, in setup_window self.setScreen() File "/usr/lib/anaconda/gui.py", line 1544, in run self.setup_window(runres) File "/usr/lib/anaconda/gui.py", line 1292, in run self.icw.run (self.runres) File "/usr/bin/anaconda", line 965, in <module> anaconda.intf.run(anaconda) FormatSetupError: invalid device specification
Created attachment 346327 [details] Attached traceback automatically from anaconda.
This was done using an uptodate Fedora 10. I'm trying to test F11-preview and yum didn't let me get there, so I tried preupgrade which is great until anaconda fails.
Looks like it didn't like the swap line in /etc/fstab. This notebook didn't have swap partition, so I created a swapfile which does as a swap filesystem. Does anaconda actually read the original /etc/fstab file to look for a swap partition? I'll comment out the swap line in /etc/fstab and try again.
OK, found the source of the error. I had this line in /etc/fstab /home/swapfile swap swap defaults 0 0 Commented out the line and right now anaconda is upgradeing my system. Now, why didn't anaconda ignore that line after the error occured?
*** This bug has been marked as a duplicate of bug 496529 ***
You can try my proposed fix by adding updates=http://dlehman.fedorapeople.org/updates-503830.img to the kernel command line when booting the installer. Please let me know how it goes.
Is an internet connection needed? Is there a way to doenload the image, maybe to /boot/upgrade/ and use instead updates=hd:UUID=adbbd5f0-5fdd-496e-a832-5d868255bc71:/boot/upgrade/updates-503830.img
Created attachment 346771 [details] Attached traceback automatically from anaconda.
*** Bug 504450 has been marked as a duplicate of this bug. ***
Seems this still happens with the provided updates image.
I was using an encrypted swap partition, if I disable that it works fine. Here's my config when it was failing, VolGroup00/LogVol02 is /home, also encrypted but using luks. /etc/fstab: UUID=ee5052b2-e92c-471d-aa52-b8b1eb76d84d /home ext3 defaults 0 0 UUID=83c47f1f-fef0-4be6-a56c-cdf2d835799a / ext3 defaults 1 1 UUID=75704042-de87-4899-98a0-4a5419a06a11 /boot ext3 defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 #/dev/VolGroup00/LogVol00 swap swap defaults 0 0 /dev/mapper/swap swap swap detaults 0 0 /etc/crypttab: luks-VolGroup00-LogVol02 /dev/mapper/VolGroup00-LogVol02 none swap /dev/VolGroup00/LogVol00 /dev/random swap,cipher=aes-cbc-essiv:sha256
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Created attachment 347060 [details] New report
Tried it again with another F10 server I have, with the exact same swapfile line in /etc/fstab and got the same result, obviously using the update-505850.img
Created attachment 347179 [details] Attached traceback automatically from anaconda.
In my case, it appears it was a result of having two swap lines in /etc/fstab, the first of which was wrong (referred to a non-existent volgroup). I'm not quite sure how that line got there, since anaconda is the only thing that's ever edited that file, but that's another issue. Removing the bad swap line solved the problem for me. Presumably: (1) when the system is up and running, the kernel ignores any attempt to use non-existent swap space; (2) anaconda should do the same. This is rather similar to Comment #4.
Created attachment 347836 [details] Attached traceback automatically from anaconda.
Created attachment 348689 [details] Attached traceback automatically from anaconda.
Created attachment 350228 [details] Attached traceback automatically from anaconda.
Created attachment 351214 [details] Attached traceback automatically from anaconda.
My variation of this bug was the installer not detecting/finding/activating my "whole disk" PV on /dev/sdb . My swap volume is /dev/vg1/swap -- vg1 is on sdb.
(In reply to comment #21) > My variation of this bug was the installer not detecting/finding/activating my > "whole disk" PV on /dev/sdb . My swap volume is /dev/vg1/swap -- vg1 is on sdb. We do not currently support the use of whole-disk formatting other than disklabels in anaconda, although support for this is planned for F12.
(In reply to comment #19) > Created an attachment (id=350228) [details] > Attached traceback automatically from anaconda. Your problem was identified and resolved in anaconda-12.0-1, and is slightly different from the other reporters'.
(In reply to comment #23) > (In reply to comment #19) > > Created an attachment (id=350228) [details] [details] > > Attached traceback automatically from anaconda. > > Your problem was identified and resolved in anaconda-12.0-1, and is slightly > different from the other reporters'. I have this problem when I was trying to upgrade to Fedora 11 (Leonidas) from Fedora 10. It happened after it appeared to download all the files it needs. I was holding off on upgrading. So should I try the upgrade again now or should I patch anaconda to 12.0.1 and then try the upgrade?
Created attachment 354255 [details] Attached traceback automatically from anaconda.
Bug appeared during upgrade from not uptodate F10 x86_64 (kernel version locked on 2.6.27.9-159 to prevent a bug with lvm support on my system - cf 481761) to Leonidas. Will try to disable swap in fstab first and then to remove version lock.
Disabling swap in fstab allowed me to run preupgrade with no more bug.
(In reply to comment #27) > Disabling swap in fstab allowed me to run preupgrade with no more bug. While you have hit the same bug reported here, you also have another problem. There is a typo in your /etc/fstab file. The swap file '/dev/SAmsung500G/swap' will not be successfully activated on any linux system since it does not exist. (Note "SAmsung" instead of "Samsung")
Yeah, I've noticed it during post-install and correct it. In fact, I've had to modify manually my fstab with a SysRescueCD due to a problem with /dev/dm-X (instead of /dev/vg/lv) in fstab which prevents the original F10 kernel to boot too. The typo comes from there. But I don't know where the problem wui /dev/dm-X naming came from. It seems to appear during my first attempt to upgrade. Very strange.
That is a relatively common problem. One should never use /dev/dm-X in fstab or anywhere else. These device names depend on the order in which device-mapper devices are created/activated, so they are not at all guaranteed to remain the same across reboots or upgrades. The persistently named devices in /dev/mapper/ are best.
This should have been fixed in anaconda-12.4-1. Please reopen it if you see this behavior in anaconda-12.4-1 or later.
Created attachment 359525 [details] Attached traceback automatically from anaconda.
Created attachment 359526 [details] Attached traceback automatically from anaconda.
Created attachment 412599 [details] Attached traceback automatically from anaconda.