Festplatten/optische Laufwerke Unterscheidung SATA oder IDE?

G

gamefreaktegel

Mitglied
Hallo Leute,

gibt es eine Möglichkeit per Software herauszufinden, ob ein SATA oder IDE-Geräte verbaut sind?
In den aktuellen Kernel Versionen werden ja auch IDE-Geräte unter /proc/scsi/scsi verwaltet... früher gab es ja mal /proc/ide...

Weiß da jemand was?
 
Hi,

schonmal lshw probiert? Das ist ein kleines Programm das dir einiges an Infos zu deiner Harware liefert. Bei Debian basierten Systemen solltest du es direkt im Packet Manager finden.

mfg,
bytepool
 
Eher Vermuten statt Wissen:

Code:
[B]l /dev/disk/by-path/[/B]
insgesamt 0
drwxr-xr-x 2 root root 320 2009-01-25 15:52 .
drwxr-xr-x 5 root root 100 2009-01-25 15:52 ..
lrwxrwxrwx 1 root root   9 2009-01-25 15:52 pci-0000:00:06.0-[B]ide[/B]-0:0 -> ../../hda
lrwxrwxrwx 1 root root  10 2009-01-25 15:52 pci-0000:00:06.0-ide-0:0-part1 -> ../../hda1
lrwxrwxrwx 1 root root  10 2009-01-25 15:52 pci-0000:00:06.0-ide-0:0-part2 -> ../../hda2
lrwxrwxrwx 1 root root  10 2009-01-25 15:52 pci-0000:00:06.0-ide-0:0-part3 -> ../../hda3
lrwxrwxrwx 1 root root  10 2009-01-25 15:52 pci-0000:00:06.0-ide-0:0-part4 -> ../../hda4
lrwxrwxrwx 1 root root   9 2009-01-25 15:52 pci-0000:00:06.0-[B]ide[/B]-0:1 -> ../../hdb
lrwxrwxrwx 1 root root  10 2009-01-25 15:52 pci-0000:00:06.0-ide-0:1-part1 -> ../../hdb1
lrwxrwxrwx 1 root root   9 2009-01-25 15:52 pci-0000:00:06.0-ide-1:0 -> ../../hdc
lrwxrwxrwx 1 root root   9 2009-01-25 15:52 pci-0000:00:06.0-[B]ide[/B]-1:1 -> ../../hdd
lrwxrwxrwx 1 root root  10 2009-01-25 15:52 pci-0000:00:06.0-ide-1:1-part1 -> ../../hdd1
lrwxrwxrwx 1 root root   9 2009-01-25 15:52 pci-0000:00:07.0-[B]scsi[/B]-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root  10 2009-01-25 15:52 pci-0000:00:07.0-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root   9 2009-01-25 15:52 pci-0000:00:07.0-[B]scsi[/B]-1:0:0:0 -> ../../sdb
lrwxrwxrwx 1 root root  10 2009-01-25 15:52 pci-0000:00:07.0-scsi-1:0:0:0-part1 -> ../../sdb1
Die ide/scsi(sata)-Verteilung würde hier (bzw. bei meinem Etch-Rechner) zumindest Perfekt zu den folgenden Devices passen ;)
 
Die ide/scsi(sata)-Verteilung würde hier (bzw. bei meinem Etch-Rechner) zumindest Perfekt zu den folgenden Devices passen ;)

Klar, das liegt aber daran, daß "Debian Antik" noch keine libata verwendet.

Code:
ls -l /dev/disk/by-path/
insgesamt 0
lrwxrwxrwx 1 root root  9 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part2 -> ../../sda2
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part3 -> ../../sda3
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part4 -> ../../sda4
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part5 -> ../../sda5
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part6 -> ../../sda6
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part7 -> ../../sda7
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part8 -> ../../sda8
lrwxrwxrwx 1 root root 10 24. Jan 20:15 pci-0000:00:1f.1-scsi-0:0:0:0-part9 -> ../../sda9
lrwxrwxrwx 1 root root  9 24. Jan 20:16 pci-0000:00:1f.1-scsi-1:0:0:0 -> ../../sr0

Dummerweise ist aber sda eine IDE-Platte, und da der TE weder seine Distribution noch seine Kernelversion angibt, ist das hier Ratespiel.

Ich würde hier "hwinfo" (mit den Argumenten --disk, --cdrom, --ide bzw. --scsi) verwenden, aber das nutzt nicht jede Distribution, genau so wie lshw wohl eine Spezialität der Debian(derivate) ist.
 
Zuletzt bearbeitet von einem Moderator:
hmm... zur Info, ich nutze Kanotix mit einem 2.6.28er Kernel.

Leider habe ich unter /dev kein disk

Bei lshw kann man nicht direkt im "Festplattenbereich" erkennen ob SATA oder IDE... man müsste schauen welcher Controller verbaut ist etc...
Ich benötige das für ein Skript was die Hardware ausliest und direkt klassifiziert ob die Platte eine IDE oder eine SATA Platte ist. Früher ging das mit /proc/ide...

Bei hwinfo --disk bekomme ich keine Ausgabe...
 
IDE oder SATA

Hallo

Bei hwinfo --disk bekomme ich keine Ausgabe...

Naja, du mußt hwinfo schon installieren und als root ausführen, dann bekommst du mit

hwinfo --disk doch recht ansehnliche Infos

mfg
schwedenmann
 
Die "antiken" Versionen sicher nicht ... aber wer nutzt schon noch Woody oder Sarge?
Aber Etch-and-a-Half, Lenny und Baustellen sollten das sehr wohl ...

Auch da scheint es darauf anzukommen, wie man diese Version erhält.

Ich hatte eine EtchVM mit 2.6.18, die ich zuerst auf Etch 1.5 mit 2.6.24 upgedatet hatte.

Da gabs noch keine libata per default (macht ja auch Sinn, da nur ein Update innerhalb der Version).

Überraschenderweise wurde auch nach einem einfachen dist-upgrade (vor etwa 6 Wochen) auf Lenny keine libata verwendet, ich habe hier immer noch hdX statt sdX für die Festplatten.

Beim dist-upgrade kam auch keine Abfrage, was mich schon etwas überrascht hatte.

Mein Kollege, der auf seiner Kiste Lenny neu installiert hatte, hat sdaX also libata.

http://ezix.org/project/wiki/HardwareLiSter
Vielleicht haben es die Susler nur "vergessen" ... :P

Nö, die Susler haben hwinfo entwickelt, wahrscheinlich (Vermutung) weil es sehr stark mit HAL/udev zusammenarbeitet.

Sieht mir aber eher so aus, als hätten die Debianers ein ordentliches Updatescript für den Sprung von Etch auf Lenny "vergessen", das dann auch nachfragt oder automatisch die fstab und menu.lst auf "libata"-kompatibel umschreibt.

Da können sie ja mal bei den "Suslern" nachfragen, die haben das schon in 10.3 eingebaut gehabt (da seit 2.6.22 per default libata verwendet wird) und welches das beim Update auch auf allen Maschinen, die ich von < 10.3 auf 10.3 gebracht habe, zuverlässig erledigt hat.
 
libata

Hallo


Zu libata ud debian.

Ich verwende Sid und hab immer noch hda, trotz Kernel 2.6.26-10??-686 .

In der kernelconfig ist pata komplett deaktiviert, dagegen stehen alle sata module auf y.

Mich störts nicht, das ich kein pata nutze
Frage_ bleibt ide im Kernel drin, oder fliegt das irgendwann für pata raus, was ja dann Sinn machen würde ?

mfg
schwedenmann
 
Ah ... Moment ... libata wird schon verwendet ... aus Stabilitätsgründen aber noch nicht alle PATA-Module ("Stabilitätsgründe" im Sinne von "die PATA-Treiber unterstützen noch nicht alles, was ihre alten Kollegen understützen").
Und das hat nix mit Antik zu tun ...

Btw. ... nur weil Suseler "ihr" hwinfo haben, ist das noch keine Erklärung, warum sie lshw nicht haben ...

Und bzgl. dem "Upgradescript" ... 1. ist Lenny noch nicht fertig und 2. können Debianer lesen -> http://www.debian.org/releases/testing/releasenotes
(den betreffenden Abschnitt findest Du sicher fix ...)

Aber stimmt schon ... hochentwickelten Tools zu glauben ist natürlich besser als selbst aufzupassen ... ;)
 
Ah ... Moment ... libata wird schon verwendet ... aus Stabilitätsgründen aber noch nicht alle PATA-Module ("Stabilitätsgründe" im Sinne von "die PATA-Treiber unterstützen noch nicht alles, was ihre alten Kollegen understützen").
Und das hat nix mit Antik zu tun ...

Aha, wieso bekommt man dann beim dist-upgrade keine Auswahl oder Nachfrage zu sehen? Nur darum geht es, und glaubs mir, ich HABE hingesehen und Ja, ich HABE vorher in die Release Notes geschaut, sogar zweimal (Etch auf Etch-1.5 und Etch1.5 auf Lenny).

Btw. ... nur weil Suseler "ihr" hwinfo haben, ist das noch keine Erklärung, warum sie lshw nicht haben ...

Wozu sollte man ein weiteres Tool pflegen, wenn man schon ein eigenes hat (welches andere Distributionen übrigens gerne übernehmen, wahrscheinlich weil es wohl nicht mal so schlecht ist)?

Nur weils von den heiligen Mönchen des Ian Murdoch-Ordens kommt? Ja ne, ist klar.

Und bzgl. dem "Upgradescript" ... 1. ist Lenny noch nicht fertig und 2. können Debianer lesen -> http://www.debian.org/releases/testing/releasenotes
(den betreffenden Abschnitt findest Du sicher fix ...)

Nun, wie gesagt, ich habe mir die Release Notes angesehen und nach libata (und danach, weil ich nichts gefunden hatte) nach "ata" gesucht.

Meinst Du den hier?

http://www.debian.org/releases/testing/i386/release-notes/ch-upgrading.de.html#boot-hangs

Oder den?

http://www.debian.org/releases/testing/i386/release-notes/ch-information.de.html#upgrade-to-2.6

(Das sind alle Treffer, die man mit dem Suchbegriff "ata" im gesamten Dokument findet und die etwas mit Partitionen zu tun haben.)

Bei einigen SATA-Geräte-Controllern zeichnet sich das Gerät als Laufwerk aus und seine Partitionen können sich von /dev/hdX in /dev/sdX ändern. In diesem Falle müssen Sie Ihre /etc/fstab und Ihre Boot-Loader-Konfiguration anpassen. Solange diese Änderungen nicht korrekt durchgeführt sind, wird Ihr System nicht korrekt hochfahren[11].

Und hier geht es nicht mal um libata, sondern um eine Funktion, die seit Ewigkeiten (oder wie alt ist Kernel 2.6 noch mal) für SATA implementiert sind, zu "libata" finde ich im verlinkten Dokument nicht ein Wort (und ich habe gesucht).

Auf gut Deutsch heisst das doch nichts Anderes als "wir bekommen es nicht hin, weshalb wirs ohne Nachfrage weglassen und kein Wort in die Release Notes schreiben", aber ich weiß, es ist ja noch nicht fertig.

"Es ist noch nicht fertig" ist hier jedenfalls ne Ausrede.

Eine tiefgreifende Änderung sollte alleine schon _weil_es noch nicht fertig ist, implementiert werden, damit es auch ordentlich getestet werden kann, oder soll das, was als erstes kommt (die Installation/das Upgrade) als letztes implementiert werden?

Das kanns ja wohl nicht sein, wenn man immer auf sein hochgelobtes System der dist-upgrades pocht, welches auch bei anderen Mechanismen insgesamt bei einer minimalen Installation ohne X etwa 10 mal nachgefragt hat, ob man die alte Config übernehmen möchte oder nicht, so wie man das auch gewohnt ist.

Aber stimmt schon ... hochentwickelten Tools zu glauben ist natürlich besser als selbst aufzupassen ... ;)

Siehe oben, das dist-upgrade habe ich nur aus diesem einen Grund durchgeführt, weil ich sehen wollte, ob man eine Auswahl bekommt, und da war eben Fehlanzeige.

Und wo wir gerade bei Release-Notes und "man findet es schnell" sind:

http://www.suse.com/relnotes/i386/openSUSE/10.3/RELEASE-NOTES.en.html#9

Das ist Stand für Kernel 2.6.22, in wiefern sich das mit den mehr als 15 Partitionen bisher geändert hat, kann ich nicht sagen.
 
Aha, wieso bekommt man dann beim dist-upgrade keine Auswahl oder Nachfrage zu sehen?
Auswahl für was??
Wozu sollte man ein weiteres Tool pflegen, wenn man schon ein eigenes hat
Genau ... wozu KDE wenn man Gnome hat ... oder andersherum ... oder überhaupt?
Was ist das denn für eine sinnfreie Einstellung?
Bingo. Wobei das Dank udev für den Wechsel von den alten ide-Treibern zu PATA nicht zwingen notwendig ist/wäre.
Und hier geht es nicht mal um libata, sondern um eine Funktion, die seit Ewigkeiten ...
Richtig ... es geht um Beheben/Umgehen von generellen Problemen mit veränderten Device-Bezeichnern ... aus welchen Gründen auch immer.
Auf gut Deutsch heisst das doch nichts Anderes als "wir bekommen es nicht hin, weshalb wirs ohne Nachfrage weglassen und kein Wort in die Release Notes schreiben", aber ich weiß, es ist ja noch nicht fertig.
Das dürfte dann wohl eher "Rain_Maker"-Deutsch sein ...
Warum soll in den Release-Notes stehen, dass man noch nicht auf PATA umgestellt hat? Warum sollte man überhaupt reinschreiben, was man _nicht_ nutzt? Muss ich direkt mal bei Suse gucken ...
Eine tiefgreifende Änderung sollte alleine schon _weil_es noch nicht fertig ist, implementiert werden, damit es auch ordentlich getestet werden kann, oder soll das, was als erstes kommt (die Installation/das Upgrade) als letztes implementiert werden?
Welchen Teil von "Debian hat noch nicht komplett auf PATA gewechselt, weil die Treiber noch nicht alles unterstützen" hast Du jetzt nicht verstanden??
Das kanns ja wohl nicht sein, wenn man immer auf sein hochgelobtes System der dist-upgrades pocht, welches auch bei anderen Mechanismen insgesamt bei einer minimalen Installation ohne X etwa 10 mal nachgefragt hat, ob man die alte Config übernehmen möchte oder nicht, so wie man das auch gewohnt ist.
Ich steh gerade auf dem Schlauch ... wieso sollte man wegen Änderungen fragen, wenn es keine Änderungen gab?
libata-SATA Treiber -> bleiben bei /dev/sd*
alte IDE-Treiber -> bleiben bei /dev/hd*
libata-PATA Treiber -> bleiben bei /dev/sd* (bzw. gab es vorher keine Unterstützung)
Wo ist das Problem?

Bzgl. Deinen Release-Notes ... ich glaub das gleiche Stand in Etch bzgl. der SATA-Module ... denn für die nutzt Debian libata schon länger. Wenn Suse der Meinung ist, die PATA-Module reichen in ihr derzeitigen/damaligen Form ... bitte, soll mir Recht sein.
 
Was ist das denn für eine sinnfreie Einstellung?

Wer hat denn mit diesem Unsinn angefangen?

http://ezix.org/project/wiki/HardwareLiSter
Vielleicht haben es die Susler nur "vergessen" ...

Glashaus anyone?

Steht ja auch auf der verlinkten Seite, wer lshw schon länger als Standardpackage ausliefert, das sind Mandriva und Debian (und nein, das mit Mandriva wusste ich nicht), Fedora seit kurzem und Gentoo wohl als optionales Paket.

Nur weil nicht jede Distribution die selben Tools wie Debian verwendet, wurde etwas vergessen? Dann hat also z.B. Gentoo apt vergessen oder Fedora aptitude?

DAS ist eine schwachsinnige Einstellung, die man aber bei Debianer sehr häufig beobachten kann, diese Scheuklappen sind wohl im Installer drin.

War hier ja auch zu lesen, erst mal "schau Dir lshw an" ohne Nachfrage, welche Distribution der TE überhaupt verwendet, genau so wie (der Klassiker) "poste die /etc/network/interfaces", selbst wenn der Fragesteller schon seine Distribution genannt hat und es handelt sich nicht um ein Debianderivat.

Welchen Teil von "Debian hat noch nicht komplett auf PATA gewechselt, weil die Treiber noch nicht alles unterstützen" hast Du jetzt nicht verstanden??

Ich steh gerade auf dem Schlauch ... wieso sollte man wegen Änderungen fragen, wenn es keine Änderungen gab?
libata-SATA Treiber -> bleiben bei /dev/sd*
alte IDE-Treiber -> bleiben bei /dev/hd*
libata-PATA Treiber -> bleiben bei /dev/sd* (bzw. gab es vorher keine Unterstützung)
Wo ist das Problem?

Zumindest den Teil, in welchem Du von PATA sprichst (und es auch mehrfach wiederholst), das sind doch die "alten" Treiber, sagen sogar die Debianer.

Wirf mal einen Blick in /etc/udev/rules.d/60-persistent-storage.rules, steht sogar netterweise noch "Obsolete PATA Driver" drüber.

Die PATA-Treiber sind obsolet und weiter unten steht ja dann (zum ersten mal?) libata-pata, also was meinst Du nun genau?

Code:
lsmod | grep ata

ata_generic             4676  0
libata                140384  1 ata_generic
scsi_mod              129356  1 libata
dock                    8304  1 libata

Disk /dev/hda: 2147 MB, 2147483648 bytes
255 heads, 63 sectors/track, 261 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x0001f0f1

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1         242     1943833+  83  Linux
/dev/hda2             243         261      152617+   5  Extended
/dev/hda5             243         261      152586   82  Linux swap / Solaris

Ist aber auch egal, was nun alt oder neu ist, denn so wie es aussieht (bei 3 Systemen, die ich bei Bekannten gecheckt hatte und auch bei dem System, von dem die obigen Ausgaben stammen) wird übrigens auch für IDE-Devices libata verwendet, nur werden noch die alten Devicenamen beibehalten (warum auch immer, ist auch nur bei Debian so, alle anderen Distributionen nennen die devices mit libata sdX und nicht hdX), eine Wahl zwischen alten und neuen Treibern bekam ich bei den Dist-Upgrades auf den besagten drei Maschinen _nicht_ angeboten.

Zu libata findet sich kein Wort in den Lenny Release Notes und es sind die selben, die Du auch weiter oben verlinkt hattest.

Bei den Etch-Release Notes muss ich nicht nachsehen, da steht sicher nichts von libata drin (weil mit Kernel 2.6.18 eindeutig zu alt).

//Edit:

OK, ich hab gerade noch mal etwas genauer hingesehen, vor allem, weil mich das hier

Code:
ata_generic             4676  [B]0[/B]
doch sehr gewundert hat.

Nun fragt man sich natürlich, was die HD wirklich antreibt, und siehe da:

Code:
lsmod | grep ide
ide_cd_mod             27652  0
cdrom                  30176  2 sr_mod,ide_cd_mod
ide_disk               10496  3
ide_pci_generic         3908  0 [permanent]
ide_core               96168  4 ide_cd_mod,ide_disk,ide_pci_generic,piix

Nett, oder?

Es werden automatisch _sowohl_die alten IDE-Treiber _als auch_ die neuen zu libata gehörenden Treiber geladen, aber scheinbar trotzdem nur die alten Treiber verwendet (für CD und HD), deshalb auch hdX statt sdX (bzw. srX für CD).

OK, jetzt habe ich das mit dem "noch nicht ganz umgestellt auf die neuen Treiber" endgültig verstanden, man nutzt die Dinger zwar nicht, aber man lässt sie trotzdem trotzdem schon mal automatisch laden, wahrscheinlich um die User (für das nächste Release?) daran zu gewöhnen.

Find ich gut, Placebos sollen sogar in Einzelfällen schon schwere Krankheiten geheilt haben.
 
Zuletzt bearbeitet von einem Moderator:

Ähnliche Themen

Linux "vergisst" Dateisystem?

Bestehende physische Windows Maschine Virtualisieren II

CDROm devices abfragen

Heimserver Konfiguration für Ubuntu Server?!

Problem mit externer Festplatte

Zurück
Oben