Bug 130588 - bad, multiple entries for /media/ieee1394 added to /etc/fstab
Summary: bad, multiple entries for /media/ieee1394 added to /etc/fstab
Alias: None
Product: Fedora
Classification: Fedora
Component: hal
Version: 3
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: David Zeuthen
QA Contact:
Depends On:
Blocks: FC3Target
TreeView+ depends on / blocked
Reported: 2004-08-22 14:06 UTC by Alexandre Oliva
Modified: 2013-03-06 03:41 UTC (History)
1 user (show)

Fixed In Version: hal-0.2.97.cvs20040827-3
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-08-31 17:27:20 UTC

Attachments (Terms of Use)
lshal output (3.89 KB, application/x-bzip2)
2004-08-23 20:59 UTC, Alexandre Oliva
no flags Details
testcase (4.99 KB, text/plain)
2004-08-24 10:29 UTC, David Zeuthen
no flags Details

Description Alexandre Oliva 2004-08-22 14:06:31 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)

Description of problem:
I'm not sure it was udev that came up with these entries; sorry if
it's something else.

Here's what got recently added to my /etc/fstab:

/dev/sdb6               /media/ieee1394disk     auto   
noauto,user,exec,dev,suid 0 0
/dev/sda6               /media/ieee1394disk     auto   
noauto,user,exec,dev,suid 0 0
/dev/sda7               /media/ieee1394disk     auto   
noauto,user,exec,dev,suid 0 0
/dev/sda5               /media/ieee1394disk     auto   
noauto,user,exec,dev,suid 0 0
/dev/sdb7               /media/ieee1394disk     auto   
noauto,user,exec,dev,suid 0 0
/dev/sda8               /media/ieee1394disk     auto   
noauto,user,exec,dev,suid 0 0
/dev/sdb5               /media/ieee1394disk     auto   
noauto,user,exec,dev,suid 0 0

It's bad enough that the entries all refer to the same directory, but
it's worse that none of these partitions are mountable devices: all
but /dev/sda8 are raid devices containing LVM physical volumes. 
Attempting to mount them could do Very Bad Things (TM).  It could be
worse: they could be RAID1 members containing ext filesystems, in
which case they would mount and silently get the raid devices out of
sync.  udev shouldn't create such entries for partitions that aren't
marked with mountable types IMHO.

/dev/sda5               1        6643    53359834+  fd  Linux raid
/dev/sda6            6644       13286    53359866   fd  Linux raid
/dev/sda7           13287       19929    53359866   fd  Linux raid
/dev/sda8           19930       24792    39062016   83  Linux

/dev/sdb5               1        6643    53359834+  fd  Linux raid
/dev/sdb6            6644       13286    53359866   fd  Linux raid
/dev/sdb7           13287       19929    53359866   fd  Linux raid

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Boot with a Firewire disk connected to the system, containing
multiple partitions, some of which are raid devices, some are physical
volumes, some are ext3 filesystems.

Actual Results:  /etc/fstab contains conflicting /media/ieee1394disk
entries pointing to all of them.

Expected Results:  There should only be entries for mountable
partitions, and they should have different names.

Additional info:

Comment 1 Harald Hoyer 2004-08-23 08:20:36 UTC
I think this is

$ rpm -qf /usr/sbin/fstab-sync

if you use an updated system

Comment 2 David Zeuthen 2004-08-23 09:49:13 UTC
Try to upgrade to the latest version of hal (hal-0.2.97.cvs20040819-1)
and attach the output of lshal when booted into a system where this
happens; we should probably skip adding volumes where the fs probing
code in hal returns unknown.

You shouldn't be able to mount these with just 'mount /dev/sdb6',
wouldn't mount(1) complain (mount(1) also contains fs probing code)?


Comment 3 David Zeuthen 2004-08-23 10:25:10 UTC
Hi, I also need to know the version of hal you identified this problem
with. It looks like an old version since the kudzu keyword hasn't been
added to the /etc/fstab entries. Please clean these entries before
upgrading to the latest hal from rawhide. Thanks.

Comment 4 Alexandre Oliva 2004-08-23 13:26:18 UTC
Too late now, I track rawhide daily updates, so I had already updated
to the requested version a few days ago.  I've removed all
kudzu/hal-generated entries and run `service kudzu start', but it
won't even create /mnt/cdrom any more.  I suppose this is expected,
but is there any simple way to get them back? (other than creating
them by hand, or copying them from some other box, that is :-)

# lshal
lshal version 0.2.97.cvs20040819
libhal.c 679 : org.freedesktop.DBus.Error.ServiceDoesNotExist raised
"Service "org.freedesktop.Hal" does not exist"
*** [DIE] lshal.c:dump_devices():70 : Couldn't obtain list of devices
Err...  I suppose this shouldn't have failed.  AFAICT, dbus is running:

# ps auxww | grep dbus
dbus      4150  0.0  0.1  2912  964 ?        Ss   Aug22   0:00
dbus-daemon-1 --system


As for being unable to say `mount /dev/sdb6', yes, it would fail,
unless sdb6 happened to be the first member of a raid 1 (or, worse,
any other raid type) device containing a regular filesystem.  Then
probing would probably detect the filesystem type from the superblock
in the first raid chunk, and proceed to try to get the rest of the
device to look like a filesystem.  With raid 1, this would work, but
it would get the raid devices out of sync.  With any other raid type,
it would get a partial view of the filesystem, the superblocks would
all look out of sync, and mount would hopefully fail, but it might
also fail in far more, erhm, interesting ways :-)

Comment 5 Alexandre Oliva 2004-08-23 13:34:33 UTC
FWIW, this pair of IEEE1394 disks used to be connected every day to
another box that also tracks rawhide, before it booted up in the
morning.  Its /etc/fstab has no traces of the firewire devices, but
the disks haven't been plugged to it for a bit more than a week.

Comment 6 David Zeuthen 2004-08-23 14:48:42 UTC
Hi, I managed to reproduce the bug with a USB thumbdrive so I've fixed
a few things upstream to address this bug

1. the multiple entries with the same mount point was a stupid trivial
bug in fstab-sync; this is now fixed. 

2. Further, fstab-sync only adds entries if hal can identify the
filesystem or if it's a cdrom or optical drive. This still is an issue
with first member of RAID1; to fix this I guess we need to teach hal
about reading the type from the (various) partition tables and get
fstab-sync to respect it. So this will take a few days to fix properly.

I'll push out a new hal package with these changes today, so if you
can test tomorrow if it works out for you (modulo the first member of
RAID1) it would be great.

You need to have hal daemon running, 'service haldaemon start' should
do the trick, otherwise lshal won't work. Please try this, prerably
today, and attach the output from lshal. Also ensure that there is a
fstab-sync or 50-fstab-sync.hal symlink in /etc/hal/device.d pointing
to /usr/sbin/fstab-sync before starting the hal daemon.

Much thanks,

Comment 7 Alexandre Oliva 2004-08-23 20:59:52 UTC
Created attachment 103003 [details]
lshal output

You should probably look for raid superblocks at the end of the device, like
LVM2 does.  Looking at the partition type isn't always possible, since in some
cases there isn't a partition table to look at (think device-mapper, raid of
raid, etc)

Comment 8 David Zeuthen 2004-08-23 21:54:32 UTC
Thanks for the lshal output; looks good.

The issues apart from wrongly adding fstab entries for raid block
devices that looks like filesystems should be fixed in Rawhide now
with hal-0.2.97.cvs20040823-1. Please confirm if this fixes the
problem (you probably need to clean /media and the fstab file).

Btw, technically hal only cares about block devices that stem from a
real disks, e.g. have a device symlink somewhere into /sys/devices but
looking for a RAID superblock sounds like a good idea anyway - I'll
pass that along to the guy who is looking into this issue as we speak.
I'll leave this bug open until that issue is resolved.

One more thing, do you know if mount(1) refuses to mount said devices?
I guess it should.

Comment 9 David Zeuthen 2004-08-24 10:29:57 UTC
Created attachment 103021 [details]

I've created a testcase for this, see attached. Indeed the RAID1 members are
still being added to the /etc/fstab file (as expected, we're still working on
the fix) but fortuntaly the kernel refuses to mount them. So, while this bug
needs to be fixed it shouldn't cause data corruption or loss as anticipated

Comment 10 Alexandre Oliva 2004-08-24 15:38:52 UTC
I can see that the kernel would refuse to mount the raid member if the
raid device is running, but what if it isn't?  E.g., raidstop /dev/md0
before trying to mount it?  I've been able to mount raid 1 members
like this before.

(I'm still downloading today's rawhide updates, will be a few hours
before I can report results for the newer build.

Comment 11 David Zeuthen 2004-08-24 15:56:09 UTC
Ugh, yes, that's right, I can confirm that; should I file a bug
against mount(1) or is there any use for this 'feature'?

[root@laptop ~]# cat /proc/mdstat
Personalities :
unused devices: <none>
[root@laptop ~]# fdisk -l /dev/sda
Disk /dev/sda: 128 MB, 128974848 bytes
16 heads, 32 sectors/track, 492 cylinders
Units = cylinders of 512 * 512 = 262144 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1         245       62704    b  W95 FAT32
/dev/sda2             246         429       47104    5  Extended
/dev/sda3             430         492       16128   83  Linux
/dev/sda5             246         307       15856   83  Linux
/dev/sda6             308         339        8176   fd  Linux raid
/dev/sda7             340         371        8176   fd  Linux raid
/dev/sda8             372         429       14832   83  Linux
[root@laptop ~]# cat /etc/fstab|grep sda6
/dev/sda6               /media/usbdisk          ext3   
noauto,user,exec,kudzu,noatime,sync 0 0
[root@laptop ~]# mount /dev/sda6
[root@laptop ~]# mount
/dev/hda1 on / type ext3 (rw)
none on /proc type proc (rw)
none on /sys type sysfs (rw)
none on /dev/pts type devpts (rw,gid=5,mode=620)
usbdevfs on /proc/bus/usb type usbdevfs (rw)
none on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
/dev/sda6 on /media/usbdisk type ext3 (rw,nosuid,nodev,sync,noatime)

Comment 12 Alexandre Oliva 2004-08-24 17:16:52 UTC
I don't think it's actually wrong to let people mount raid 1 members
if explicitly told to do so, but the auto-detection code could
definitely be made smarter so as to tell the user the device is a raid
member, and what the underlying filesystem type was, should one want
to override mount by explicitly specifying the filesystem type.  I
would certainly welcome such a change.  Avoiding accidents is good.

Comment 13 Alexandre Oliva 2004-08-24 21:37:54 UTC
Just finished installing the updates.  Wiped out all kudzu-generated
entries from /etc/fstab, restarted haldaemon, started kudzu, and
voila, I had new entries for /media/floppy1 and /media/ieee1394disk1,
for the only ext3 partition in these 2 removable disks.  All of the
raid devices are LVM PVs, so I won't be able to test the
raid-superblock-checking code.

Unfortunately, it didn't add an entry for the CDROM.  I suppose this
is not something that hal would do, and kudzu would not re-add it, right?

So, as far as I'm concerned, the problem is fixed, thanks!  Feel free
to close it if you like, but I suppose you'll prefer to keep it open
until raid checking is addressed.


Comment 14 David Zeuthen 2004-08-24 22:01:18 UTC
Hi, thanks for the testing. 

Regarding your cdrom drive; that should indeed be detected by hal and
fstab-sync should add a mount point. kudzu doesn't ship with updfstab
anymore at all, so hal is now responsible for this.

Please attach the output of lshal, 'tree /sys' and 'for i in
/proc/ide/hd*;do echo "$i -> `cat $i/media`"; done'.
Is the cdrom on IDE, SCSI, Firewire or USB? Any specific model?


Comment 15 David Zeuthen 2004-08-24 22:24:25 UTC
Btw, running udevstart if you haven't rebooted in a long time (like a
week) and restarting the haldaemon afterwards might help. I think by
now this happens by default with udev being integrated with initrd.

Comment 16 Alexandre Oliva 2004-08-25 00:03:02 UTC
udevstart with today's udev seems to have fixed it, in that it added
entries for /media/idedisk* and /media/cdrom.  Still no /mnt/cdrom,
but I guess I can get used to /media/cdrom instead of /mnt/cdrom :-)

On the good side, I'll actually be able to test the raid thingie,
since I have /boot on raid1, and today's hal creates mountable entry
points for both raid members.

Just to answer the question on CD-ROM type, it's an IDE CD-ROM bundled
with a Dell Inspiron 8000.  It shows up as /dev/hdb.  If you'd like
the /sys and /proc/ide/hd* stuff, I can still provide it to you, but I
guess it's no longer needed.

Thanks again,

Comment 17 David Zeuthen 2004-08-26 23:37:23 UTC
Hi, I've just built hal-0.2.97.cvs20040827-2 in dist-fc3 that has code
to detect RAID super blocks; credit goes to Kay Sievers of udev fame
for this code. Works jolly well on my setup (RAID1 on two different
compact flash cards :-); please give it a whirl if you still got the
setup for it.

Glad to see your CD-ROM showed up; actually the mount point name will
vary according to the capabilities of the device; mine is called
/media/dvdrom on my aging Inspiron 7500 and my USB2
/media/cdrw_dvdrw. Dunno if that's clever but I guess it's better than
cdrom, cdrom1 etc. Oh well, what's in a name :-)

Comment 18 Alexandre Oliva 2004-08-31 17:27:20 UTC
The raid devices are indeed taken out of /etc/fstab with the latest
code.  Yay!  Thanks,

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