https://bugzilla.novell.com/show_bug.cgi?id=333736#c1 Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|kernel-maintainers@forge.provo.novell.com |jeffm@novell.com Status|NEW |ASSIGNED --- Comment #1 from Jeff Mahoney 2007-10-15 13:01:20 MST --- I'm not seeing anything in the log that would indicate why it's failing. Can you try to mount manually and post the output of 'dmesg' afterwards? If there's nothing interesting in there near the end, please also attach the output of 'dmsetup table' and the contents of /proc/mdstat. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=333736#c2 Thomas Rood changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomrood1@yahoo.com --- Comment #2 from Thomas Rood 2007-10-15 20:47:19 MST --- Since at least SuSE Professional 9.3, if a disk had been previously used with a Promise Fasttrack controller, the Promise partitions would remain even though the disk was remounted in another machine and a conventional parition table was written. Yast (in SuSE 9.3) would warn about it but let it continue. I could always tell that it had occurred since Yast would write fstab as /dev/mapper .. rather than /dev/hd... When this occurred, the yast partitioner would show both the /dev/hd... and the /dev/mapper ... partitions in the table, but it would use the /dev/mapper partitions. A single physical drive could show as /dev/hda1 and /dev/mapper/name-partition. From the printout that was attached to this bug report, I believe that the drive connected to the computer's primary IDE controller was previously connected to the Promise Fasttrack controller and has been assigned both /dev/hda1 and the partitions /dev/mapper/lotus-opt_suse101, /dev/mapper/lotus-srv_suse101, /dev/mapper/lotus-tmp_suse101, /dev/mapper/lotus-usr_suse101, /dev/mapper/lotus-src_suse101, and /dev/mapper/lotus-var_suse101. If this is what happened, the system is properly reporting /dev/hda1 as already mounted since it is already mounted as /dev/mapper/lotus. Fsck never cared which access point was used so it reports good for /dev/hda1 by checking /dev/mapper/lotus-opt_suse101. The other drive should be there somewhere, but since it was previously connected to a Promise Fasttrack controller it will also be showing as /dev/mapper/something. Also, if the Promise Fasttrack controller was previously supporting a RAID0, it may have been already mounted as part of /dev/mapper/lotus. After some experimenting with Promise Fasttrack cards, I decided the only safe way to use them was to support data drives then to destroy the partitions on them using dmraid prior to removing the drives from the machine. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=333736#c4 --- Comment #4 from Jörg Spilker 2007-10-17 08:32:12 MST --- Created an attachment (id=179040) --> (https://bugzilla.novell.com/attachment.cgi?id=179040) Output of /proc/mdstat And now the output of /proc/mdstat -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=333736#c6 Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |WORKSFORME --- Comment #6 from Jeff Mahoney 2007-10-22 14:02:02 MST --- Ok, that makes sense. dmraid should be claiming the device. Closing as WORKSFORME. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.