Bug 826492
Summary: | DeviceError: ('device has not been created', '//dlink-b3b325/Volume_1') | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | jrissole | ||||||||||||||
Component: | anaconda | Assignee: | David Lehman <dlehman> | ||||||||||||||
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||
Severity: | unspecified | Docs Contact: | |||||||||||||||
Priority: | unspecified | ||||||||||||||||
Version: | 17 | CC: | anaconda-maint-list, boss2kfr, chris, dkdietlein, dwrobertson1504, g.kaviyarasu, jim.cromie, jonathan, levi.darby, mattyclarkson, neteler, techtonik, vanmeeuwen+fedora, wjstarrsiii | ||||||||||||||
Target Milestone: | --- | ||||||||||||||||
Target Release: | --- | ||||||||||||||||
Hardware: | x86_64 | ||||||||||||||||
OS: | Unspecified | ||||||||||||||||
Whiteboard: | abrt_hash:55f20e6bafd5efe92917a65c5af12946ccd5c8ecc15914d95bf262ca270bdecb | ||||||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||
Doc Text: | Story Points: | --- | |||||||||||||||
Clone Of: | Environment: | ||||||||||||||||
Last Closed: | 2013-08-01 17:00:28 UTC | Type: | --- | ||||||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||||||
Documentation: | --- | CRM: | |||||||||||||||
Verified Versions: | Category: | --- | |||||||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||
Embargoed: | |||||||||||||||||
Attachments: |
|
Description
jrissole
2012-05-30 10:50:11 UTC
Created attachment 587678 [details]
File: anaconda-tb-bUvSle
Workaround: hash out NFS mounted filesystems in /etc/fstab Created attachment 588026 [details]
anaconda report
Anaconda coundn't upgrade from Fedora 16.
I tried to create a bugzilla report but it told me it is a duplicate of this one.
I have seperate /usr and /var on LVM
(In reply to comment #3) > Created attachment 588026 [details] > anaconda report > > Anaconda coundn't upgrade from Fedora 16. > > I tried to create a bugzilla report but it told me it is a duplicate of this > one. > > I have seperate /usr and /var on LVM This appears to be a failure to resolve the /dev/disk/by-uuid/ link to a real device. You can work around this error by replacing /dev/disk/by-uuid/ with UUID= in your /etc/fstab entries. Hi, I have been failing the same way with both preupgrade and via installation DVD. My home partition is encrypted. I tried the workaround in Comment 4 and replaced my /dev/mapper/luks.... with the appropriate UUID=... in my fstab. Even after doing this, I get the same error. Any other ideas? (In reply to comment #5) > Hi, I have been failing the same way with both preupgrade and via > installation DVD. My home partition is encrypted. I tried the workaround > in Comment 4 and replaced my /dev/mapper/luks.... with the appropriate > UUID=... in my fstab. > > Even after doing this, I get the same error. Any other ideas? Tried the same on another machine, this one with no encryption. All local drives in fstab already used the UUID= style. The only other thing these have in common is they are multiboot systems, both have root on sda5 and home on sda9. Both have grub2 on sda. 0 for 2. (In reply to comment #6) > (In reply to comment #5) > > Hi, I have been failing the same way with both preupgrade and via > > installation DVD. My home partition is encrypted. I tried the workaround > > in Comment 4 and replaced my /dev/mapper/luks.... with the appropriate > > UUID=... in my fstab. > > > > Even after doing this, I get the same error. Any other ideas? > > Tried the same on another machine, this one with no encryption. All local > drives in fstab already used the UUID= style. The only other thing these > have in common is they are multiboot systems, both have root on sda5 and > home on sda9. Both have grub2 on sda. 0 for 2. OK, last fun fact.. after trying one more time and actually writing down the UUID that failed during the installation, it is my swap partition. The swap partition appears in my fstab with the UUID= convention. It appears in my /dev/disks/by-uuid, but it does not show up with the blkid command. I must assume it is also the swap partition on the 2nd machine. Perhaps this means something. (In reply to comment #5) > Even after doing this, I get the same error. Any other ideas? Attach /tmp/anaconda-tb-* from the systems after the error has occurred. Attach them as plain text files -- no archives, zip, or anything like that. *** Bug 828114 has been marked as a duplicate of this bug. *** Ive fixed my error by commenting out the debugfs line in /etc/fstab upgrade from DVD is proceeding. (In reply to comment #8) > (In reply to comment #5) > > Even after doing this, I get the same error. Any other ideas? > > Attach /tmp/anaconda-tb-* from the systems after the error has occurred. > Attach them as plain text files -- no archives, zip, or anything like that. I tried again and could not figure out how to access the /tmp/anacaconda files. I ended up doing a fresh install, but noticed that when I manually configured the partitions, my swap partition that seemed to cause the failure in the upgrade (the device not created) was not recognized by anaconda as swap, but was unknown. I had to choose to format it as swap, then installation went fine. I also have been attempting to upgrade Fedora 16 to 17 (x86-64) and have hit on this same error. My fstab entries for the local disks are as follows:- /dev/mapper/VolGroup-lv_root / ext4 defaults 1 1 UUID=8983a159-b0a9-4fa2-a2b7-1dbc7aacead3 /boot ext4 defaults 1 2 UUID=63729ea5-a5f5-4adf-907b-37474bd63d35 /home ext4 defaults 1 2 UUID=9ab73cff-99ab-41ca-910f-0d37bd071113 /raidata ext3 defaults 1 2 /dev/mapper/VolGroup-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 / I cannot see where the suggested fix can be applied. (In reply to comment #12) > I also have been attempting to upgrade Fedora 16 to 17 (x86-64) and have hit > on this same error. My fstab entries for the local disks are as follows:- <snip> > I cannot see where the suggested fix can be applied. To be able to tell you which device is problematic I would need to see the error message you are receiving and probably also the traceback file (/tmp/anaconda-tb-*). There is NO traceback file that I can find with that name in /tmp. I did try to save the log, but the install program kept reporting an error whenever I pressed the Save button. Where else would this file(s) be saved? h(In reply to comment #14) > There is NO traceback file that I can find with that name in /tmp. There are no files in /tmp whose name begins with 'anaconda-tb-' ? Perhaps you can attach the output of 'ls -l /tmp'. > > I did try to save the log, but the install program kept reporting an error > whenever I pressed the Save button. You could just use scp to copy it to another machine or manually insert a removeable storage device and copy it off that way, but first you need to find the file. Created attachment 915461 [details]
Comment
(This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
(In reply to comment #16) > David > > Found the anaconda-tb* files in /root? Perhaps you are rebooting before looking for them? There is a shell on tty2 during installation. While you are looking at this error on the main installer display (on tty6) you can access the shell on tty2 by pressing ctrl+alt+f2 and from there you will find the anaconda-tb-* file in /tmp. In the future, please never paste large amounts of text into a bug like that -- add an attachment instead. These cifs mount entries are what is causing the problem. Just comment them out, do the upgrade, and uncomment them. > //saruman/userfolders /export/saruman cifs > credentials=/root/saruman_userfolders,_netdev,uid=chris_jones,gid=users 0 0 > /home/backuppc /var/lib/BackupPC none bind > //denathor/users /export/denathor cifs > credentials=/root/denathor_users,_netdev,uid=chris_jones,gid=users 0 0 > //gandalf/users /export/gandalf cifs > credentials=/root/gandalf_users,_netdev,uid=chris_jones,gid=users 0 0 > //arwen/users /export/arwen cifs > credentials=/root/arwen_users,_netdev,uid=pat_jones,gid=users 0 0 > //frodo/homes /export/frodo/homes cifs > credentials=/root/frodo_administrator,_netdev,uid=chris_jones,gid=users 0 0 > //aragorn/users /export/aragorn cifs > credentials=/root/aragorn_users,_netdev,uid=chris_jones,gid=users 0 0 > //faramir/users /export/faramir cifs > credentials=/root/faramir_users,_netdev,uid=pat_jones,gid=users 0 0 > *** Bug 832924 has been marked as a duplicate of this bug. *** *** Bug 825500 has been marked as a duplicate of this bug. *** Hi, When I try to report my issue with preupgrade it tell my thas my bug is duplicate of this. So this is my fstab : /dev/sda1 /boot ext4 defaults,noatime,discard 1 2 /dev/sda2 / ext4 defaults,noatime,discard 1 1 /dev/sdb1 /home ext4 defaults 1 2 # /dev/sdb3 /mnt/HITACHI ext4 defaults 1 2 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 none /tmp tmpfs defaults,nosuid,nodev,noexec 0 0 And the error is : DeviceError: ('device has not been created', /dev/sdb1) non-exitent 0MB storage /dev/sdb1 (14) with non existent ext4 filesystem. Could you help me please ? (In reply to comment #20) > And the error is : DeviceError: ('device has not been created', /dev/sdb1) > non-exitent 0MB storage /dev/sdb1 (14) with non existent ext4 filesystem. > > Could you help me please ? To know exactly what has happened I would need to see /tmp/storage.log (make an attachment -- please do not paste it into a comment), but most likely some device reordering has made /dev/sdb1 get a different name. The way to avoid this is to use UUID=<uuid-of-home-fs> instead of /dev/sdb1 in /etc/fstab. Created attachment 597655 [details]
as asked the file after error
When I use UUID=<uuid-of-home-fs> instead of /dev/sdb1 in /etc/fstab I have error too blkid thinks your disk sdb contains an ext4 filesystem instead of a partition table. I would recommend that you just comment out /home in /etc/fstab, do your upgrade/install, and then uncomment it. Thanks it works. Could you explain me what is the problem with my /home in fstab ? (In reply to comment #25) > Thanks it works. > > Could you explain me what is the problem with my /home in fstab ? Nothing is wrong with your /home. blkid is confused, and the fedora installer in turn gets confused into thinking sdb is not partitioned. It's arguably an installer bug, and has already been changed for F18 so this will no longer be an issue. Ok and again thanks à lot. I have been getting this similar error when I try to update to Fedora 17. I am also uploading my anaconda report from the installation failure. Can you find a way for me to work around this bug? Created attachment 608407 [details]
Here is my copy of the anaconda report regarding this bug.
Uploading my anaconda reprot regarding this bug.
Created attachment 653227 [details]
Matt Clarkson Traceback
Hi, David. I am attempting to upgrade from F16 to F17 on my laptop with encrypted root partition. I originally was directed to 825500 but it has been merged to this bug. I have attached my traceback.
Reading the comments on this bug report it seems it could be something to do with my /etc/fstab. Whilst I am logged into my F16:
/dev/mapper/luks-8fd2284a-9251-4e87-96c3-65be70d5bda2 / ext4 defaults 1 1
UUID=18f0f6c4-714c-468d-b814-d0fc4e2eddf9 /boot ext4 defaults 1 2
UUID=01451a2e-906c-46ef-ab84-6aba55ba52b5 swap swap defaults 0 0
Will you need the /tmp/storage.log to create a workaround for me?
I am happy that this has been fixed in F18 so the F17 -> F18 update will be easier :)
Matt
(In reply to comment #30) > Matt Clarkson Traceback > > Hi, David. I am attempting to upgrade from F16 to F17 on my laptop with > encrypted root partition. I originally was directed to 825500 but it has > been merged to this bug. I have attached my traceback. The swap device referenced in your /etc/fstab does not exist. Comment that line out and try the upgrade again. You may get grief for not having any swap space. That got preupgrade working. It did it's thing, I sat there whilst the progress bar all went up. Then it rebooted and my grub only shows my last three fedora 16 entries, no fedora 17 or anything. Jumped into F16 and it cannot connect to the network and loads of things are missing in /sbin etc. Looks like a messed up upgrade. I think I'm just gonna reinstall Fedora 17 and nuke everything. I'm not loosing anything, it's on my dev laptop. Out of curiosity, what part of the traceback allowed you to identify it was the swap that was the problem? (In reply to comment #32) > Out of curiosity, what part of the traceback allowed you to identify it was > the swap that was the problem? I basically searched for the UUID from the error message (near the top of your traceback). The contents of your /etc/fstab are also included in the traceback, and I saw from it that the problematic UUID was your swap device. Further into the traceback, the storage.log shows that we were unable to resolve that UUID to any device we found in your system. This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is 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 change the 'version' to a later Fedora version prior to Fedora 17's end of life. 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. Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed. |