#1 28.01.2019 09:24:26

ManfredB
Mitglied

[erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

Hallo zusammen,

in meinem Rechner sind 4 Festplatten untergebracht:
2 SSDs
2 4TB-Festplatten

Unter ArchLinux bietet lsblk -o+label nur folgende Angaben:
sda (SSD1)
sdb (HD1)
sdd (SSD2)
sde (HD2)

Warum fehlt sdc? Bei anderen Distributionen wird die normale Reihenfolge angezeigt:
sda
sdb
sdc
sdd

Warum ist das bei ArchLinux anders?

Nicht, daß das soooo wichtig ist, aber interessieren würde mich das schon.

Danke im voraus für Antworten.

Gruß
Manfred

Beitrag geändert von ManfredB (28.01.2019 18:12:33)

Offline

#2 28.01.2019 10:14:15

schard
Moderator

Re: [erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

Da fehlt nichts. Oben sind vier, unten sind vier.
Die Namensgebung der Blockdevices durch den Kernel ist zufällig, was hinlänglich bekannt sein dürfte.
https://wiki.archlinux.org/index.php/pe … ice_naming

Offline

#3 28.01.2019 10:22:58

ManfredB
Mitglied

Re: [erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

Danke für die schnelle Antwort.

Gruß
Manfred

Offline

#4 28.01.2019 11:12:13

GerBra
Mitglied

Re: [erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

Mich wundert allerdings auch, warum bei den StorageDevices(sd) die normalen Bezeichnerreihenfolge(Buchstaben) scheinbar verändert ist. Sehe ich zum ersten Mal (und hat IMHO nichts zu tun mit dem was @schard anspricht.

Evtl. mogelt sich ein anderes Device noch rein, z.B. ein SD-Kartenleser ohne Karte. Ich habe meinen mal angeschaltet und habe dann ein sdc (bei 2 Platten), was aber logischerweise (ohne Karte) bei lsblk nicht angezeigt wird.
Zeige doch mal vom Archlinux aus die Ausgaben von:

dmesg |grep "\[sd"
dmesg |grep ata[[:digit:]]

//Edit: oder ggf. einfacher ein:
lsblk -a

Beitrag geändert von GerBra (28.01.2019 11:22:43)

Offline

#5 28.01.2019 11:49:44

ManfredB
Mitglied

Re: [erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

dmesg |grep "\[sd"
[    2.518306] sd 4:0:0:0: [sdb] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
[    2.518308] sd 4:0:0:0: [sdb] 4096-byte physical blocks
[    2.518310] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    2.518315] sd 4:0:0:0: [sdb] Write Protect is off
[    2.518316] sd 4:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    2.518319] sd 0:0:0:0: [sda] Write Protect is off
[    2.518321] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.518325] sd 4:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.518335] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.521263] sd 12:0:0:0: [sdc] Attached SCSI removable disk
[    2.523085] sd 0:0:0:0: [sda] supports TCG Opal
[    2.523087] sd 0:0:0:0: [sda] Attached SCSI disk
[    2.576989] sd 4:0:0:0: [sdb] Attached SCSI disk
[    2.774087] sd 10:0:0:0: [sdd] 976773168 512-byte logical blocks: (500 GB/466 GiB)
[    2.774089] sd 10:0:0:0: [sdd] 4096-byte physical blocks
[    2.774106] sd 10:0:0:0: [sdd] Write Protect is off
[    2.774108] sd 10:0:0:0: [sdd] Mode Sense: 00 3a 00 00
[    2.774137] sd 10:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.774432] sd 11:0:0:0: [sde] 7814037168 512-byte logical blocks: (4.00 TB/3.64 TiB)
[    2.774434] sd 11:0:0:0: [sde] 4096-byte physical blocks
[    2.774451] sd 11:0:0:0: [sde] Write Protect is off
[    2.774453] sd 11:0:0:0: [sde] Mode Sense: 00 3a 00 00
[    2.774477] sd 11:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.780156] sd 10:0:0:0: [sdd] supports TCG Opal
[    2.780158] sd 10:0:0:0: [sdd] Attached SCSI disk
[    2.832382] sd 11:0:0:0: [sde] Attached SCSI disk
 dmesg |grep ata[[:digit:]]
[    0.892227] ata1: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680100 irq 40
[    0.892229] ata2: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680180 irq 40
[    0.892229] ata3: DUMMY
[    0.892230] ata4: DUMMY
[    0.892231] ata5: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680300 irq 40
[    0.892233] ata6: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680380 irq 40
[    0.892233] ata7: DUMMY
[    0.892234] ata8: DUMMY
[    0.892964] ata9: DUMMY
[    0.892964] ata10: DUMMY
[    0.892966] ata11: SATA max UDMA/133 abar m4096@0xf7708000 port 0xf7708200 irq 44
[    0.892967] ata12: SATA max UDMA/133 abar m4096@0xf7708000 port 0xf7708280 irq 45
[    1.363798] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.364119] ata1.00: supports DRM functions and may not be fully accessible
[    1.364942] ata1.00: ATA-11: Samsung SSD 860 EVO 500GB, RVT01B6Q, max UDMA/133
[    1.364943] ata1.00: 976773168 sectors, multi 1: LBA48 NCQ (depth 32), AA
[    1.366736] ata11: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.367237] ata1.00: supports DRM functions and may not be fully accessible
[    1.367464] ata11.00: supports DRM functions and may not be fully accessible
[    1.367486] ata11.00: ATA-10: CT500MX500SSD1, M3CR023, max UDMA/133
[    1.367487] ata11.00: 976773168 sectors, multi 1: LBA48 NCQ (depth 32), AA
[    1.368033] ata11.00: supports DRM functions and may not be fully accessible
[    1.368496] ata11.00: configured for UDMA/133
[    1.369955] ata1.00: configured for UDMA/133
[    1.370068] ata12: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    1.370870] ata12.00: ATA-9: ST4000DM000-1F2168, CC54, max UDMA/133
[    1.370871] ata12.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[    1.371707] ata12.00: configured for UDMA/133
[    1.840404] ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[    1.841902] ata2.00: ATAPI: DRW-24D5MT, 1.10, max UDMA/133
[    1.843208] ata2.00: configured for UDMA/133
[    2.363747] ata5: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[    2.402570] ata5.00: ATA-10: ST4000DM004-2CV104, 0001, max UDMA/133
[    2.402573] ata5.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[    2.464224] ata5.00: configured for UDMA/133
[    2.518246] ata1.00: Enabling discard_zeroes_data
[    2.518444] ata1.00: Enabling discard_zeroes_data
[    2.521929] ata1.00: Enabling discard_zeroes_data
[    2.773558] ata6: SATA link down (SStatus 0 SControl 330)
lsblk -a
NAME    MAJ:MIN RM    SIZE RO TYPE MOUNTPOINT
sda       8:0    0  465,8G  0 disk 
├─sda1    8:1    0    499M  0 part 
├─sda2    8:2    0     99M  0 part 
├─sda3    8:3    0     16M  0 part 
├─sda4    8:4    0  194,7G  0 part 
├─sda5    8:5    0   49,8G  0 part 
├─sda6    8:6    0   50,3G  0 part 
├─sda7    8:7    0   49,8G  0 part 
├─sda8    8:8    0     50G  0 part 
├─sda9    8:9    0   39,2G  0 part 
└─sda10   8:10   0   30,4G  0 part 
sdb       8:16   0    3,7T  0 disk 
├─sdb1    8:17   0    9,8G  0 part 
├─sdb2    8:18   0   10,7G  0 part 
├─sdb3    8:19   0    9,9G  0 part 
├─sdb4    8:20   0     10G  0 part 
├─sdb5    8:21   0     10G  0 part 
├─sdb6    8:22   0     10G  0 part 
├─sdb7    8:23   0     10G  0 part 
├─sdb8    8:24   0     10G  0 part 
├─sdb9    8:25   0     10G  0 part 
├─sdb10   8:26   0     10G  0 part 
├─sdb11   8:27   0     10G  0 part 
├─sdb12   8:28   0     10G  0 part 
├─sdb13   8:29   0    988G  0 part /MediaThek
├─sdb14   8:30   0  984,3G  0 part /Isos
├─sdb15   8:31   0  989,9G  0 part 
└─sdb16 259:0    0  643,6G  0 part 
sdc       8:32   1          0 disk 
sdd       8:48   0  465,8G  0 disk 
├─sdd1    8:49   0      3G  0 part 
├─sdd2    8:50   0     40G  0 part 
├─sdd3    8:51   0     90G  0 part 
├─sdd4    8:52   0     40G  0 part /
├─sdd5    8:53   0     90G  0 part 
├─sdd6    8:54   0     40G  0 part 
├─sdd7    8:55   0     40G  0 part 
├─sdd8    8:56   0     40G  0 part 
├─sdd9    8:57   0     40G  0 part 
└─sdd10   8:58   0     40G  0 part 
sde       8:64   0    3,7T  0 disk 
├─sde1    8:65   0   14,8G  0 part [SWAP]
├─sde2    8:66   0  496,2G  0 part 
├─sde3    8:67   0  983,2G  0 part 
├─sde4    8:68   0 1003,5G  0 part /Downloads
├─sde5    8:69   0  692,8G  0 part /VMs
└─sde6    8:70   0  535,6G  0 part /Daten

Kann es sein, daß der Card-Reader in /dev/sdc sitzt und von ArchLinux einfach eingebunden wird?

Gruß
Manfred

Offline

#6 28.01.2019 11:56:19

ManfredB
Mitglied

Re: [erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

Nachtrag:

Ich habe einmal eine USB-HD am PC angeschlossen. Auf dieser sind Sicherheitskopien von Gentoo-stable und Gentoo-unstable
und noch 2 Linux-Distributionen, u.a. Archlinux.

Diese habe ich aber im Moment ausgeschaltet und den USB-Stecker rausgezogen.

Wenn ich sie anschliesse und einschalte, wird sie als /dev/sdb angezeigt,
Kann es also daran liegen?

Offline

#7 28.01.2019 12:34:20

GerBra
Mitglied

Re: [erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

ManfredB schrieb:

Kann es sein, daß der Card-Reader in /dev/sdc sitzt und von ArchLinux einfach eingebunden wird?

Das ist nach der lsblk -a Ausgabe zumindest sehr  naheliegend. Auf jedenfall hast du unter Arch eine **durchgehend** konsistente Benennung der /dev/sdX Blockdevices. Es "fehlt" nichts, höchstenfalls erkennen die "anderen Distributionen" halt nicht alle Blockdevices(->deren Problem)...
Für mich sieht das alles OK aus.

Sowas ist halt auch ein klassisches Beispiel für den Punkt, den @schard ansprach: Wie wichtig es ist, bei mehreren Festplatten/Controllern/usw. sich eben nicht auf die Devicebezeichner zu verlassen beim gezielten Zugriff auf Partitionen/Dateisysteme, sondern dann eben konsequent mit LABELs oder UUIDs zu arbeiten.

Offline

#8 28.01.2019 13:00:55

ManfredB
Mitglied

Re: [erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

Ganz herzlichen Dank für die Hilfe.
Nun verstehe ich das Ganze doch besser.

Also hat die manchmal angeschlossene USB-HD keinen Einfluss auf die Devices.

Das ist schon mal beruhigend.

So nebenbei nur: Die einzige Distribution, die mir - sobald sie auf einer USB-HD installiert wird - mit kernel panic endet, ist PCLinuxOS.
Alle anderen kommen mit LABEL und UUID wunderbar zurecht.
Allerdings nutze ich auf dem PC hauptsächlich nur noch die beiden SSDs für Distributionen,
auf den HDs sind nur Daten gespeichert.
Der Vorteil ist überwältigend: der Boot-Vorgang und alle Updates (auch bei Gentoo) sind rasant.

Hat sich also gelohnt mit der Anschaffung des neuen PCs.

Gruß
Manfred

Offline

#9 28.01.2019 17:08:04

GerBra(offline)
Gast

Re: [erledigt] lsblk -o+label - sda,sdb,sdd,sde - kein sdc?

ManfredB schrieb:

Ganz herzlichen Dank für die Hilfe.
Nun verstehe ich das Ganze doch besser.

Also hat die manchmal angeschlossene USB-HD keinen Einfluss auf die Devices.
Das ist schon mal beruhigend.

USB-HD: Wenn diese HD während des Bootens schon angeschlossen/aktiv ist, dann kann das schon eine Rolle spielen. Durchaus möglich, daß diese sich dann als sdd hinter den "Cardreader (sdc)" einfügt und deine anderen HDs wieder einen "Buchstaben" weiterwandern.
Das ist ja das "Problem" dabei.

Die Reihenfolge, in der Blockdevices auftauchen, folgt schon einer gewissen Systematik. Erstmal liefert das BIOS/(U)EFI eine "geordnete" Liste, die v.a. von Hardwarefaktoren abhängt: An welchem Port/Anschluß hängt ein Device, welcher Controller (Sata,USB,Scsi,IDE,...) ist "onboard" oder per externer Controllerkarte an welchem Bus/Slot/Steckplatz(pci(e)1, pci1 und pci2, usb, usw.

Betriebssysteme können diese geliefterte Liste nun aber nach eigenen Notwendigkeiten "durcheinander würfeln". Frühere Windowse (wenn ich das richtig in Erinnerung habe) stellten z.B. primären Partitionen bei der Laufwerkbuchstabenvergabe vor den logischen Laufwerken (unabängig von welcher Controllerreihenfolge diese kamen).
Linux/BSDs halten m.E. nach zumindest am jeweiligen Controller bei Gleichwertigkeit der Anschlüsse die "Reihenfolge" ein, 3 Devices am gleichen Sata-Controller (Port 1,2 und 3) haben dann z.B. sda, sdb und sdc. Evtl. Fallstrick hier: Gerade bei Home-PCs sind die (Onboard) Anschlüsse eben nicht gleichwertig (wird auch oft im Handbuch erwähnt), bei 6 Ports sind oftmals 5 und 6 nur niedrigere Durchsatzrate(für optische Laufwerke z.B).

Und dann noch: zwischen Kaltstart und Warmstart des PCs kann es (teils je nach welchem OS gebootet wurde) auch noch/wieder eine andere Reihenfolge geben. Früher(tm), als in Computern noch wesentlich mehr (weil kleine) Platten verbaut wurden, z.B. an 2-3 modellgleichen SCSI-Controllern, war es ein ebensolches Vabanque-Spiel: welcher Controller ist heute der "Erste"... Genauso mit (oftmals gleichen) Ethernet-Karten: eth0 mußte nicht immer das erwartete eth0 sein. Deshalb gab es Mechanismen, die Devicebezeichner(ethX) jeweils fix an die MAC-Adresse zu binden; aus dem gleichen Grund agiert(e) man auch bei Blockdevices eben mit Label oder UUID.

Schnellantwort auf dieses Thema

Schreibe deinen Beitrag und versende ihn
Deine Antwort

Fußzeile des Forums