Bug 517498 - Traceback when the same fs is listed multiple times in /etc/fstab
Summary: Traceback when the same fs is listed multiple times in /etc/fstab
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: 11
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Anaconda Maintenance Team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 520135 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-08-14 11:50 UTC by Izidor Matušov
Modified: 2009-09-07 11:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-08-31 17:49:35 UTC


Attachments (Terms of Use)
Photo of traceback (397.46 KB, image/jpeg)
2009-08-14 11:50 UTC, Izidor Matušov
no flags Details

Description Izidor Matušov 2009-08-14 11:50:27 UTC
Created attachment 357443 [details]
Photo of traceback

Description of problem:
When I want to boot into rescue mode from Fedora 11 x86_64 DVD, I got python exception and had to reboot system.

I think the source of problem could be I use LVM and crypted disks.

How reproducible:


Steps to Reproduce:
1. Boot from DVD - Rescue mode
2. Chose the keyboard, enable/disable network, choose RW or RO mode - it is all irrelevant.
3. Enter passphrase for every disk. 
  
Actual results:

Traceback (most recent call last):
File "/usr/bin/anaconda", line 729, in <module> 
rescue.runRescu(anaconda, instClass)

File "/usr/lib/anaconda/rescue.py", line 315, in runRescu
readOnly = readOnly)

File "/usr/lib/anaconda/storage/__init__.py", line 1187, in mountExistingSystem
fsset.parseFSTab(chroot=rootPath)

File "/usr/lib/anaconda/storage/__init__.py", line 1520, in parseFSTab
self.devicetree._addDeviceService)

File "/usr/lib/anaconda/storage/devicetree.py", line 601, in _addDevice
raise ValueError("device is already in tree")

ValueError: device is already in tree

install exited abnormally (1/1)
disabling swap...
unmounting filesystem...
/mnt/runtime done
disabling /dev/loop0 LOOP_CLR_FD failed: 16

/proc done
/dev/pts done
/sys done
/selinux done
/mnt/sysimage done
sending termination signals... done
sending kill signals... done
You may safely reboot your system

(rewritten from attached photo I took with my phone)

Expected results:
Boot into rescue mode

Comment 1 Chris Lumens 2009-08-17 18:55:54 UTC
What does your /etc/fstab look like?

Comment 3 Chris Lumens 2009-08-28 20:38:03 UTC
*** Bug 520135 has been marked as a duplicate of this bug. ***

Comment 5 Chris A 2009-08-30 21:35:51 UTC
A quick but dirty fix to this problem is to comment many useless lines in the /etc/fstab.

I encountered similar problem with a fstab like this :

/dev/sdb1  /media/foo  vfat  rw,user,noauto,owner,uid=500,gid=500 0 0
/dev/sdb1  /media/bar  ntfs  rw,user,noauto,owner,uid=500,gid=500 0 0

Even with 'noauto' option provided in the /etc/fstab, Anaconda looks for the device and fails if not found.

Comment 6 Chris Lumens 2009-08-31 17:49:35 UTC
This will be fixed in the next build of anaconda.  Thanks for the bug report.

Comment 7 Izidor Matušov 2009-09-07 11:39:31 UTC
After removing useless lines from the /etc/fstab it works!

But I have one relative question. After booting into rescue mode, mounting installation, chrooting and rebooting computer, my installed fedora runs SELinux relabeling. (I did nothing with SELinux in rescue mode). It took me a lot of time. It is the normal behaviour?


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