This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 132876 - bogus ext3 media detected.
bogus ext3 media detected.
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: hal (Show other bugs)
3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Zeuthen
:
Depends On:
Blocks: FC3Target FC3BugWeekQA
  Show dependency treegraph
 
Reported: 2004-09-18 11:28 EDT by Dams
Modified: 2013-03-05 22:41 EST (History)
4 users (show)

See Also:
Fixed In Version: 0.2.98.cvs20040923-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-27 14:24:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
hald --daemon=no --verbose=yes > hal.txt 2>&1 (52.56 KB, text/plain)
2004-09-18 12:41 EDT, Dams
no flags Details
Version 0.2.98-4 : hald --daemon=no --verbose=yes > hal.txt 2>&1 (67.77 KB, text/plain)
2004-09-22 13:28 EDT, Dams
no flags Details
lshal output (63.40 KB, text/plain)
2004-09-22 14:37 EDT, Dams
no flags Details
dd if=/dev/sdc2 bs=512 count=16|hexdump -C (27.41 KB, text/plain)
2004-09-23 14:38 EDT, Dams
no flags Details

  None (edit)
Description Dams 2004-09-18 11:28:58 EDT
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
Comment 1 David Zeuthen 2004-09-18 11:44:20 EDT
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
Comment 2 Dams 2004-09-18 12:39:23 EDT
The version is: hal(0:0.2.97.cvs20040901-1).i386
It persisted over 3 reboot. Here is the output.
Comment 3 Dams 2004-09-18 12:41:55 EDT
Created attachment 103982 [details]
hald --daemon=no --verbose=yes > hal.txt 2>&1
Comment 4 David Zeuthen 2004-09-21 03:35:55 EDT
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).
Comment 5 Dams 2004-09-22 13:28:33 EDT
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.
Comment 6 David Zeuthen 2004-09-22 13:43:40 EDT
Please attach the contents of lshal. Also what is the size of /dev/sdc2?

Thanks,
David
Comment 7 Dams 2004-09-22 14:37:16 EDT
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.
Comment 8 Kay Sievers 2004-09-23 14:19:27 EDT
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
Comment 9 Dams 2004-09-23 14:38:19 EDT
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 ?
Comment 10 David Zeuthen 2004-09-23 20:40:50 EDT
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
Comment 11 Kay Sievers 2004-09-24 02:24:31 EDT
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
Comment 12 David Zeuthen 2004-09-27 13:52:13 EDT
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
Comment 13 Dams 2004-09-27 14:24:19 EDT
Yes. Everything's okay here with hal-0.2.98.cvs20040923-1
Thanks everybody.

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