From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040809 Galeon/1.3.17 Description of problem: (I dont know exactly if it's really kudzu, hal, or anaconda, or whatever so feel free to change the component if i'm wrong.) After an upgrade from Fedora Core 2 to Fedora Core 3 Test 2, I've discovered 3 new lines in my fstab : /dev/sdc2 /media/scsidisk ext3 noauto,user,exec,kudzu 0 0 /dev/sdb2 /media/scsidisk1 ext3 noauto,user,exec,kudzu 0 0 /dev/sda3 /media/scsidisk2 ext3 noauto,user,exec,kudzu 0 0 My system has an scsi controler with 3 disks. The 3 disks are non-removable devices. Now let's take a look at partitions : /dev/sda3 650 1272 5004247+ fd Linux raid autodetect /dev/sdb2 27 649 5004247+ fd Linux raid autodetect /dev/sdc2 27 1920 15213555 8e Linux LVM sda3 and sdb2 are in fact /dev/md0 (soft raid 1), configured in the fstab as /mnt/anvil: /dev/md0 /mnt/anvil ext3 defaults 1 2 On its side, /dev/sdc2 is part of a logical volume "/dev/mapper/1er-other", along with sda4 and sdb4, but neither sda4 nr sdb4 appears in the fstab with these strange lines. Version-Release number of selected component: packages are all stock fc3t2 version. How reproducible: Always
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.