Mailinglist Archive: opensuse-bugs (13462 mails)
| < Previous | Next > |
[Bug 333736] Can´t mount reiserf s partition from disk connected to Promise Fasttrack controller (initialized with 10.2)
- From: bugzilla_noreply@xxxxxxxxxx
- Date: Mon, 15 Oct 2007 20:47:20 -0600 (MDT)
- Message-id: <20071016024720.79FD0CC7AD@xxxxxxxxxxxxxxxxxxxxxx>
https://bugzilla.novell.com/show_bug.cgi?id=333736#c2
Thomas Rood <tomrood1@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|
|tomrood1@xxxxxxxxx
--- Comment #2 from Thomas Rood <tomrood1@xxxxxxxxx> 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.
Thomas Rood <tomrood1@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|
|tomrood1@xxxxxxxxx
--- Comment #2 from Thomas Rood <tomrood1@xxxxxxxxx> 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.
| < Previous | Next > |