Debian Sarge mit Kern 2.4.27 auf SMP (Ross) Teil 1

[claus]

Noch etwas:

Code: [Auswählen]

ok test net

Using AUI Ethernet Interface
Internal loopback test -- succeeded.
External loopback test -- Lost Carrier  (transceiver cable problem?)  
send failed.

Using TP Ethernet Interface
Internal loopback test -- succeeded.
External loopback test -- Lost Carrier  (transceiver cable problem?)  
send failed.

net selftest failed. Return code = -1

Ganz doofe Frage: Hattest Du ein Kabel angesteckt?

Bezüglich AUI bzw TP,  gibt es da nicht einen OBP Eintrag, der regelt, welches von beiden benutzt wird?

Ich hab leider meine Command Reference nicht da und die SS20 steht auch woanders im Augenblick

Übrigens hab ich noch einen AUI-TP Converter hier herumliegen, falls Du ihn brauchen solltest, kann ich dir das Ding gerne zukommen lassen gegen Porto (2€ oder so sollte das kosten).

Angenehmes Wochenende,

Claus

[RolfD]

So.. ich habe mein Kernel hochgeladen und stelle ihn damit zu Testzwecken zur Verfügung
Sollte ich Probleme mit dem Downloadvolumen bei Arcor kriegen, nehme ich den Kern wieder vom Netz.

Zum Kernel selbst:

Der Kern mit Version 2.4.27 ist ein normaler Debian Kernel mit modifizierten Optionen "make menuconfig".
Er läuft nur mit V8 Prozessoren!
Er lädt keine initrd!
Er hat kein ext2 Filesystem enthalten!
Er muss eine ext3 /boot und  eine ext3 / (root) partition vorfinden!
Er kann ext2 als Modul nach dem booten nachladen!
Er ist als SMP Kern mit max 4 CPU'S compiliert, ob er auf einem UP System läuft, weiss ich nicht.
Es sind einige Optionen abgeschaltet, die evtl. doch gewünscht sind... es steht jedem frei, den Kern selbst neu zu bauen und die von mir abgeschalteten Optionen wieder einzuschalten, es ist jedoch auf die Kernelgrösse von max. 2,6MB "ungezipt" zu achten.
Der Kern ist ein reiner Test- u. Versuchskernel und nicht für produktive Umgebungen gedacht.
Die Nutzung erfolgt auf eigene Gefahr und sollte nicht ohne Hintergrundinformation erfolgen.
Für Schäden aus der Nutzung dieses Kernels muss ich also jede Verantwortung ablehnen.

Der Link zum Config File: http://home.arcor.de/rolf.diesing/sun/config
(Bitte daran denken, das File in .config umzubenennen wenn es 1:1 in den sourcetree eingefügt werden soll.
Das File ist leider etwas gross um es hier komplett zu posten, solche Datenwüsten wären in einem Forum als Text auch unpassend)

Der Link zum Kernel: http://home.arcor.de/rolf.diesing/sun/kernel-image-2.4.27-sparc32_V8.smp_sparc.deb
(Dies ist ein normales deb, ggf. im silo vorher eine Alternativconfig anlegen um den alten UP-Kernel noch booten zu können.)

Ich bin für Vorschläge und Verbesserungen am config File immer dankbar da ich mich selbst erst langsam an die Problematik rantaste.

@Sparky
Danke für diese Infos!
Ich hab da aber noch ne Frage: Ich habe bei mir im Banner (2.25R) der Sun gesehen, das dort "Hypersparc" steht. Ist das ein Hinweis auf ein OBP einer HS20/30? ich habe mal im OBP nach den Optionen für die Speichereinstellungen gesucht aber nichts gefunden. Oder sind alle Rechner mit Ross CPUs sozusagen "Hypersparc"? Mein ROM Image habe ich mal irgendwann im Web/FTP gefunden und kann leider nichts mehr zum Filedatum sagen. Gibts eine Möglichkeit das ROM genauer zu identifizieren?

Zu meinem Versuch, alle Pakete mit apt-build nachzubauen und entsprechend auf v8 zu optimieren.. es scheint da diverse Probleme zu geben, ich empfehle daher derzeit, dies noch nicht zu machen. Ganz konkret z.B. lässt sich der dhcp-client zwar compilieren, ist aber dann nicht mehr in der Lage, IP adressen zuzuweisen. Da man sich sein Rechner mit sowas vom Netz abhängen kann, ist da Vorsicht geboten. (ich habe mir dann provisorisch z.B. mit einer statischen IP geholfen, der Rechner muss jedoch später dhcp auf min. 1 eth machen können). Wo da genau die Probleme liegen, versuche ich noch rauszubekommen. Perl habe ich bisher noch nicht compilieren können, das bricht mit Fehler ab. Jedoch scheint es sich doch zu lohnen, mit Ross CPUs zumindest einige Pakete zu optimieren - vor allem da wo viel gerechnet wird, merkt man doch deutliche Unterschiede.

Gruß RolfD

[Sparky]

Ich hab da aber noch ne Frage: Ich habe bei mir im Banner (2.25R) der Sun gesehen, das dort "Hypersparc" steht. Ist das ein Hinweis auf ein OBP einer HS20/30? ich habe mal im OBP nach den Optionen für die Speichereinstellungen gesucht aber nichts gefunden. Oder sind alle Rechner mit Ross CPUs sozusagen "Hypersparc"? Mein ROM Image habe ich mal irgendwann im Web/FTP gefunden und kann leider nichts mehr zum Filedatum sagen. Gibts eine Möglichkeit das ROM genauer zu identifizieren?

Im OK Prompt:
.Version

[astronom]

So.. ich habe mein Kernel hochgeladen und stelle ihn damit zu Testzwecken zur Verfügung
Sollte ich Probleme mit dem Downloadvolumen bei Arcor kriegen, nehme ich den Kern wieder vom Netz.

Zum Kernel selbst:

Der Kern mit Version 2.4.27 ist ein normaler Debian Kernel mit modifizierten Optionen "make menuconfig".
Er läuft nur mit V8 Prozessoren! [...]
Der Link zum Kernel: http://home.arcor.de/rolf.diesing/sun/kernel-image-2.4.27-sparc32_V8.smp_sparc.deb
(Dies ist ein normales deb, ggf. im silo vorher eine Alternativconfig anlegen um den alten UP-Kernel noch booten zu können.)

Getestet an meiner Funktionierenden SS20 mit 2x125MHz Ross - Bootet nicht. Der Debian-Uniprozessorkernel von der Installations-CD läuft.
Das erste booten des neuen Kernels endete mit einem kompletten System-freeze, ich bin nichtmal mehr an das OK-Prompt gekommen. Alle weiteren enden in einem "Watchdog reset" & Rücksetzen ans OK-Prompt sofort nach dem start von init.

Der nächste schritt wäre wohl selber einen Kernel zu basteln - aber nimmer heute. Gibt es noch irgend welche anderen vorschläge, was man versuchen könnte?

[RolfD]

@Sparky
Hallo Sparky ich habe mit .Version folgende Ausgabe:

->Release 2.25R hyperSPARC Version 1 created 97/01/28 15:20:13

Ist diese Version für eine 'normale' SS20 mit 2 mal HM142S-1024 Modulen überhaupt geeignet?
Und kann ich aus dem Rechner evtl. noch etwas Leistung rauskitzeln und wenn ja, wie?
Die R-Versionen haben anscheinend auch einige Befehle mehr als das "normale" OBP, gibts dazu irgendwo im Netz eine erweiterte Befehlsreferenz?

@All
Zu meinem 2.4.31 Kernel von Kernel.org:
Ich habe heute mein zuletzt gebauten Kern nun aktiviert und alles ist glatt verlaufen.
Der Rechner bootet und startet fehlerfrei komplett durch.

@astronom
Die Probleme, das nach dem Booten der init Prozess starb und der Rechner hing, hatte ich mit frühen 2.4er Kernel Versuchen auch.
Allerdings meinte ich das Problem in einer falsch eingerichteten "system.map" gefunden zu haben da Silo die zum Kernel gehörende "system.map" zum laden des Kerns braucht bzw. da etwas Mittels einem Codestück "btfixup.c" anpasst. Wenn die System.map nicht dem aktuellen Kernel entspricht, konnte ich solche Fehler wie init-Absturz reproduzieren. Da tappe ich aber recht massiv im Dunkelen... und lasse mich gern auch verbessern. Sonst wüsste ich nicht, warum der Debain-Kern 2.4.27-2 so Probleme macht.. wie gesagt hier läuft er einwandfrei. Man kann mit LILO über den Kernel Boot Parameter "init=/bin/bash" übrigens auch ein anderes Programm als "Init" starten was an der Konsole gern zum reset von rootpw genutzt wird. Das entspricht grob gesagt einem Kernelstart im single Modus. Der Silo müsste sowas auch kennen. Damit kannst du evtl. die geladenen Module und Devices kontrollieren (wenn silo das so überhaupt kann).

Den Kern also selbst zu bauen (evtl. mit meinem config file) scheint mir die beste Lösung zu sein. Wie man debian-Kernel erstellt ist gut dokumentiert. Die Kernel von Kernel.org lassen sich so ähnlich bauen. Ich vermute aber, das Prozedere kennst du auch.
Würd mich freuen wenn wir die Rechner mal "gegeneinander antreten lassen können" wenn du soweit bist. Ist bestimmt auch für die Com interessant, eine Dual CPU SS20 142Mhz 1mb cache gegen eine Quad SS20 100Mhz 256 kb cache laufen zu sehen...
Mich würden auch Ergebnisse anderer Betriebssysteme und Konstellationen im Bereich SS20 interessieren.

@All
Nach dem mein 2.4.31 Kern nun läuft, überlege ich noch, den Security Patch von http://www.grsecurity.net/ anzuwenden.
Gibt es damit hier Erfahrung im Forum bezüglich SMP? Angeblich soll der Patch SMP tauglich sein... hat das mal jemand (evtl auch auf sparc64) probiert? Welche Erfahrungen gibt es also zu dem Patch auf Sparc?

Gruß RolfD

[Sparky]

->Release 2.25R hyperSPARC Version 1 created 97/01/28 15:20:13

Ist diese Version für eine 'normale' SS20 mit 2 mal HM142S-1024 Modulen überhaupt geeignet?
Und kann ich aus dem Rechner evtl. noch etwas Leistung rauskitzeln und wenn ja, wie?
Die R-Versionen haben anscheinend auch einige Befehle mehr als das "normale" OBP, gibts dazu irgendwo im Netz eine erweiterte Befehlsreferenz?

- Offensichtlich ist diese Version geeignet, sonst würde deine SS20 damit nicht booten
- Mehr Leistung gibts nur mit schnelleren CPU´s oder einer waschechten Ross HyperSTATION
- Es gibt nirgends eine Befehlreferenz - da sollte ich vielleicht für meine Homepage mit aufnehmen

[RolfD]

Zum Patch von grsecurity.net auf vanilla Kernel 2.4.31 als SMP,

der Patch lässt sich erwartungsgemäß problemlos einspielen und die Compilation läuft durch.

Die Optionen von grsecurity lassen sich Mittels 'make menuconfig' einstellen.
Es gibt Low,Medium,High,Custom. Ich hatte dort die Stufe 'Medium' genommen und den gcc lauf angeworfen.

Der Kern ist jedoch nicht startbar.

Beim Laden des Kerns (noch auf der Silo Ausgabe und vor dem Umschalten in den normalen ->(weisse Schrift auf schwarzem Hintergrund) Videomode blinkt die Grafik kurz auf.. als wenn ein CPU/Grafikkarten/Rechner Reset ausgeführt wird und der Rechner bleibt dann mit Int 15 bzw. Watchdog Meldung stehen. Da der Patch sehr tief in die Systeminterna der Prozessverwaltung eingreift, scheint es also dort auch zu Problemen zu kommen. Es dürfte sich IMHO also um ein (Speicher)Initialisierungs-/Ladefehler von Silo und/oder (in der Folge) um ein sehr frühes "Sterben" des eigentlichen Kernelprozesses handeln. Jedenfalls ist der Kern nach dem Reset nicht mehr in der Lage, irgendwas gescheites in der "grsecurity"-Einstellung "medium" anzustellen. Der Patch sollte aber angeblich auf arch Sparc laufen. Evtl. geht er auf UP und das Problem liegt im SMP code... da scheinen sowieso noch "einige" Baustellen zu liegen.

Ich teste das ganze nun mit SMP und in Einstellung "Low"als default und mit aktivem "random tcp source port" als Custom Option und bin auf den nächsten gcc Lauf gespannt. Ich benutze inzwischen auch das "-mcpu=hypersparc -mtune=hypersparc" als Ersatz für "-mv8 -mtune=v9" da dies den für meine CPUs bestangepassten Code ergeben müsste.

Gruß RolfD

[RolfD]

@all
Der Patch von grsecurity.net funktioniert auch in der "Low" unter den beschriebenen Voraussetzungen und Einstellung nicht.
Da ich nicht vor hatte, Kernelprogger zu werden, muss ich mich wohl mit dem 2.4.31er smp Kern erst mal begnügen.

Gruß Karboom

[astronom]

Hallo RolfD,

dein 2.4.27-Kernel läuft auf meiner daheimstehenden Sun (4x100MHz, 512MB Ram) blendend - seit ich BNC-Netzwerkequipment habe kann ich mit dem AUI-BNC-Transciever auch wieder ins Netzwerk.
Allerdings wüsste ich noch gerne, welche änderungen du an dem Kernel gegenüber dem Vanilla-Kernel vorgenommen hast und mit welchen Extra-Compiler-Optionen du den Kern gebaut hast. Ich habe versucht mir einen 2.4.31 zu backen, der bootet aber leider nicht. Er bleibt bei einer Fehlermeldung (die ich schon wieder vergessen habe) stehen und das ganze System mit ihm - kein OBP mehr. Den habe ich mit -mcpu=hypersparc -mtune=hypersparc gebaut.

Muss man eigentlich wie in einem deiner ersten Postings erwähnt wirklich den Makefile ändern um diese Optionen zu den CFLAGS hinzuzufügen oder reicht da nicht ein "export CFLAGS="$CFLAGS -mcpu=hypersparc -mtune=hypersparc" vor dem starten des Compile?

[RolfD]

Hallo Astronom,
es freut mich sehr, das der von mir gebaute Kern bei deiner 4x100er läuft.
Es gibt nichts schlimmeres wie wenn man "nicht reprduzierbare Ergebnisse" hat.. von da her ist dies ein wichtiger Schritt.

Zur Kernel config:
Ich hatte neben dem Kernel auch die Config auf dem Webspace abgelegt, mit der ich den Kernel erzeugt habe.
Es handelt sich wie gesagt um den 2.4.27-2 aus original Debian Qellen.

Du kannst mit "diff" meine und deine Config vergleichen und/oder meine Config in dein Kernelsourceverzeichnis als ".config" kopieren um dann mit "make menukonfig" die für dich sinnvollen Änderungen machen. (backup nicht vergessen)

Die Änderungen bezüglich der CFLAGS muss man wohl in /usr/src/Kernelsource+Version/arch/sparc/Makefile machen.
Ich hatte auch versucht, dies mit CFLAGS als shell Variable zu machen aber diese wird scheinbar von den scripten nicht berücksichtig bzw. das mit dem Var Export hat bei mir nicht so geklappt wie es gedacht war. Ändern des Makefile hilft aber zuverlässig.
Bei mir sieht das dann so aus:
CFLAGS := $(CFLAGS) -mcpu=hypersparc -mtune=hypersparc -O2 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7

Zum 2.4.31 Kern:
Ich habe wie bereits beschrieben das .config File aus der 2.4.27-2 genommen und es in den Source Tree für den 2.4.31 kopiert, dort dann mit "make menuconfig" weitere kleinere Einstellungen vorgenommen (im Bereich NetFilter) und ebenfalls dort in arch/sparc/Makefile die Optionen geändert. Dieser Kern läuft bei mir nun seid einigen Tagen stabil. Du hast damit alles an Infos, die du brachst um den Kern nachzubauen.

Mir ist noch nicht ganz klar, warum der von mir gebaute Kern nicht auf deinem 2x125 Rechner läuft. Eigentlich kann dies nur ein Problem am Filesystem sein. Hängen deine Platten an dem interen ESP SCSI oder bootest du von einer externen Platte UND einem 2.ten SCSI Kontroller (Qlogic)? Wenn ja, musst du den QLogic Treiber natürlich aktivieren, der bei mir nur als Modul nachgeladen werden kann. Auch "von einem Array booten" müsste mit meinem Kern fehlschlagen da die Module dazu nachgeladen werden. Mein Kern ist nur zum booten von einer internen Platte am Bordeigenen ESP mit ext3 /boot bzw. / ausgelegt. Mein /boot liegt dabei in der / und nicht als eigene Partition vor so das also auch /lib mit den Modulen erreicht werden kann wenn / gemountet wird. Poste doch mal bitte dazu Deine komplette /etc/fstab. Auch eine etwas genauere Fehlerbeschreibung würde mir ggf. schon helfen. Versuch evtl. auch mal die Platte aus dem 4x100 Rechner in dem Rechner mit 2x125 laufen zu lassen... wenn die Hardware ok ist, müsste der 2x125er ja mit der Platte aus dem Stand hochkommen.

Für Leute die ext2 UND ext3 im Kern brauchen, wäre übrigens evtl. interessant, das NCP Netzwerk File System (Novell Shares) und das XFS Filesystem sowie das IPv6 abzuschalten... es gibt schon noch einige Möglichkeiten, den Kern kleiner zu kriegen.... Grundsätzlich gilt: der Kern sollte wirklich nur nützliches enthalten... und den Rest in Module packen und/oder ganz abschalten.

Ich muss wirklich sagen.... Debian auf Sparc32 ist inzwischen eine gute Wahl... aber nix für Linux Anfänger und Leute ohne Geduld Aber solche Leute wären mit ner SS20 sowieso nicht glücklich zu machen... egal welches Sys da werkelt.
Mich würde nun brennend interessieren, warum der grsecurity patch so übel daneben geht... denn in der Antwort dieser Frage liegt IMHO auch ein grosser Teil der Probleme, warum z.B. die 2.6er Kerne auf Sparc32-smp nicht gehen und SMP auf Sparc32 wohl grundsätzlich nicht unproblematisch scheint.

Gruß RolfD

[astronom]

Hallo Astronom,
es freut mich sehr, das der von mir gebaute Kern bei deiner 4x100er läuft.
Es gibt nichts schlimmeres wie wenn man "nicht reprduzierbare Ergebnisse" hat.. von da her ist dies ein wichtiger Schritt.

Zur Kernel config:
(Keine weiteren änderungen)

Du brauchst mir nicht alles Haarklein erklären, ich bin schon seit einigen Jahren Linuxer und betrachte mich inzwischen als recht fit

Zum 2.4.31 Kern:
Ich habe wie bereits beschrieben das .config File aus der 2.4.27-2 genommen und es in den Source Tree für den 2.4.31 kopiert, dort dann mit "make menuconfig" weitere kleinere Einstellungen vorgenommen (im Bereich NetFilter) und ebenfalls dort in arch/sparc/Makefile die Optionen geändert. Dieser Kern läuft bei mir nun seid einigen Tagen stabil. Du hast damit alles an Infos, die du brachst um den Kern nachzubauen.

Heute schon zweimal gemacht - beim zweiten mal (interessanterweise mit der gleichen config wie beim ersten mal) lief der Kernel kann.

Mir ist noch nicht ganz klar, warum der von mir gebaute Kern nicht auf deinem 2x125 Rechner läuft. Eigentlich kann dies nur ein Problem am Filesystem sein. Hängen deine Platten an dem interen ESP SCSI oder bootest du von einer externen Platte UND einem 2.ten SCSI Kontroller (Qlogic)?

Die 125er-Sun hat nur den internen Controller. Meine hiesige hat _glaube_ ich zwei Controller. Allerdings habe ich die Karte bisher auch nicht weiter identifiziert - die steckt einfach noch drin damit sie aufgeräumt ist.

Die Platte in der 125er hat nur zwei Partitionen - /dev/sda1 (root, 1,6 GB, ext3) und /dev/sda2 (swap, 360 MB). Aber der Kernel wurde ja nicht mal richtig gebootet. Wenn ich wieder an der Sun sitze (frühestens am Wochenende) kann ich genaueres abtippen.

[RolfD]

Hallo Astronom,

Du brauchst mir nicht alles Haarklein erklären, ich bin schon seit einigen Jahren Linuxer und betrachte mich inzwischen als recht fit

Nun ich erkläre es deshalb so genau um Missverständnisse zu vermeiden, und um Leuten diesen Weg zu ermöglichen, die nicht Meine oder Deine Erfahrung haben. Ausserdem ist das Thema sparc32 und SMP auf Debian (auch weil Redhat/SUsE und andere {z.B. der Sparc Kernel Programmierer Dave Miller} ihre Bemühungen zur arch sparc32 offiziell eingestellt haben - nicht zuletzt wegen angeblich kaum zu lösender Probleme mit dem Arch Code ) ein sehr wichtiges Thema. Auch die Menge an Klicks für den Thread zeigen, das hier grosses Interesse besteht!
Nimm das also bitte nicht persönlich auf dich bezogen.
 

Heute schon zweimal gemacht - beim zweiten mal (interessanterweise mit der gleichen config wie beim ersten mal) lief der Kernel kann.

Mir ist schon einige Male aufgefallen, das es Unterschiede zwischen einem Kaltstart, einem Reset mittels OBP-Befehl und einem Stop-a/Resume gibt. Dies ist evtl. auf das OBP zurück zu führen bzw. ein weiteres Problem von SILO. Dementsprechend startet manchmal der Kernel auch bei mir nicht und bleibt einfach hängen. Ein Kaltstart bringt das System jedoch meist fehelrfrei hoch und ein "reboot" in der shell ist - so weit ich mich erinnere - auch noch nicht hängen geblieben. Gibt man am Siloprompt jedoch Befehle ein, kann der anschliessende Start dann hängen bleiben. Wie gesagt, IMHO ein SILO Problem da SILO immer gestartet wird, jedoch der Kern manchmal hängt (weil er nicht richtig initialisiert wird).

Die 125er-Sun hat nur den internen Controller. Meine hiesige hat _glaube_ ich zwei Controller. Allerdings habe ich die Karte bisher auch nicht weiter identifiziert - die steckt einfach noch drin damit sie aufgeräumt ist.

Die Platte in der 125er hat nur zwei Partitionen - /dev/sda1 (root, 1,6 GB, ext3) und /dev/sda2 (swap, 360 MB). Aber der Kernel wurde ja nicht mal richtig gebootet. Wenn ich wieder an der Sun sitze (frühestens am Wochenende) kann ich genaueres abtippen.

Die / auf /dev/sda1 sollte nicht grösser als 1 GB sein. Dazu gibts hier im Forum ebenfalls massenweise Hinweise. Ich sagte auch schon mal das SILO im Prinzip ein sehr alter LILO ist... bei dem es das gleiche Problem auch in i386 gab. Eine 2Gb Platte ist für ein Linux eh etwas sehr schwachbrüstig. Das nur als Tip zur Partition. Der "nichtidentifizierte Controller" ist anhand seiner Part Nr. sehr leicht zu identifizieren. Schau mal bei http://sunstuff.org/ vorbei. Wegen Platten... da gibts noch nen ganz gemeinen Fallstrick:

Die Sun bootet von der Platte auf der SCSI ID 3. Die wird in Linux auch richtig als /dev/sda erkannt. Baut man nun eine Platte hinzu, läuft diese meist als SCSI ID 1 (im OBP kontrollieren!). Die Sun bootet weiterhin von der ID 3. Das habe ich soweit aus diversen Sun Docu's und das lässt sich im OBP auch umstellen. Bootet das Linux System aber nun von ID 3, werden auch wieder die Patten erkannt.. und weil dabei ID 1 vor ID3 kommt, wird nun die Platte auf ID 1 zur /dev/sda und die Platte mit ID 3 dann /dev/sdb! Als Folge stimmen nun z.B. die nicht ganz unbedeutenden Einträge in der /etc/fstab und/oder silo.conf zum root fs nicht und der Bootvorgang MUSS fehlschlagen. Wer sich eine Platte zusätzlich ins Sysem hängen will, sollte sich also VORHER Gedanken zu dem Problem machen! Um dies Problem zu umgehen habe ich mein Sys von Anfang an mit 2 Platten installiert und boote daher von ID3 alias /dev/sdb1. Mit einer weiteren Platte würden aber wieder Probleme auftauchen weil die bootplatte dann z.B. /dev/sdc1 ist. Ohne Probleme lassen sich nur Platten auf ID 4,5 und 6 nachrüsten (ID 6 ist evtl. für ein vorhandenen Streamer vorbehalten). Andere Systeme (NetBSD?) benutzen teilweise die Devicedescriptoren wie bei Sun üblich... (so 'komische' devicenamen die sich kein Mensch merken kann , auch im OBP zu finden) so das diese das Problem weiträumig umgehen... eigentlich ist dies aber auch unter Linux mit den /dev/sdxX Namen kein Problem wenn man das Gesagte berücksichtigt.

Gruß RolfD