(gelöst) grub2 findet 2. installation nicht

[michaa7]

System: Debian/sid(uction) tagesaktuell, grub2/pc

Irgendewtwas habe ich wohl wiedermal falsch gemacht bei der installtion von grub:


Meine hauptinstalltion befindet sich auf sdc1, eine 2. installation auf sda1. Ein grub-update von der gebooteten sdc1 installation aus findet die installtion auf sda1 nicht (mehr). Nicht mehr weil das mal funktionierte.

Was ist eigentlich die voraussetzung dafür dass eine installation gefunden wird?

1. Muss die entsprechende partition gemountet sein?
2. Wo muss ggf. grub2 dort installiert sein?
3. Geht das nur über chainloader?

Was ich erreichen will ist dass ich die installation auf sda1 wieder im grub auswahlmenü der sdc1 installation vorfinde. Wie fixe ich das von der sdc1 installtion aus?

[pferdefreund]

Kenne mich mit grub zwar nicht aus - aber ich vermute mal, dass die gemountet sein muss. Wie soll er die denn sonst finden ?
Soweit ich weiß, kann man das auch irgendwo in der grub-Konfiguration eintragen - aber wie gesagt - bin da weitestgehend ahnungslos, weil Lilo-Nutzer.

[DeletedUserReAsG]

1. nein
2. „muss“ gar nicht. Kann man zwar machen, aber macht’s unnötig kompliziert.
3. nein. Kann man zwar machen, aber macht’s unnötig kompliziert.

os-prober ist installiert und funktioniert?

Wenn‘s gar nicht funktionieren sollte (etwa, weil os-prober oder etwas Anderes in Sid gerade kaputt/fehlkonfiguriert ist), kann man es immer noch manuell confen. Dazu einfach einen weiteren Eintrag für das gewünschte System erstellen.

[michaa7]

os-prober ist natürlich in seiner neuesten inkarnation installiert - und funktioniert. Es werden ja bei jedem kernelupdate meine hauptinstalltion plus die älteren kernel plus die auf einer ganz anderen partition liegenden linux.iso's gefunden. In der vergangenheit (bis vor zwei,drei wochen) wurde eben auch mein zweitsystem gefunden. Nun taucht es nicht mehr auf.

EDIT: Allerdings gibt es seit etwa dieser zeit einen merkwürdigen eintrag in der liste:

logger: socket /dev/log: Datei oder Verzeichnis nicht gefunden

taucht in der erzeugten liste 16 mal untereinander auf.

Möglicherweise hängt dies mit dem nichtauffinden der besagen installtion zusammen, denn diese meldungen steht genau an der stelle in der reihnfolge der gefundenen installtionen, an der bisher der nun fehlende eintrag stand. Ich habe nach dieser meldung gegoogelt, aber nichts gefunden was irgendwie hilfreich gewesen wäre. /EDIT

Es geht also nicht darum ob os-prober nicht mehr funktioniert, sondern warum eine spezifische installation nicht mehr auftaucht. Wenn ich die partition der betreffenden installation mounte ist auch alles da. Warum also findet os-prober die installtion auf /dev/sda1 nicht mehr? BTW, händisches gefummle möchte ich vermeiden, dazu habe ich ja os-prober, eigentlich ...

[Apfelmann]

Teste mal mit der Super-Grub-Disk,
damit kann eigentlich so gut wie alles gebootet werden

https://www.supergrubdisk.org/

LG

[DeletedUserReAsG]

Es geht also nicht darum ob os-prober nicht mehr funktioniert, sondern warum eine spezifische installation nicht mehr auftaucht.

Was denn nun? Es geht nicht darum, ob’s funktioniert, sondern darum, dass es nicht (richtig) funktioniert?

Möglicherweise fehlt ihm ein Erkennungsmerkmal des betreffenden Systems. Da kann man ohne weitere Infos dazu aber auch nur raten.

[michaa7]

...erkennungsmerkmale ...

als da wären?

Im direkten vergleich sieht die betroffene installtion auch nicht anders aus als meine hauptinstallation. Das letzte mal hat es wohl anfang des monats funktioniert, das ist am datum des lletzten kernels ablesbar.

Welche infos zu welchen merkmalen wären denn hilfreich?

Und die fehlermeldung, irgendeine idee?

EDIT:

menuentry "neuinstall"{
set root=(hd0,1)
chainloader +1
}

Dieser neue eintrag in /etc/grub.d/40_custom sollte die fehlende intallation doch eigentlich in das grub menue einbinden, tut es aber nach erneutem ausführen von update-grub nicht.

[DeletedUserReAsG]

Zu den Fehlermeldungen kann ich nix weiter sagen. Ich weiß nur, dass damals, als ich os-prober noch genutzt habe, regelmäßig gar grausige Meldungen im Log waren, wenn es gelaufen ist. Ebensowenig kann ich aus dem Kopf was zu den Kriterien sagen – da müsste ich in der Doku nachschauen. Und bevor ich das nun mache und dir hier schreibe, was drinsteht, kannst du auch selbst reinschauen (oder warten, bis jemand hier reinschaut, der’s im Kopf hat).

[michaa7]

Das problem hängt wohl mit systemd zusammen. Boote ich sysvinit von der selben installtion, kann ich os-prober erfolgreich ausführen und die besagte 2. installation wird auch gefunden und erhält einen menüeintrag -- genau an der stelle an der sonst diese komischen fehlermeldungen auftauchen. Letztere sind nun auch nicht vorhanden. Einige google findings sowie fehlermeldungen bein systemd --reinstall legen nahe dass es loggingprobleme mit systemd gibt.

In soweit halb gelöst, mal schaun ob das nen bugreport gegen systemd ergibt ...

[smutbert]

Das mit chainloader funktioniert nur, wenn es im PBR (Partition Boot Record) der angegebenen Partition (hier wäre es also die 2. Partition auf der ersten Platte) auch tatsächlich einen Bootloader oder etwas ähnliches zum Landen gibt. Den ersten Teil von grub schreibt man aber normalerweise in den MBR. Bei zwei Linuxinstallationen auf einem PC kommt man so ohne weitere Maßnahmen also erst einmal nicht weiter.

Wovon es abhängt ob os-prober richtig funktioniert oder nicht, habe ich übrigens auch noch nicht herausbekommen. Meistens erkennt er alles richtig, aber manchmal scheitert er ohne für mich ersichtlichen Grund.


Ich würde einen eigenen Eintrag in dieser Form schreiben

Code: Alles auswählen

menuentry 'GNU/Linux XYZ' {
    search --no-floppy --fs-uuid --set=root xxxxxxx
    configfile /boot/grub/grub.cfg
}

Statt "xxxxxxx" musst du die UUID der /-Partition der Linuxinstallation angeben, die gestartet werden soll. Für den Fall, dass es eine eigene Partition für /boot gibt, muss es etwas angepasst werden (Pfad und UUID).


Das hat den Vorteil, dass man auf der Hauptinstallation nicht update-grub ausführen um den aktuellen Kernel der anderen Installation booten zu können, weil der Eintrag nicht direkt auf den Kernel sondern auf die grub-Konfigurationsdatei der „Nebeninstallation“ verweist und die grub-Konfiguration wird von der „Nebeninstallation“ (hoffentlich) automatisch auf dem aktuellen Stand gehalten.
Gegenüber deinem ohnehin nicht funktionierenden Beispiel mit dem chainloader bietet die Angabe mittels UUID auch noch den Vorteil der Unempfindlichkeit gegenüber Änderungen der Reihenfolge der Festplatten (die kann es abhängig von der Hardware auch spontan von Systemstart zu Systemstart geben).

[michaa7]

Gelöst.

Schuld war systemd, das sich wohl irgendwie verwurstelt hatte.

Ein booten der hauptinstalltion mit sysvinit, dann

Code: Alles auswählen

init 3

, dann ein beherztes

Code: Alles auswählen

apt purge systemd

gefolgt von

Code: Alles auswählen

apt install systemd

lies darauffolgend

Code: Alles auswählen

update-grub

ohne fehlermeldung und mit auflistung meiner zweitinstallation durchlaufen. Alle systeme booten wieder

@ smubert

Danke!

Dass mein eintrag fehlerhaft war vermutete ich schon bei der erstellung, ich hatte das irgendwie anders in erinnerung und deine variante wird wohl die richtige sein. Aber solange nun wieder alles normal funktioniert lasse ich es mal dabei, zumal zukünfig die zweitinstallation vielleicht meine hauptinstallation ersetzen wird ... mal sehn ...