Disk-Device-Reihenfolge

[freewind]

@willy4711
wir haben aneinander vorbei geredet.
Es ging nicht um den Eintrag "sdX" in der /boot/grub/grub.cfg sondern um den Eintrag im MasterBootRecord.

Jetzt ist im MBR /dev/disk/by-id/ata-WDC_WD3000HLHX-60JJPV1_WD-WX11E61SR434 eingetragen.
Anscheinend hat sich das Problem sda<->sdb erledigt.

Ich bekomme jetzt allerdings beim booten noch einige Fekler bzgl. mdadm: no array found in config...
Werde das mal untersuchen.

Danke

[fischig]

Das ganze ist folglich ein grub-Konfigurationsproblem, nix mit:

Je nach Lust und Laune mixt das System die Device-Order!?!

„Order“? Gemeint: Ordnung/Reihenfolge?

[freewind]

Das denke ich nicht.

Die Ursache bleibt ein Problem (vermutlich Timing) von Debian. Die Ordnung ist von der HW vorgegeben. Platte an SATA-Port

Selber Kernel-log, unterschiedliche Zuweisung
kernel: [ 104.171285] sd 0:0:0:0: [sda] Starting disk kernel: [ 177.100884] sd 0:0:0:0: [sdb] Starting disk
kernel: [ 104.171290] sd 1:0:0:0: [sdb] Starting disk kernel: [ 177.100904] sd 1:0:0:0: [sda] Starting disk
kernel: [ 104.171310] sd 3:0:0:0: [sdc] Starting disk kernel: [ 177.100923] sd 3:0:0:0: [sdc] Starting disk


kernel: [ 2.312757] sd 0:0:0:0: [sda] 586072368 512-byte logical blocks: (300 GB/279 GiB)
kernel: [ 2.312761] sd 1:0:0:0: [sdb] 586072368 512-byte logical blocks: (300 GB/279 GiB)
kernel: [ 2.312786] sd 3:0:0:0: [sdc] 312500000 512-byte logical blocks: (160 GB/149 GiB)

kernel: [ 2.312557] sd 0:0:0:0: [sdb] 586072368 512-byte logical blocks: (300 GB/279 GiB)
kernel: [ 2.312558] sd 1:0:0:0: [sda] 586072368 512-byte logical blocks: (300 GB/279 GiB)
kernel: [ 2.312561] sd 3:0:0:0: [sdc] 312500000 512-byte logical blocks: (160 GB/149 GiB)

Ohne Änderung an der HW bekommen die Platten zufällige devices zugeordnet. Man sieht auch daß die dritte Platte am SATA-Port 3 anstatt 2 hängt.
Mit grub habe ich die Möglichkeit nicht das /dev/sdX in den MBR zu schreiben sondern /dev/disk/by-id/

[towo]

Die Ursache bleibt ein Problem (vermutlich Timing) von Debian.

Nein, das ist ist genau kein Problem von Debian! Alle aktuellen Kernel haben durch udev keine feste Reihenfolge der Devices.

[freewind]

Also kein Bug sondern ein Feature
udev ist für UNIXer aus den 80gern

[RobertS]

…
udev ist für UNIXer aus den 80gern

Ja und? Es tut. HAL war nicht wirklich besser.

[fischig]

Debian-Kerne benötigen udev, aber das dürfte bei Ubuntu-Kernen nicht anders sein, denke ich. Wenn du für Debian deinen Kern aus den Quellen von kernel.org selbst baust, benötigst du keine initrd und damit kein udev, wenn du devtmpfs gemountet einkompilierst. Ich möchte fast wetten, dass du damit eine stabile Reihenfolge deiner Platten beim Booten erhältst. Keine Ahnung, wie das Gnome-Universum damit zurechtkommt.

[freewind]

OK Leute,

es waren sicherlich tolle Zeiten, als fast jeder noch sein eigenes OS geforkt, umgeschrieben oder erfunden hat.
ABER, auch wenn jetzt einigen der Glühwein in den Adern gefriert:
Ich bin Nutzer / Anwender, kein Coder! Installieren, anpassen, nutzen - fertig!
Wenn ich mir mein OS noch selber bauen wollte, wäre ich bei AmigaOS geblieben.
Wir leben nun mal nicht mehr AnnoDazumal!
Ich zieh kein Schwein in der Wohnung groß um es irgendwann zu schlachten, auszunehmen und zu Salami zu verwursten. Ich geh in den nächsten Supermarkt und kauf sie.

Eure Einstellung ist völlig OK, für Euch. Ich/Wir wollen damit schaffen, nicht frikeln.

So, genug damit.
Auf ein hoffentlich Absturzfreies Neues Jahr

[fischig]

es waren sicherlich tolle Zeiten, als fast jeder noch sein eigenes OS geforkt, umgeschrieben oder erfunden hat.

Niemand hat gesagt, dass du das machen sollst, aber wenn du es nicht willst, musst du trotzdem das gegebene System sachgemäß konfigurieren und das läuft in Debian nun mal über udev. Will sagen: Ob und was du da warum im Vergleich zu Ubuntu fehlkonfiguriert hast, bleibt für mich ungelöst. Nicht das System (Debian) „(mixt) je nach Lust und Laune [...] die Device-Order!?!"

[DeletedUserReAsG]

Eure Einstellung ist völlig OK, für Euch. Ich/Wir wollen damit schaffen, nicht frikeln.

Dann konfiguriert’s halt einmal ordentlich. Oder bleib bei Ubuntu, wenn das für dich besser funktioniert (ernst gemeint).

[DefaultXXL]

Ein freundliches Hallo in die Runde. Ich musste mich jetzt einfach mal anmelden (lese seit Jahren mit) um auf diesen Thead meine Erfahrungen mitzuteilen.

Vorweg: Ich schwanke immer zwischen Debian und Ubuntu, seit ich 2012 auf apt umgestiegen bin. Aus ein paar für mich wichtigen technischen Gründen nutze ich derzeit die Ubuntu-LTS-Basis.

Ist das Debian-Typisch ?

Nein. Das macht Ubuntu auch. Vermutlich alle anderen auch.

Habe ich irgendwo Mist gebaut oder ist das ein Bug oder ist das lösbar?

Das scheint Kernel-abhängig zu sein. Bis 5.0 ging das noch. Ich beobachte das Phänomen seit Kernel 5.3.

Bis Oktober 2020 habe ich zuletzt mit Kubuntu gearbeitet. Als ich erstmals Kubuntu 19.10 installierte (September 2019), hatte ich das selbe Phänomen: Mal lag die Folge sda bis sdc so herum, mal ganz anders gestaffelt. Das wechselt mit jedem Neustart. Egal, mit welchem Laufwerk gestartet wird oder wo /boot liegt bzw. der MBR liegt. Dabei achte ich seit Jahrzehnten darauf, dass ich auch "richtig" auf dem Mainboard anstöpsel. /dev/sda-Laufwerk war bei mir auch immer auf dem ersten Port des Mainboards, genauer gesagt der Master des jeweiligen Ports. Kann man im BIOS nachvollziehen. Das scheint jetzt grundsätzlich vom Kernel anders interpretiert zu werden.

Am Mainboard liegt es nicht. Denn eine alte Linux Mint Installation macht immer noch dasselbe (erster SATA-Port (Master) ist immer /dev/sda). Vor ein paar Wochen bin ich zu Cinnamon gewechselt, und habe mit Linux Mint Cinnamon (basiert auf Ubuntu LTS 20.04) wieder das gleiche Problem. Kernel 5.4.

In der grub.cfg steht natürlich die UUID der Partition drin, nicht /dev/sda usw. So wie der Installer das macht. Da ich das Bootlaufwerk im BIOS definiert habe, fällt das Problem garnicht auf. sda, sdb usw. spielt keine Rolle mehr. UUID ist state-of-the-art.

Dann konfiguriert’s halt einmal ordentlich. Oder bleib bei Ubuntu, wenn das für dich besser funktioniert (ernst gemeint).

Nützt nichts. Siehe oben.

[DeletedUserReAsG]

Dann konfiguriert’s halt einmal ordentlich. Oder bleib bei Ubuntu, wenn das für dich besser funktioniert (ernst gemeint).

Nützt nichts. Siehe oben.

Naja … oben beschreibst du ja selbst, dass es mit einer richtigen Konfiguration sehr wohl funktioniert. Insofern …

[DefaultXXL]

Jetzt habe ich hier eine Lösung für Menschen, die das mit der Maus brauchen, und einen String der korrekten Geräte-Angabe haben wollen. Ein klitzekleines Ding, welches die Information holt und gleich in den Zwischenspeicher schreibt. Also nicht viel anders, als "Copy" mit der Maus zu machen.

Schritt 1:
Wir installieren dieses hier:

Code: Alles auswählen

apt-get install python3-pyperclip

Schritt 2:
Wir schreiben diese Programm (ich habs mal where_is_my_drive genannt):

Code: Alles auswählen

#!/usr/bin/python3.8

import pyperclip
import subprocess

batcmd="/sbin/blkid --uuid hier_steht_die_UUID_der_Partition"

output = subprocess.check_output(batcmd,shell=True,)
result = output.decode('utf-8')
pyperclip.copy(result)

Bitte auf die Python3-Version achten, und ggf. die Shebang-Zeile anpassen.
Python 3.8 ist aktuell. In LTS 20.04 liegt 3.7 drin.
Ggf. einen Link setzen von python3.8 auf python3. Im Verzeichnis /bin oder /usr/bin, wo Python drin ist.
Dann reicht /usr/bin/python3 in der Shebang-Zeile. Siehe auch:

Code: Alles auswählen

$ whereis python

Bei mir war's

Code: Alles auswählen

# ln -s /usr/bin/python3.8 /usr/bin/python

weil bei mir python2 schon lange keine Rolle mehr spielt.


Schritt 3:
Wir machen es ausführbar

Code: Alles auswählen

$ chmod u+x where_is_my_drive

(woimmer es auch steht)

Schritt 4:
Wir schieben es an eine geeignete Stelle

Code: Alles auswählen

$ sudo mv where_is_my_drive /usr/local/bin/

Schritt 5:
Wir legen uns einen Starter an oder schreiben es ins Menü, ziehen es dann bestenfalls in die Kontroll-Leiste.

Dann reicht ein Doppelklick darauf (in der Kontroll-Leiste ein einfacher Klick) und es steht anschließend im Zwischenspeicher. Da ich schon lange nicht mehr den Grub-Customizer genutzt habe, weiss ich nicht, ob man so zum Ziel kommt; also im nächsten Schritt den "Paste" in den Grub-Customizer zu machen, wenn es geht.

Unter Linux Mint Cinnamon läuft dieses Python3-Programm; wobei ich ein bin-Verzeichnis im User-Verzeichnis habe, um derlei Hilfen für die Maus zu haben. Dann muss man natürlich an den Pfad denken. /usr/local/bin steht im Regelfalle in der Pfad-Definition des Users drinne. Unter Umständen muss man das Python-Paket für Python's subprocess ebenso installieren. Weiss ich aber nicht. Bei mir war's schon da. Und man muss natürlich individuell die Variable batcmd richtig bestücken, mit der richtigen UUID.

Ich freue mich über Feedback.

[DeletedUserReAsG]

Ich freue mich über Feedback.

Zuerst mal: Respekt, dass du dich so ins Zeug legst. Aber dann: so ein Aufwand, nur, um das Eingeben eines Befehls und das Lesen der Ausgabe desselben zu umgehen? Das bedient irgendwie wieder alle gängigen Vorurteile – war das Absicht?

Außerdem: der Beitrag wurde offensichtlich für das Buntu-Forum geschrieben, und sollte zunächst auf Debian Stable adaptiert und getestet werden, bevor der hier reingemalt wird.