Device Mapper mapped Disk ungewollt (Linux)

Seite 1 von 1 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/device-mapper-mapped-disk-ungewollt-linux_248331/page_1 - zur Vollversion wechseln!

GrandAdmiralThrawn schrieb am 02.03.2017 um 13:21

Heyho,

Ich hab schon seit längerem ein Problem mit Device Mapper. Der schnappt sich irgendwie beim Booten meine 4Kn Disk und erzeugt eine Device Map, das ist aber ungewünscht.

In meinem Fall ist das /dev/sdc mit der MBR Partition /dev/sdc1. Das Disklabel ist "backup" (Auch wenn's keine wirkliche Backupdisk mehr ist).

Jetzt is die Sache lästig, weil ich einige Sachen auf der Disk offen habe, und wenn ich reboote kommen meine gespeicherten Desktops nur zur Hälfte wieder, weil ich erst das hier machen muß:

Code:

# dmsetup remove backup
# mount /dev/sdc1 /mnt/4Kn

In der fstab steht's natürlich richtig drin:

Code:

/dev/sdc1		/mnt/4Kn		ext4	defaults,auto	0 0

Also die Frage: Wie erkläre ich dem Device Mapper, daß er meine Disk da bitte in Ruhe lassen soll? Er soll weiterhin seine Maps für mein md RAID-1 erzeugen, das passt schon, aber nicht für diese Platte.

Klar könnt ich auch einfach den Mapper Mountpoint nehmen, aber mich juckt das jetzt, gibt's ja nicht, daß ich dem nicht erklären kann, diese Disk zu ignorieren!

Oder brauch ich da eine udev Regel?! Ich find im Netz schlicht keine Lösung dafür.

Danke!

COLOSSUS schrieb am 02.03.2017 um 14:24

Ich verstehe das Problem nicht. Sicher, dass das nicht einfach das Label des Dateisystems auf diesem Datentraeger ist, und udev fuer dich diesen Symlink als Alias fuer den Kernel-Name des Blockgeraets anlegt? (dm-mappings sind u. a. eigentlich eine Alternative zu Partitionen...)

Kannst du die Ausgabe von `dmsetup ls` und `lsblk` hier posten, von dem Zustand, der dich stoert?

GrandAdmiralThrawn schrieb am 02.03.2017 um 15:08

Das war jetzt Arbeit, alle meine VMs wieder runternehmen, zig Tools schließen... hah. Aber jo, das was mich primär stört, ist, daß meine Partition nicht eingehängt wird so wie ich will, und daß das hier nicht geht:

Code:

# mount /dev/sdc1 /mnt/4Kn
mount: /dev/sdc1 already mounted or /mnt/4Kn busy

Tjo, mounted is es nicht, nur mein System RAID-1 ist wirklich eingehängt:

Code:

# mount | grep -e mapper -e sdc
/dev/mapper/luks-e0e20f87-1d08-4b51-9c70-1eb463859282 on / type ext4 (rw)

Und wenn das so is, dann restored er mir so gut wie keine grafischen Programme beim Reboot/Login in Gome, die irgendwelche Dateien auf /mnt/4Kn offen hatten. Die kann ich dann alle wieder manuell aufmachen, Fenstergeometrie anpassen, Daten öffnen, WÄH!

Die Ausgaben, die du wolltest:

Code:

# dmsetup ls
backup	(253:2)
luks-dd0ff087-caa8-4533-b963-bd71baf5399f	(253:1)
luks-e0e20f87-1d08-4b51-9c70-1eb463859282	(253:0)

# lsblk
NAME              MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                 8:0    0 698.7G  0 disk  
├─sda1              8:1    0 554.7G  0 part  
│ └─md1             9:1    0 554.7G  0 raid1 
│   └─luks-e0e20f87-1d08-4b51-9c70-1eb463859282 (dm-0)
                  253:0    0 554.7G  0 crypt /
├─sda2              8:2    0   512M  0 part  
│ └─md0             9:0    0   512M  0 raid1 /boot
└─sda3              8:3    0   3.7G  0 part  
  └─md2             9:2    0   3.7G  0 raid1 
    └─luks-dd0ff087-caa8-4533-b963-bd71baf5399f (dm-1)
                  253:1    0   3.7G  0 crypt [SWAP]
sdb                 8:16   0 698.7G  0 disk  
├─sdb1              8:17   0 554.7G  0 part  
│ └─md1             9:1    0 554.7G  0 raid1 
│   └─luks-e0e20f87-1d08-4b51-9c70-1eb463859282 (dm-0)
                  253:0    0 554.7G  0 crypt /
├─sdb2              8:18   0   512M  0 part  
│ └─md0             9:0    0   512M  0 raid1 /boot
└─sdb3              8:19   0   3.7G  0 part  
  └─md2             9:2    0   3.7G  0 raid1 
    └─luks-dd0ff087-caa8-4533-b963-bd71baf5399f (dm-1)
                  253:1    0   3.7G  0 crypt [SWAP]
sdc                 8:32   0   2.7T  0 disk  
└─sdc1              8:33   0   2.7T  0 part  
  └─backup (dm-2) 253:2    0   2.7T  0 crypt 
sr0                11:0    1  1024M  0 rom   
sr1                11:1    1  1024M  0 rom

Was ich nicht will ist, daß /dev/sdc1 ein /dev/dm-2 bzw. /dev/mapper/backup Mapping erhält (das kann ich auch irgendwie ned mounten?). Ich will, daß der Devicemapper die Disk nicht anfaßt, weil ich will's normal in der fstab einhängen, also Partition auf Mountpoint!

Deswegen muß ich erst die Devicemap entfernen, und dann erst kann ich's einhängen wie gewohnt, eben wie oben schon gezeigt:

Code:

# dmsetup remove backup
# mount /dev/sdc1 /mnt/4Kn

Voilà, so funzts. Ich hab leider keine Ahnung wie man das automatische Verhalten des Devicemappers steuert...

COLOSSUS schrieb am 02.03.2017 um 15:54

Hattest du auf /dev/sdc1 mal einen LUKS-Container drauf?

GrandAdmiralThrawn schrieb am 02.03.2017 um 17:44

Hmm... Die Disk war schon so einiges Zeit ihres Lebens (wegen der 4Kn Tests). Ich könnts nicht beschwören, aber es kann GUT sein, daß ich die Mal verschlüsselt hatte. Meinst wegen des lsblk Outputs? Hm.

Wenn ja, wie fix ich das? Also nach Möglichkeit ohne meinen MBR zu schrotten.

COLOSSUS schrieb am 02.03.2017 um 17:59

Ja, deswegen. Du koenntest mal schauen, was `cryptsetup -v isLuks /dev/sdc1` zu sagen hat, um sicher(er) zu gehen.

GrandAdmiralThrawn schrieb am 02.03.2017 um 18:54

Gesagt, getan:

Code:

# cryptsetup -v isLuks /dev/sdc1
Device /dev/sdc1 is not a valid LUKS device.
Command failed with code 22: Device /dev/sdc1 is not a valid LUKS device.

Und etwas mehr, weil ich ned weiß was ich sonst tun sollte:

Code:

# file -s /dev/sdc
/dev/sdc: x86 boot sector; partition 1: ID=0x7, starthead 1, startsector 63, 732563937 sectors, extended partition table (last)\011, code offset 0x0

# file -s /dev/sdc1
/dev/sdc1: Linux rev 1.0 ext4 filesystem data (needs journal recovery) (extents) (large files) (huge files)

COLOSSUS schrieb am 04.03.2017 um 20:47

OK, LUKS-Device ist es also wohl keines, und auch nie gewesen. Vielleicht aber ja dm-crypt? Ich wuerde, der Einfachheit halber, einfach den gesamten Datentraeger-Inhalt an einen sicheren Ort kopieren, dann /dev/sdc* aushaengen, die Platte badblocks einmal im destrutive r/w mode von vorne bis hinten durchbuegeln, und die zuvor gesicherten Daten dann zurueckkopieren. Somit kann eigentlich nix mehr sein (und sichergestellt, dass die Disk noch gesund ist, hast du damit auch).

GrandAdmiralThrawn schrieb am 06.03.2017 um 20:00

Hmm, wipen also... Das werd ich mir vorerst wohl nicht antun. Ein Unmount oder Reboot geht grade noch, aber alles wegsichern, wipen, restoren, das frißt einfach zuviel Zeit jetzt. Das Ding ist ja permanent in Benutzung, und recht voll is die Disk auch (1.9TiB/2.7TiB belegt).

Ein schneller, chirurgischer Eingriff (irgendwo in Track 0?) wäre da besser, dann bräuchte man nur kleine Teile wegsichern vor'm Rumpfuschen, und man könnte danach gleich weitermachen..