Some sata drives are now /dev/mapper/nvidia_xxxxxx

[NaSH]

Binary package hint: devicekit-disks

after migrating from 9.04 to 9.10 rc
some of my satadrives became /dev/mapper/nvidia_xxxxxx instead of classic /dev/sdb1

only 2 of my 4 sata drives became unmountable.

both of them are 250 Gb, and same serial number but NOT in raid.
the sata controller was previously in IDE mode, i switched to AHCI with no effect.

fdisk detect all my drive correcly (sda -> sde)

gparted is lost.. got a /dev/mapper/nvidia_cbccehbc of 500GB with 250GB partition
and another /dev/mapper/nvidia_fhjffiga1 that is mountable, with 250GB

Disk manager is lost too, with 3 more 250GB disk found ! and a 500 GB...

note that if i boot my system with 9.04 on usb key, all drives are mounted correctly and available.

got a ICH10 motherboard
05:00.0 SATA controller: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03)
05:00.1 IDE interface: JMicron Technology Corp. JMB362/JMB363 AHCI Controller (rev 03)

ProblemType: Bug
Architecture: amd64
CustomUdevRuleFiles: 10-vboxdrv.rules z80_user.rules
Date: Sat Oct 24 02:02:17 2009
DistroRelease: Ubuntu 9.10
MachineType: MSI MS-7522
NonfreeKernelModules: nvidia
Package: devicekit-disks 007-2ubuntu3
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-14-generic root=UUID=4c0ae5aa-b561-4939-9bdb-3ec0dcf3cd91 ro quiet splash
ProcEnviron:
 LANGUAGE=fr_FR.UTF-8
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: devicekit-disks
Symptom: storage
Uname: Linux 2.6.31-14-generic x86_64
dmi.bios.date: 01/20/2009
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: V7.0
dmi.board.asset.tag: To Be Filled By O.E.M.
dmi.board.name: MSI X58 Gold(MS-7522)
dmi.board.vendor: MSI
dmi.board.version: 3.0
dmi.chassis.asset.tag: To Be Filled By O.E.M.
dmi.chassis.type: 3
dmi.chassis.vendor: MICRO-STAR INTERNATIONAL CO.,LTD
dmi.chassis.version: 3.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrV7.0:bd01/20/2009:svnMSI:pnMS-7522:pvr3.0:rvnMSI:rnMSIX58Gold(MS-7522):rvr3.0:cvnMICRO-STARINTERNATIONALCO.,LTD:ct3:cvr3.0:
dmi.product.name: MS-7522
dmi.product.version: 3.0
dmi.sys.vendor: MSI

[NaSH (lenashou)]

oups..
the fstab sent with the report is the one i tried to tweak.
after going back to the original one, and reboot, the pblm still the same.

the original is the one attached here

[NaSH (lenashou)]

ok think i found the reason..
i removed dmraid, dmsetup and kpartx that where installed during the upgrade and broke my system.
I donno why they where installed, is it automatic during the upgrade for any reason ?
anyway, removing them resolve my pblm.

[Tyler Morgan (digismack)]

I am having the same problem and it is as of yet unresolved. I kept getting "NFS stale file handle" when trying to mount either of my two SATA drives. I removed dmraid, dmsetup and kpartx and now the drives show up properly in gparted.

The partition table on one drive (/dev/sdc1 aka Dumpster) seems to be fine, but Nautilus nor ls are showing any files. This is strange because there ARE files on the drive and it shows 2.x Gb being used. But, hey, no biggie, nothing on that drive is critical.

The other drive (/dev/sdb1 aka Storage) shows no partition table and thus no files. This is a big problem because I have all my work files here. I do have a backup of my most critical files on a remote machine, but it's not a full backup nor is it the latest.

I read on a blog somewhere that running 'sudo gpart /dev/sdx -W /dev/sdx' can find lost partition tables. I'm still waiting for the results. :fingers crossed:

[Tyler Morgan (digismack)]

digismack@digismack:~$ sudo fdisk -l

Disk /dev/sda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0xeacaeaca

   Device Boot Start End Blocks Id System
/dev/sda1 * 1 13373 107418591 83 Linux
/dev/sda2 13374 14593 9799650 5 Extended
/dev/sda5 13374 14593 9799618+ 82 Linux swap / Solaris

Disk /dev/sdc: 74.0 GB, 74000000000 bytes
255 heads, 63 sectors/track, 8996 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x41ab2316

   Device Boot Start End Blocks Id System
/dev/sdc1 1 8996 72260338+ 83 Linux

Disk /dev/sdb: 74.0 GB, 74000000000 bytes
255 heads, 63 sectors/track, 8996 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

[Tyler Morgan (digismack)]

:(

digismack@digismack:~$ sudo gpart /dev/sdb -W /dev/sdb

Begin scan...
End scan.

Checking partitions...
Ok.

Guessed primary partition table:
Primary partition(1)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(2)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(3)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

Primary partition(4)
   type: 000(0x00)(unused)
   size: 0mb #s(0) s(0-0)
   chs: (0/0/0)-(0/0/0)d (0/0/0)-(0/0/0)r

[Martin Pitt (pitti)]

NaSH, any chance you could reinstall dmsetup or dmraid (one at a time) and see which of the two caused this breakage? (I suppose it was dmraid, but let's check). After you identified the package, can you please do

  sudo udevadm test `udevadm info --query=path --name=/dev/mapper/nvidia_xxxxxx`

(with the actual name instead of xxxxx, of course)

Please copy&paste the entire output.

Thanks!

[Tormod Volden (tormodvolden)]

You probably have fakeraid signatures on the disks. Since Ubuntu 9.10 has fakeraid support by default, your fakeraids will be discovered and activated unless you use the "nodmraid" boot option.

The fake raid is on the disks, not on the motherboard. Linux/dmraid can not see if you have disabled the fakeraid support in the BIOS, but it sees the fakeraid signatures on the disks. If your BIOS does not have an option to delete the fakeraid configuration from the disks, use dmraid -E.

[Martin Pitt (pitti)]

Tormod Volden [2009-11-10 16:27 -0000]:
> The fake raid is on the disks, not on the motherboard. Linux/dmraid can
> not see if you have disabled the fakeraid support in the BIOS, but it
> sees the fakeraid signatures on the disks. If your BIOS does not have an
> option to delete the fakeraid configuration from the disks, use dmraid
> -E.

Would blkid detect those signatures? Or is there a similar command for
dumping the dmraid info?

Martin
--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Tormod Volden (tormodvolden)]

Yes, blkid detects that it is a raid, and udev calls dmraid to search for and setup the raid (see /lib/udev/rules.d/85-dmraid.rules).
To see what dmraid finds, run: dmraid -vvv -ddd -ay
This will also activate the raids, so to deactivate again run: dmraid -an