I think this is

$ rpm -qf /usr/sbin/fstab-sync
hal-0.2.97-1

if you use an updated system

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)?

Thanks,
David

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.

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

Ideas?


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 :-)

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.

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,
David

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)

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.

Created attachment 103021 [details]
testcase

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
earlier.

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.

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
autodetect
/dev/sda7             340         371        8176   fd  Linux raid
autodetect
/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)

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.

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.

Thanks,

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?

Thanks,
David

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.

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,

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
CDROM/CDR/CDRW/DVD-R/DVD+R/DVD-RW/DVD+RW gadget is called
/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 :-)

The raid devices are indeed taken out of /etc/fstab with the latest
code.  Yay!  Thanks,