Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I'm working on a hopefully unrelated question question and I've got to a strange situation.

First: I know very little about the very low level hardware kernel storage driver magix, so I'm hoping a) someone can help and b) someone can explain it to me better.

I've been trying a dozen different configurations of my 2x500GB SATA drives over the past few hours involving switching between ACHI/IDE/RAID in my bios; After each attempt I've reset the bios option, booted into a live CD, deleting partitions and rewriting partition tables left on the drives.

Now, however, I've been sitting with a /dev/mapper/nvidia_XXXXXXX1 that seems to be impossible to kill!

It's the only 'partition' that I see in the Ubuntu install (but I can see the others in parted) but it is only the size of one of the drives, and I know I did not set any RAID levels other than RAID0.

Anyone have any ideas how I can kill this and get back to just two independent IDE drives? Or can anyone convince me of a reason to go the AHCI route?

Many thanks in advance.

Update Thanks to you guys this was sorted, and I've updated my blog with a summary walkthrough

share|improve this question
    
Of course, I may just be an idiot; of the two drives, I've only been partitioning one, leaving the other vacant for later use as a scratchdisk, and my thought process is that if the device-mapper is trying to represent both devices together, it will just display the capacity that is partitioned? Right? Wrong? Crazy? –  Andrew Bolster Mar 24 '10 at 21:12
    
I'm wrong and crazy, the mapper was only dealing with one of the two drives (goodness knows why) –  Andrew Bolster Mar 24 '10 at 21:16

3 Answers 3

up vote 3 down vote accepted

Thanks to wazoox for eliminating a possibility, but I found what works for me.

After a bit of experimenting, I tried

$dmraid -r

so see what raid sets were set up, then did

$dmraid -x

but was presented with

ERROR: Raid set deletion is not supported in "nvidia" format

Googled this and found this forum post that told me to do this;

$dmraid -rE

And that went through, rebooted, hoped, waited (well, while i was waiting, set the bios back to AHCI), and repartitioned, and all of (this particular issue) was well again. Hope this helps someone else down the line!

share|improve this answer
    
Nice find, kudos! I wasn't aware of dmraid, I'm all in the enterprise-class RAID stuff :) –  wazoox Mar 25 '10 at 10:40
    
Neither was I! Nothin better than self-learning. Thanks for your help though, and now that I have the rep, enjoy some upvoting! –  Andrew Bolster Mar 25 '10 at 12:32
    
Booting with nodmraid helps too. –  Giovanni Toraldo Dec 1 '12 at 14:10

You definitely must use AHCI. This is the native SATA controller mode, it provides enormous performance gains compared to the funky IDE emulation. "RAID" on motherboards is basically a sham, hiding a software RAID through a windows driver, and has absolutely zero effect under Linux. If you want RAID, use software RAID, it works great.

The "/dev/mapper/xxx" stuff probably is an LVM logical volume created by some partial installation. Open a console and see what "lvdisplay" shows. If there's some LVs, delete them with

lvremove /dev/whatever

Then check for volumes groups and remove them : get the list with

vgdisplay

then kill with

vgremove /dev/whatever

Finally clean up LVM physical volumes :

lvdisplay

then

lvremove /dev/whatever

For reference, LVM manages disks partitions as "physical volumes", aggregates them in "volume groups", then allows you to make "logical volumes" on them. See LVM on wikipedia for more gory details.

share|improve this answer
    
vgdisplay says nada, vgremove /... complains the volume group wasnt found (makes sense). Thanks for trying. As for AHCI, Sold! If i had the rep I've upvote; maybe later. –  Andrew Bolster Mar 24 '10 at 21:21
    
run vgscan to see if you have VGs, then the commands in this answer. –  Dan Andreatta Mar 24 '10 at 22:19
1  
Tried that after nosying around the vgdisplay man pages, but thanks for the heads up –  Andrew Bolster Mar 26 '10 at 22:00

Device mapper creates references to partitions or devices, and associates a UUID that is different to the one seen in partition managers. Its not a new or separate device, its just a new reference. You can just get rid of the reference, there is no need to clean up your partitions or devices.

I wanted to remove a device that appeared in my file browser, because it is from another OS that i dont want to access from Ubuntu. (Im using a triple boot UEFI laptop.) I wanted to remove the device mapper device reference in my file browser.

The file browser showed me the UUID of the device

$ sudo blkid

--> lists all the devices and showed me the UUID came from device mapper

Hiding the partitions using /etc/udev/rules.d/ didnt work.

The answer by wazoox worked for me, to remove the device mapper reference.

$ sudo lvdisplay

--> showed the persistently displayed device, and another of same OS

$ sudo vgscan

--> showed me that i had one group, corresponding to the OS of the device

$ sudo vgremove groupname

--> deleted the group (change groupname to yours, no quotes)

When i reopened the file browser, that persistent device was gone. When i rebooted, the device didnt reappear in my browser.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.