ubuntuusers.de

Hallo, ich habe ein Mehrfach-Ubuntu auf USB-SSD installiert und kriege auch die entsprechenden Menüs mit den Derivat-Anzeigen - allerdings wird meine USB-SSD manchmal auf sda angezeigt, manchmal auf sdd (ohne dass ich sie abgestöpselt hätte). Da ich die Derivate (Xu/Lu usw Buntu) und ihre UUIDs in der für die Grub-Menüanzeige zuständigen Datei gksudo gedit /etc/grub.d/40_custom alle auf sda eingetragen hatte, habe ich den Eindruck der Bootvorgang stockt, sobald die Disk auf sdd geführt wird (z.B. Meldung "signature error sda5 not exist") oder es erscheint die Meldung (initramfs). Ich muss dann neu Booten ehe es wieder funktioniert. Im Moment funktioniert es wieder.

Kann man eine Disk "zwingen" immer auf eine bestimmte Position zu gehen ?

PS: bitte an dieser Stelle nicht diskutieren WARUM ich DIESE Methode der Menüanzeige bei Mehrfach-*Buntu gewählt habe. Ich habe es aus dem Forum übernommen und nicht selbst erfunden.

rokkybuntu schrieb:

Kann man eine Disk "zwingen" immer auf eine bestimmte Position zu gehen ?

Nein. Aus dem Grund verwendet man auch nicht die Bezeichnungen sondern die UUIDs in solchen solchen Skripten...

tomtomtom schrieb:

Nein. Aus dem Grund verwendet man auch nicht die Bezeichnungen sondern die UUIDs in solchen solchen Skripten...

Ich verwende ja UUIDs. Heisst das, dass das Stocken beim Booten gar nichts mit der Position der Disk auf sda oder sdd zu tun hat, sondern dass ich den Fehler woanders suchen muss?

rokkybuntu schrieb:

Ich verwende ja UUIDs.

Deiner Fehlerbeschreibung nach nicht. Und deiner eigenen Aussage nach auch nicht. Wenn in dem Skript UUIDs verwendet werden werden dort keine Device-Bezeichnungen verwendet und somit kann das Problem gar nicht auftreten.

Tritt es doch auf verwendest du dort keine UUIDs. Das Problem kann man dann beheben, indem man UUIDs verwendet...

Heisst das, dass das Stocken beim Booten gar nichts mit der Position der Disk auf sda oder sdd zu tun hat, sondern dass ich den Fehler woanders suchen muss?

Das heißt, dass die Fehlermeldung, dass /dev/sdX nicht gefunden werden kann daran liegt, dass keine UUIDs verwendet werden, denn dann wäre diese Meldung schlichtweg nicht möglich.

Und im Übrigen heißt die genannte Datei nicht gksudo gedit /etc/grub.d/40_custom sondern /etc/grub.d/40_custom. Klingt zwar logisch, ist aber so.

tomtomtom schrieb:

Das heißt, dass die Fehlermeldung, dass /dev/sdX nicht gefunden werden kann daran liegt, dass keine UUIDs verwendet werden, denn dann wäre diese Meldung schlichtweg nicht möglich.

Und im Übrigen heißt die genannte Datei nicht gksudo gedit /etc/grub.d/40_custom sondern /etc/grub.d/40_custom. Klingt zwar logisch, ist aber so.

Danke, ich weiss dass du gerne "sarkastisch mit Logik" antwortest (obwohl du vielleicht ein netter Kerl bist, wer weiss das schon?). Zugegebenermaßen könnte meine Frage etwas anfängerhaft wirken, ich werde mich bessern! 😢

Nur zur Info hänge ich mal einen Teil des Inhaltes der Datei /etc/grub.d/40_custom an, woraus man erkennt wie die in meinem Falle aufgebaut ist - mit UUIDs:

!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.
menuentry "Ubu1404 auf /dev/sda1" {
   insmod ext2
   set root=(hd3,2)
   search --no-floppy --fs-uuid --set=root daeef1ab-e479-4681-9f8a-44e49bf9c76c
   configfile /boot/grub/grub.cfg
   chainloader +1
   
   }
   
menuentry "Mate auf /dev/sda2" {
   insmod ext2
   set root=(hd3,2)
   search --no-floppy --fs-uuid --set=root 0aefb103-6ed7-4efb-a77b-e5f0c8d5a869
   configfile /boot/grub/grub.cfg
   chainloader +1
   
   }

Ja, "einen Teil" der Datei zu zeigen ist immer unheimlich praktisch, den Rest kann man ja per Stochastik ermitteln...

Sofern der Rest der Datei ähnlich aufgebaut ist ist die Fragestellung weiterhin falsch.

Denn das Problem ist hier nicht /dev/sdX sondern die feste Angabe von z.B. set root=(hd3,2).

Das lässt sich bei Chainloading aber schlecht ändern.

tomtomtom schrieb:

Ja, "einen Teil" der Datei zu zeigen ist immer unheimlich praktisch, den Rest kann man ja per Stochastik ermitteln...

Sofern der Rest der Datei ähnlich aufgebaut ist ist die Fragestellung weiterhin falsch.

Denn das Problem ist hier nicht /dev/sdX sondern die feste Angabe von z.B. set root=(hd3,2).

Das lässt sich bei Chainloading aber schlecht ändern.

Vielen Dank, ja, der Rest ist genauso aufgebaut. Wie gesagt, das habe ich nicht erfunden, dazu reicht meine Kenntnis nicht, sondern dazu haben mir mehrere freundliche Helfer hier im Forum verholfen.

Was wäre die Alternative für: set root=(hd3,2) ?

Hier der komplette Inhalt:

#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries.  Simply type the
# menu entries you want to add after this comment.  Be careful not to change
# the 'exec tail' line above.

menuentry "Ubu1404 auf /dev/sda1" {
   insmod ext2
   set root=(hd3,2)
   search --no-floppy --fs-uuid --set=root daeef1ab-e479-4681-9f8a-44e49bf9c76c
   configfile /boot/grub/grub.cfg
   chainloader +1
   
   }
   
menuentry "Mate auf /dev/sda2" {
   insmod ext2
   set root=(hd3,2)
   search --no-floppy --fs-uuid --set=root 0aefb103-6ed7-4efb-a77b-e5f0c8d5a869
   configfile /boot/grub/grub.cfg
   chainloader +1
   
   }
    
menuentry "Gnome auf /dev/sda3" {
   insmod ext2
   set root=(hd3,3)
   search --no-floppy --fs-uuid --set=root 86f3262e-3827-4860-97ea-1d5637423fd1
   configfile /boot/grub/grub.cfg
   chainloader +1
   
   }
menuentry "Mint auf /dev/sda5" {
   insmod ext2
   set root=(hd3,2)
   search --no-floppy --fs-uuid --set=root c1e899f0-c283-442a-b4cb-e33fad4177fc 
   configfile /boot/grub/grub.cfg
   chainloader +1
   
   }
   
menuentry "Xubu auf /dev/sda6" {
   insmod ext2
   set root=(hd3,3)
   search --no-floppy --fs-uuid --set=root 1643f0a3-60af-46bb-83f5-1b305e51e945 
   configfile /boot/grub/grub.cfg
   chainloader +1
   
   }
menuentry "Lubu auf /dev/sda7" {
   insmod ext2
   set root=(hd3,2)
   search --no-floppy --fs-uuid --set=root e71c47e0-d468-4725-b998-9494fc8b17c5 
   configfile /boot/grub/grub.cfg
   chainloader +1
   
   }
   

rokkybuntu schrieb:

Was wäre die Alternative für: set root=(hd3,2) ?

Für Chainloading gibt es die nicht.

Die generelle Alternative ist eben keinen chainloader zu benutzen. Dafür darfst du dann natürlich auch kein os-prober benutzen und musst eigene Skripte für jede Distribution anlegen.

Siehe dazu GRUB 2/Skripte und die verlinkten Quellen.

tomtomtom schrieb:

Dafür darfst du dann natürlich auch kein os-prober benutzen

In der /etc/default/grub hatte ich den abgeschaltet:

GRUB_DISABLE_OS_PROBER="true"

Siehe dazu GRUB 2/Skripte und die verlinkten Quellen.

Das bringt mich zwar im Moment nicht weiter, aber es liefert zumindest eine Erklärung. Und meine eigentliche Frage "Disk auf Position zwingen (?)" ist beantwortet, wenn auch mit "nein". Danke.

Hej rokkybuntu,

rokkybuntu schrieb:

... Kann man eine Disk "zwingen" immer auf eine bestimmte Position zu gehen ?

mir ist noch kein System untergekommen, in dem das nicht so wäre:

• das im BIOS an erster Stelle der Bootreihenfolge (von dem dann auch gebootet wird) ist das device 0 (fd0,..., hd0/sda)

• bootest Du z. B. vom Stick, und möchtest mit dessen grub die interne Platte booten, kann Dir ein drivemap -s helfen. (ist aber hier nicht der Fall)

Ich kann Deine Fehlerbeschreibung nicht nachvollziehen. Prüfe mal in der grub Konsole (Taste C ) die Position der Datenträger

ls

tomtomtom schrieb:

... Für Chainloading gibt es die nicht.

Die generelle Alternative ist eben keinen chainloader zu benutzen.

das hat mit chainloading nichts zu tun, dafür muß lediglich ein grub im PBR (bzw. MBR, wenn z. B. von einem Stick eine interne Platte gebootet werden soll) installiert sein. Außerdem kommt das in der beschriebenen Form gar nicht zum Tragen, da steht ja vorher, daß das configfile geladen werden soll, was grub dann auch tut, so es an der angebenen Stelle zu finden ist.

Gruß black tencate

black tencate schrieb:

Hej rokkybuntu,

rokkybuntu schrieb:

Ich kann Deine Fehlerbeschreibung nicht nachvollziehen. Prüfe mal in der grub Konsole (Taste C ) die Position der Datenträger

ls

Hi Blacky, da bist du ja wieder, nett dich zu sehen!

(Taste C )? Habe mal schnell ein Foto geschossen, siehe Anhang.

Falls die Position der Devices undsoweiter gezeigt werden soll, hier:

r@r:~$ sudo blkid
/dev/sda1: LABEL="Ubu1404" UUID="daeef1ab-e479-4681-9f8a-44e49bf9c76c" TYPE="ext4" 
/dev/sda2: LABEL="Mate" UUID="0aefb103-6ed7-4efb-a77b-e5f0c8d5a869“TYPE="ext4" 
/dev/sda3: LABEL="Gnome" UUID="86f3262e-3827-4860-97ea-1d5637423fd1" TYPE="ext4" 
/dev/sda5: LABEL="Mint" UUID="c1e899f0-c283-442a-b4cb-e33fad4177fc" TYPE="ext4" 
/dev/sda6: LABEL="Xubu" UUID="1643f0a3-60af-46bb-83f5-1b305e51e945" TYPE="ext4" 
/dev/sda7: LABEL="Lubu" UUID="e71c47e0-d468-4725-b998-9494fc8b17c5" TYPE="ext4" 
/dev/sda8: UUID="cc66cbcf-7b7b-44bc-ac39-49259af21c19" TYPE="swap" 
/dev/sda9: LABEL="multi ntfs" UUID="41D923225C901AA0" TYPE="ntfs" 
/dev/sdb1: LABEL="PNY SSD" UUID="741C68E81C68A6B8" TYPE="ntfs" 
/dev/sdc1: LABEL="Green" UUID="1C86CB451F8A84D4" TYPE="ntfs" 
/dev/sdd1: LABEL="System-reserviert" UUID="AAF0C74AF0C71C07" TYPE="ntfs" 
/dev/sdd2: LABEL="SYSTEM (SSD)" UUID="B616C92E16C8F103" TYPE="ntfs" 
r@r:~$ 

Ich habe die 40_Custom mal "geleert" (alle Eintragungen zwecks Menüs/Submenüs raus) und wieder mit einem Grundsystem gebootet. Jetzt gibt es keine Bootprobleme mehr. Es müsste also an den Eintragungen in der 40_Custom liegen (die ich oben anfangs gepostet habe). Irgendetwas habe ich da falsch eingetragen, werde ich mich morgen drum kümmern.

Und wir müssen das ganze Rattenschwanzthema nicht nochmal von vorne durchkauen, du (und einige weitere Helferkollegen) haben in dem von mir inzwischen "als gelöst bezeichneten" Thread (du weisst schon) schon viel zu viel Zeit investiert, ist mir schon peinlich. 🙄 Bis denne...

Hej rokkybuntu,

• black tencate schrieb:

...in der grub Konsole (Taste C ) die Position der Datenträger

ls

• ich erkenne da die interne Platte sda, einen USB Stick sdb, ein ? sdc und die (?externe?) SSD

  • wenn Du von der SSD bootest, sollte dies natürlich sda sein, genau das solltest Du mit dem o.g. Befehl auf der grub Konsole überprüfen, erkennbar an ihren 2 Partitionen muß also etwas stehen wie (hdx,1) hd(x,2). In Kombination mit 1 und 2 kommt das nur einmal vor, das x dürfte dann 0 sein, vorausgesetzt, Du steckst nicht noch irgend etwas anders an.

• Zitat: ist mir schon peinlich.

da muß Dir nichts peinlich sein, üblicherweise sagen die Helfer hier schon, wenn es ihnen 'reicht' 😈

Gruß black tencate

EDIT.: Du hast das Bild nachgeschoben, und da hast Du nicht von der SSD gebootet.

Ich habe jetzt gerade Deine ganze Historie im Kopf (weiß also nicht, welches Ziel Du eigentlich hast), da laufen noch div threads von jusy, das bringe ich jetzt aus dem Gedächtnis nicht auseinander.

EDIT2: Ach ja, mehrere Distris auf einer SSD (extern); ja warum bootest Du dann nicht von dieser externen, dann gibt es doch keine Probleme. Selbst, wenn Du einen internen grub bei angesteckter externer Platte updatest, sollte alles funktionieren.

black tencate schrieb:

EDIT.: Du hast das Bild nachgeschoben, und da hast Du nicht von der SSD gebootet.

Ja, ich habe Windows gebootet um das Foto reinschieben zu können (das ist auch eine SSD, aber keine an USB) Nur Ubuntu und Kollegen sind an USB. Normalerweise boote ich IMMER von der externen!

Ich habe jetzt gerade Deine ganze Historie im Kopf...

Das hier war mein Thread (da müssen wir aber nicht nochmal ran):

https://forum.ubuntuusers.de/topic/3-verschiedene-ubuntus-wie-kann-man-das-grub-m/

Hej rokkybuntu,

auf dem Bild (leider nicht vollständig) ist die SSD jetzt aber (hd1), oder? Warum müssen denn zusätzlich (während des Bootens) die anderen neben der internen Platte und der Bootplatte angesteckt sein?

Gruß black tencate

EDIT.: Und um dm ganzen Schlamasel aus dem Wege zu gehen, verwendest Du die UUID wie folgt

menuentry "was auch immer" {
...
search --fs-uuid --set=root <hierDeine entsprechndeUUID>
configfile /boot/grub/grub.cfg # oder aber chainloader +1
}

KEINE zusätliche Zeile mit set root= vor der search Anweisung!

black tencate schrieb:

Hej rokkybuntu,

auf dem Bild (leider nicht vollständig) ist die SSD jetzt aber (hd1), oder? Warum müssen denn zusätzlich (während des Bootens) die anderen neben der internen Platte und der Bootplatte angesteckt sein?

An USB ist nur diese bewusste MehrfachBuntu-SSD. Die anderen 3 sind intern. Ich hatte aber gerade noch ein Backup von einem Redo-Stick aus gemacht, vielleicht steckte der noch. Werde mich morgen mit deinen anderen guten Ideen befasse. So, jetzt aber Ende für Heute.