Bug 132876

What version of hal you are running? This was supposed to be addressed
with hal-0.2.97.cvs20040901-1 - see also bug 130588 for discussion.

If the bug still persists please attach the output of 'hald
--daemon=no --verbose=yes' to this bug report (make sure to stop the
haldaemon with 'service haldaemon stop' before doing this).

Thanks,
David

The version is: hal(0:0.2.97.cvs20040901-1).i386
It persisted over 3 reboot. Here is the output.

Created attachment 103982 [details]
hald --daemon=no --verbose=yes > hal.txt 2>&1

This should be fixed in hal-0.2.98-4 which is available in Rawhide
soon - alternatively you can download the SRPM from 

 http://people.redhat.com/davidz/hal-0.2.98-4.src.rpm

Also, please attach the output of 'hald --daemon=no --verbose=yes'
even if it works. I've got a suspiscion that the kernel is giving us
the wrong size of the disks (that's why the RAID and LVM superblocks
weren't picked up by hal and thus the disk was wrongly added to the
fstab).

Created attachment 104134 [details]
Version 0.2.98-4 : hald --daemon=no --verbose=yes > hal.txt 2>&1

0.2.98-4 version seems to work a little better, since i only have one bogus
device left in the fstab : 
/dev/sdc2 /media/scsidisk ext3 noauto,user,exec,kudzu 0 0

sdc2 is an lvm2 partition. Here's the new log.

Please attach the contents of lshal. Also what is the size of /dev/sdc2?

Thanks,
David

Created attachment 104138 [details]
lshal output

sdc2 is approx. 15GB.

Disk /dev/sdc: 18.3 GB, 18351959040 bytes
255 heads, 63 sectors/track, 2231 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
   Device Boot	    Start	  End	   Blocks   Id	System
/dev/sdc1   *		1	   26	   208813+  82	Linux swap
/dev/sdc2	       27	 1920	 15213555   8e	Linux LVM
/dev/sdc3	     1921	 2231	  2498107+  83	Linux

lshal output attached.

Hi,
the last bug is hopefully fixed in CVS now. The first bug was
caused by a wrong size calculation we did in HAL. With fixing this,
the Linux raid was detected correcly.

David introduced the interpretation of the partiton type of the
msdos table and this should now prevent the remaining bug that you
run into.

But there must be still something wrong with the detection, cause
for some reason we don't detect your last volume as a raid member.
You have 3 partitions in one volume set, right?

  sdc2  LVM2 (15GB)
  sda4  LVM2 (7GB)
  sdb4  LVM2 (9GB)

We don't catch the 15GB volume. It would be nice if you can give me
a look at the content of your first few sectors by issuing:

  dd if=/dev/sdc2 bs=512 count=16|hexdump -C

and post that output. This will hopefully lead to a solution to fix
this bug and we don't just prevent the fstab update but also set the
right fstype in the HAL volume object.

Thanks,
Kay

Created attachment 104208 [details]
dd if=/dev/sdc2 bs=512 count=16|hexdump -C

You're correct, sdc2, sda4 and sdb4 are all gathered into a volume group called
"1er" which contain a single logical volume called "other". I've pasted sdc
partition table in my last comment. If it can be useful, here are the 2 other
disk partition tables.

Disk /dev/sda: 18.2 GB, 18200739840 bytes
255 heads, 63 sectors/track, 2212 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot	    Start	  End	   Blocks   Id	System
/dev/sda1		1	   26	   208813+  82	Linux swap
/dev/sda2   *	       27	  649	  5004247+  83	Linux
/dev/sda3	      650	 1272	  5004247+  fd	Linux raid autodetect
/dev/sda4	     1273	 2212	  7550550   8e	Linux LVM

Disk /dev/sdb: 18.3 GB, 18351959040 bytes
255 heads, 63 sectors/track, 2231 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot	    Start	  End	   Blocks   Id	System
/dev/sdb1   *		1	   26	   208813+  82	Linux swap
/dev/sdb2	       27	  649	  5004247+  fd	Linux raid autodetect
/dev/sdb3	      650	 1148	  4008217+  83	Linux
/dev/sdb4	     1149	 2231	  8699197+  8e	Linux LVM

I'm attaching the hexdump ouput you requested. Do you need anything else ?

I've uploaded a new hal package hal-0.2.98.cvs20040923-1 that will
appear in Rawhide tomorrrow. Please see if this fixes the bug.

Thanks,
David

With all the nice debug data from Dams, I've hopefully found the real
bug now. We just need to probe for LVM before we probe for any real
filesystem, cause that may be successful even on a raid member. This
is what we see with /dev/sdc2.

Thanks,
Kay

I've just uploaded another hal package that is a bit more conservative
in what is being added to fstab named hal-0.2.98.cvs20040927-1 that
will appear in tomorrows upload. Although hal-0.2.98.cvs20040923-1
should work equally well in this case.

Dams, does it work for you? Can I close this bug?

Thanks,
David

Yes. Everything's okay here with hal-0.2.98.cvs20040923-1
Thanks everybody.