Bug 825500 - DeviceError: ('device has not been created', '/dev/dm-3')
DeviceError: ('device has not been created', '/dev/dm-3')
Status: CLOSED DUPLICATE of bug 826492
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
17
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Anaconda Maintenance Team
Fedora Extras Quality Assurance
abrt_hash:8c44d5aca383ee6b7f42cb4ef11...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-26 19:05 EDT by David Robertson
Modified: 2012-09-21 16:11 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-18 13:03:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: anaconda-tb-6rtFBS (501.10 KB, text/plain)
2012-05-26 19:06 EDT, David Robertson
no flags Details
Richard's anaconda-tb-wVxWNe (334.84 KB, text/plain)
2012-06-06 15:36 EDT, Richard Schwarting
no flags Details

  None (edit)
Description David Robertson 2012-05-26 19:05:55 EDT
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
Comment 1 David Robertson 2012-05-26 19:06:05 EDT
Created attachment 587047 [details]
File: anaconda-tb-6rtFBS
Comment 2 Matt Clarkson 2012-06-01 09:03:55 EDT
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.
Comment 3 David Lehman 2012-06-01 10:45:26 EDT
(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.
Comment 4 David Lehman 2012-06-01 10:46:46 EDT
(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.
Comment 5 Matt Clarkson 2012-06-02 08:24:57 EDT
(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
Comment 6 Richard Schwarting 2012-06-06 15:26:51 EDT
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.
Comment 7 Richard Schwarting 2012-06-06 15:36:35 EDT
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.
Comment 8 Richard Schwarting 2012-06-06 15:38:00 EDT
Er, error in my comment above.
"it skips this" => it encounters this error
Comment 9 Richard Schwarting 2012-06-06 15:58:01 EDT
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.
Comment 10 David Lehman 2012-06-06 18:26:43 EDT
(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.
Comment 11 David Lehman 2012-06-06 18:29:59 EDT
(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.
Comment 12 Paul W 2012-06-08 06:15:09 EDT
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.
Comment 13 David Lehman 2012-06-18 13:03:42 EDT

*** This bug has been marked as a duplicate of bug 826492 ***

Note You need to log in before you can comment on or make changes to this bug.