libreport version: 2.0.10 cmdline: /usr/bin/python /usr/sbin/anaconda executable: /usr/sbin/anaconda exnFileName: /tmp/anaconda-tb-6rtFBS hashmarkername: anaconda kernel: 3.3.4-5.fc17.x86_64 other involved packages: product: Fedora release: Cannot get release name. time: Sat 26 May 2012 11:00:29 PM UTC version: 17 anaconda-tb-6rtFBS: Text file, 513127 bytes description: :The following was filed automatically by anaconda: :anaconda 17.29 exception report :Traceback (most recent call first): : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 702, in _preSetup : raise DeviceError("device has not been created", self.name) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/devices.py", line 718, in setup : if not self._preSetup(orig=orig): : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2012, in _parseOneLine : device.setup() : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2112, in parseFSTab : device = self._parseOneLine((devspec, mountpoint, fstype, options, dump, passno)) : File "/usr/lib64/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1676, in mountExistingSystem : fsset.parseFSTab(anaconda=anaconda) : File "/usr/lib64/python2.7/site-packages/pyanaconda/upgrade.py", line 178, in upgradeMountFilesystems : mountExistingSystem(anaconda, anaconda.upgradeRoot[0], allowDirty = 0) : File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 383, in dispatch : self.dir = self.steps[self.step].target(self.anaconda) : File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 88, in return_false : func(*args, **kwargs) :DeviceError: ('device has not been created', '/dev/dm-3') environ: :LANG=en_US.UTF-8 :repo=hd::/var/cache/yum/preupgrade :TERM=linux :BOOT_IMAGE=/upgrade/vmlinuz :XAUTHORITY=/root/.Xauthority :LC_NUMERIC=C :SHLVL=0 :PYTHONPATH=/tmp/updates :LVM_SUPPRESS_FD_WARNINGS=1 :GLADEPATH=/tmp/updates/:/tmp/updates/data/ui/:ui/:/usr/share/anaconda/ui/:/usr/share/python-meh/ :GNOME_DISABLE_CRASH_DIALOG=1 :ks=hd:UUID=6a93bbc7-4645-49c9-aa8d-0c3117b9d1dd:/upgrade/ks.cfg :PWD=/ :MALLOC_PERTURB_=204 :GCONF_GLOBAL_LOCKS=1 :HOME=/tmp :PIXMAPPATH=/tmp/updates/pixmaps/:/tmp/updates/:/tmp/product/pixmaps/:/tmp/product/:pixmaps/:/usr/share/anaconda/pixmaps/:/usr/share/pixmaps/:/usr/share/anaconda/:/usr/share/python-meh/:/usr/share/icons/Fedora/48x48/apps/ :PATH=/usr/bin:/bin:/sbin:/usr/sbin:/mnt/sysimage/bin:/mnt/sysimage/usr/bin:/mnt/sysimage/usr/sbin:/mnt/sysimage/sbin:/sbin:/usr/sbin :stage2=hd:UUID=6a93bbc7-4645-49c9-aa8d-0c3117b9d1dd:/upgrade/squashfs.img :MALLOC_CHECK_=2 :DISPLAY=:1
Created attachment 587047 [details] File: anaconda-tb-6rtFBS
Just got this bug on my HP Envy 14" (2002ea) I have an encrypted hard drive and the exception occurs after I enter the password.
(In reply to comment #1) > Created attachment 587047 [details] > File: anaconda-tb-6rtFBS You really, really should never put a device like /dev/dm-3 into /etc/fstab. The number at the end there depends only on how many device-mapper devices are active when that one gets activated, so there is a good likelihood that number will change from time to time. Use the /dev/mapper/$map_name node instead, as that should remain constant.
(In reply to comment #2) > Just got this bug on my HP Envy 14" (2002ea) > > I have an encrypted hard drive and the exception occurs after I enter the > password. Please attach the /tmp/anaconda-tb-* file to this bug report if you would like some help or a workaround.
(In reply to comment #4) > (In reply to comment #2) > > Just got this bug on my HP Envy 14" (2002ea) > > > > I have an encrypted hard drive and the exception occurs after I enter the > > password. > > Please attach the /tmp/anaconda-tb-* file to this bug report if you would > like some help or a workaround. I attached the /tmp/anaconda-tb-* from the mounted fs that anaconda has to the bugzilla report but it just says that it is a duplicate of this bug and disconnects. Could you describe a process for getting the file from the preupgrade mounted fs to this webpage? Sorry for being very naive here - this is my first bug report. Matt
Matt, in Anaconda, you can do ctrl-alt-F2 to change to a terminal. From there, you could put a USB key into your machine and mount it. (If you're not sure how: You can check the device name of the USB key that you've inserted by checking the output of dmesg after inserting it. You would see about 9 lines takling about something like "[sdb]" with the last one being something like "[sdb] Attached SCSI removable disk". Your usable partition on the device would be something like /dev/sdb1. (Depending on what disks you have in your machine, your USB key could be something like sdc or sdd instead, so then /dev/sdd1, and if you have multiple partitions on it, maybe /dev/sdd2. I'll use sdb1 as an example, though.) $ mkdir /mnt/usbdisk $ mount -t auto /dev/sdb1 /mnt/usbdisk Then, copy the file asked for above to it and unmount your drive. $ cp /tmp/anaconda-tb-* /mnt/usbdisk/ $ umount /mnt/usbdisk/ Then you can reboot your machine (some machines want you to not have a USB disk in when starting, so remove it after unmounting), and attach the file here.
Created attachment 589994 [details] Richard's anaconda-tb-wVxWNe Compaq tc4400 tablet PC. I also have an encrypted home partition. If I put in the password or not, it skips this. The device error message for me is this: DeviceError: ('device has not been created', 'UUID=7e829803-b3f4-4909-954b-693d787fd84f') The fstab from F16 didn't have an entry with that UUID, but the fstab entry in Anaconda has this: UUID=7e829803-b3f4-4909-954b-693d787fd84f /boot ext4 defaults 1 2 The F16 entry for /boot was the only one with a UUID though and it was this: UUID=bf797159-28b0-4897-8528-980c7dcefe76 /boot ext4 defaults 1 2 In F16, I see: /dev/disk/by-uuid/bf797159-28b0-4897-8528-980c7dcefe76 -> ../../sda1 I'm about to try modifying my fstab entry to point to /dev/sda1. Wish me luck O_O.
Er, error in my comment above. "it skips this" => it encounters this error
That had no effect. F16's /etc/fstab: # # /etc/fstab # Created by anaconda on Thu Oct 13 16:05:51 2011 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/vg_clarity-lv_root2 / ext4 defaults 1 1 #UUID=bf797159-28b0-4897-8528-980c7dcefe76 /boot ext4 defaults 1 2 /dev/sda1 /boot ext4 defaults 1 2 /dev/mapper/luks-171b6107-e0d3-4db0-a508-cacd20bcf617 /home ext4 defaults 1 2 /dev/mapper/vg_clarity-lv_swap swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 Anaconda's /mnt/sysimage/etc/fstab: # # /etc/fstab # Created by anaconda on Thu Mar 31 11:29:18 2011 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/vg_clarity-lv_root / ext4 defaults 1 1 UUID=7e829803-b3f4-4909-954b-693d787fd84f /boot ext4 defaults 1 2 /dev/mapper/luks-171b6107-e0d3-4db0-a508-cacd20bcf617 /home ext4 defaults 1 2 /dev/mapper/vg_clarity-lv_swap swap swap defaults 0 0 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 Is /mnt/sysimage/etc/fstab supposed to be related to my system's actual one or is it relevant at all? It mentions my system's name (clarity) but it doesn't mention the correct root volume (referencing "vg_clarity-lv_root" rather than the current "vg_clarity-lv_root2" and it has a different UUID for /boot. ==UUID== From within Anaconda, I can see these uuid-disk mapping: lrwxrwxrwx. 1 root root 10 Jun 6 19:39 /dev/disk/by-uuid/bf797159-28b0-4897-8528-980c7dcefe76 -> ../../sda1 lrwxrwxrwx. 1 root root 10 Jun 6 19:39 /dev/disk/by-uuid/758e0768-f22c-48a8-919d-23054ed0707a -> ../../dm-0 lrwxrwxrwx. 1 root root 10 Jun 6 19:40 /dev/disk/by-uuid/7e1adf1b-fb25-4f7f-8c59-10bcab3e3d13 -> ../../dm-1 lrwxrwxrwx. 1 root root 10 Jun 6 19:40 /dev/disk/by-uuid/B2C4-2895 -> ../../sdb1 My actual boot is on /dev/sda1 (bf79...) but Anaconda's fstab (and the error message) references /dev/dm-1 (7e1a...). From F16, I see this: lrwxrwxrwx. 1 root root 10 6. Jun 15:44 /dev/disk/by-uuid/5bd74c64-5658-4d7a-8d86-78527a3c902a -> ../../dm-1 lrwxrwxrwx. 1 root root 10 6. Jun 15:44 /dev/disk/by-uuid/c67943e7-426d-4558-a768-697829ac3e5e -> ../../dm-0 lrwxrwxrwx. 1 root root 10 6. Jun 15:44 /dev/disk/by-uuid/bf797159-28b0-4897-8528-980c7dcefe76 -> ../../sda1 lrwxrwxrwx. 1 root root 10 6. Jun 15:44 /dev/disk/by-uuid/7e1adf1b-fb25-4f7f-8c59-10bcab3e3d13 -> ../../dm-2 lrwxrwxrwx. 1 root root 10 6. Jun 15:44 /dev/disk/by-uuid/171b6107-e0d3-4db0-a508-cacd20bcf617 -> ../../dm-3 lrwxrwxrwx. 1 root root 10 6. Jun 15:44 /dev/disk/by-uuid/e592b8fe-b6ba-40b8-bce0-9d5d106dd07e -> ../../dm-4 lrwxrwxrwx. 1 root root 10 6. Jun 15:48 /dev/disk/by-uuid/B2C4-2895 -> ../../sdb1 ==Question== Is it possible that Anaconda is somehow finding configuration for F15? Given the date on the /mnt/sysimage/etc/fstab and its name for my root partition, that seems possible? I have a vague memory of having F15 and F16 installed in parallel due to upgrading my file system to ext4 and wanting to copy things over. I may have messed things up doing that.
(In reply to comment #9) > ==Question== > > Is it possible that Anaconda is somehow finding configuration for F15? > Given the date on the /mnt/sysimage/etc/fstab and its name for my root > partition, that seems possible? I have a vague memory of having F15 and F16 > installed in parallel due to upgrading my file system to ext4 and wanting to > copy things over. I may have messed things up doing that. Anaconda has indeed mounted vg_clarity-lv_root as the to-be-upgraded root. It appears you have outsmarted preupgrade and hit this bug by having anaconda try to resolve a no-longer-existent /boot filesystem UUID to the device containing it. You can work around the issue by removing the /etc/fstab file from vg_clarity-lv_root's filesystem, which will cause anaconda to not consider it a possible upgradable root. Or you could remove that lv altogether and use the space for something else.
(In reply to comment #9) > copy things over. I may have messed things up doing that. Apparently preupgrade is the one that messed things up. This is the line in the preupgrade-generated kickstart that's supposed to tell anaconda which filesystem is the root of the system to upgrade: upgrade --root-device=UUID=None Please open a separate bug against preupgrade for this problem. Try a search first to see if there is already one open.
I got the same error because I had a line in my /etc/fstab for mounting a virtual box shared filesystem (windows host, linux guest). I just removed the line for the upgrade process. Maybe this helps someone who gets the same error.
*** This bug has been marked as a duplicate of bug 826492 ***