Systemstart nur noch via Live-Stick -> Detect EFI Bootloaders möglich

[nitja]

Zunächst herzlichen Glückwunsch… und dass es auch so bleibt!

Der Befehl su funktioniert natürlich, nur musste ich bei der … länglichen Aktion immer wieder das, bei mir auch längliche, Passwort eingeben.
Da war mir su - root mindestens sehr viel angenehmer.
Und ja das angegebene Passwort bezog sich auf die life-session.
chroot mit, eben der richtigen, der Kette an Folgebefehlen sollte sicher auch funktionieren.
Und da … ↑ ↗ … nimmt einem das manjaro-chroot(-script?) schon einiges ab.

[gosia]

Hallo Chris,

Code: Alles auswählen

blkid | grep a301b39e-b21e-4f39-97dd-87f8595a88ab
grep a301b39e-b21e-4f39-97dd-87f8595a88ab /etc/fstab

Komischerweise gar nichts!

Da alles wieder funktioniert, müssen wir dem nicht nachgehen.

dass man nur su bräuchte

ja. Was sagt die Manpage dazu:

Code: Alles auswählen

man su

su [options] [-] [user [argument...]]
su allows commands to be run with a substitute user and group ID.

When called with no user specified, su defaults to running an interactive shell as root. When user is specified, additional arguments can be supplied, in which case they are passed to the shell.

das aber nur, um auf die zuwenig beachteten man-Pages hinzuweisen. Hätte auch einfach vier Grossbuchstaben hinschreiben können

viele Grüsse gosia

[LaGGGer]

Hmm.. ich will jetzt nich rumunken aber ....
Ich hatte so ein ähnliches Problem auch mal, allerdings damals mit EndeavourOS.
Mein EOS fuhr irgendwann nicht mehr hoch, ich reparierte es nach Anleitung mit chroot und es funktionierte wieder.

Und zwar solange bis ich zwischendurch ein anderes System startete. Ich habe ja einen Festplattenumschaler, also:

• Laufendes System A (das reparierte) runter fahren. Umschalten auf System B, damit arbeiten, funktioniert.

• System B runterfahren, System A (das reparierte) hochfahren .... geht nicht, wieder bootet das System nicht.

• Also nochmal System A reparieren. Es funktioniert nach Reparatur mit chroot wieder.

Aber wenn ich zwischendurch ein anderes System hochfahre, kille ich -wie auch immer- System A. Das habe ich bestimmt 10x gemacht. immer dasselbe.

Bei dir kann man System A mit deinem reparierten System vergleichen, System B wäre Rescuezilla. Du kannst ja mit Rescuezilla beim Sichern nichs kaputmachen, bei rückspielen möglicherweise schon.

Wir haben den Fehler nicht gefunden. Ich musste EOS neu aufsetzen. Seitdem keine Probleme mehr. Irgendwas hat nicht funktioniert mit chroot und dem Uefi - Bios. Jedenfalls bei mir, muss bei dir nicht genau so sein.

Ich hoffe es ist bei dir nicht so, kann aber sein das, wenn du ein anderes Systen startest, z.B. Rescuzilla, der ganze Schlamassel wieder von vorne losgeht.

[Chris]

... Und da … ↑ ↗ … nimmt einem das manjaro-chroot(-script?) schon einiges ab.

Ich weiß ehrlich gesagt immer noch nicht, worum es da geht!
Aber soweit ich das bis jetzt verstanden habe, brauchte ich diese ganze chroot Sache auch nicht, da ich aus dem laufenden System gearbeitet habe (nicht Live-System).
Ich will es aber auch noch versuchen, nachzustellen, so wie es im Manjaro-Wiki beschrieben wird (dort wird ja (überwiegend) von einem Live-System ausgegangen):
https://wiki.manjaro.org/index.php/GRUB ... tloader/de
Vielleicht kann ich dann verstehen, was z.B. dieses Skript manjaro-tools-base macht.

... Was sagt die Manpage dazu:

Code: Alles auswählen

man su

su [options] [-] [user [argument...]]
su allows commands to be run with a substitute user and group ID.

When called with no user specified, su defaults to running an interactive shell as root. When user is specified, additional arguments can be supplied, in which case they are passed to the shell.

...

Hmm ... demnach wäre su ohne weitere Angabe das gleiche wie su - root

Wenn ich das mal in der Konsole durchspiele, wohlgemerkt, aus meinem laufenden System heraus, also nicht aus einem Live-System, sieht das folgendermaßen aus:

Code: Alles auswählen

 ~  su                                                                                                                           ✔
Passwort:
[john-doe john]# exit
exit
    ~  su - root                                                                                                            ✔  17s 
Passwort:
[john-doe ~]# exit
Abgemeldet
    ~                                                                                                                        ✔  8s 

Ich hab jetzt einfach mal alles rauskopiert, inkl. dieser komischen Zeichen.
Hinter der Klammer steht in beiden Fällen die #, was dann wohl für root steht. Sollte also tatsächlich aufs Gleiche rauslaufen!
Dann lag es vielleicht doch nicht daran, dass es mit su - root plötzlich geklappt hat!

Vielleicht hing es auch mit einer Veränderung zusammen, die ich zuletzt vorher im BIOS unternommen hatte. Und zwar hatte ich dort meine Festplatte, die als erste Boot-Option eingetragen war, deaktiviert und statt dessen meinen USB-Live-Stick eingetragen! Weil ich mir dachte, das wird dann praktischer für die Zukunft sein, als jedes Mal F11 drücken zu müssen für die manuelle Boot-Auswahl.
Ich dachte mir, warum nicht zukünftig gleich in den Grub vom Live-Stick starten, weil ich ja dort dann immer über "Detect EFI Bootsectors" das System starten muss. Das war schon fast zur Routine geworden!

Andererseits, bei der Neuinstallation, die ich zwischenzeitlich testweise gemacht hatte (und anschließend ja wieder das Rescuezilla-Backup zurückgespielt habe), hatte ich die Festplatte vorher auch nicht in den Boot-Optionen deaktiviert. Da würde man ja normalerweise auch gar nicht drauf kommen, bzw. das wäre ja widersinnig, weil ja nach der Neuinstallation direkt ein Neustart erfolgt und von der Festplatte gebootet werden soll.

Wobei - wiederum andererseits - mein BIOS das mit der Bootreihenfolge auch nicht so genau nimmt! Denn, obwohl ich die Festplatte in den Start-Optionen deaktiviert hatte, war sie nach der Grub-Reparatur wieder da und an erster Stelle. Der von mir zuvor ausgewählte USB-Live-Stick war auch noch da, ist aber einfach in der Rangfolge nach hinten geschoben worden.

Also, ich fürchte auch, es könnte so sein, wie LaGGGer schreibt, dass der Spuk noch nicht vorbei ist!

Deshalb wäre es für mich auch umso wichtiger, dass ich eine möglichst klare Prozedur habe, was ich dann an Befehlen abarbeiten muss.
Gibt nicht sudo einem auch Root-Rechte?


Und noch mal am Rande:
Es hat mir ja doch keine Ruhe gelassen ... wenn ich in diesem Grub-Startfenster (erstes Foto in Beitrag 2) mit dem Navigationspfeil auf "Manjaro" gehe, also den ersten Eintrag, so dass er unterlegt ist und dann auf E drücke (für Edit Boot Options), dann sehe ich dort immer noch den selben Inhalt drin stehen mit dieser nicht nachvollziehbaren UUID (falls es eine UUID ist). Also keine Ahnung, was es damit auf sich hat, da war ich wohl auf dem Holzweg, anscheinend ist dort so oder so nicht die "richtige" UUID hinterlegt.


Ich habe jetzt noch keinen Beitrag als Lösung markiert, weil für mich erst die Kombination aus mehreren Beiträgen zur Lösung geführt hat.
Und es ist ja auch leider noch nicht wirklich klar, was jetzt letztlich überhaupt bewirkt hat, dass es plötzlich wieder geht! Und wie dauerhaft die Lösung ist.

[gosia]

Hallo Chris,

demnach wäre su ohne weitere Angabe das gleiche wie su - root

genau genommen ist su und su - root
nicht das gleiche. Mit beiden wist Du root, aber nur

Code: Alles auswählen

su

bewirkt, dass die Umgebung des Users erhalten bleibt, während mit

Code: Alles auswählen

su - root

Du dich als root einloggst, und damit sich auch die Umgebungsvariablen, die Shell und das Homeverzeichnis ändert.
Das mit dem Homeverzeichnis hast Du ja selbst gesehen und die Umgebungsvariablen kannst Du mit

Code: Alles auswählen

env

betrachten, da siehst Du den Unterschied.
Kommt eben drauf an, was Du möchtest, aber für deinen Zweck ist es relativ uninteressant. War auch nur als kleine Nebenbemerkung gedacht, zumal für die Untersuchung bzw. Reparatur von Grub chroot (oder für Manjaro manjaro-chroot) von einem Livesystem aus das Mittel der Wahl ist.

falls es eine UUID ist... anscheinend ist dort so oder so nicht die "richtige" UUID hinterlegt

Hehe, natürlich sollte dort die "richtige" UUID eingetragen sein, was denn sonst? Es sei denn, die Variable GRUB_DISABLE_LINUX_UUID ist auf true gesetzt, dann wird eine weniger zuverlässige Kennung wie z.B. /dev/sda1 benutzt.

viele Grüsse gosia

PS. Aber lass dich nicht weiter mit meinem Gerede über su verwirren, das führt nur vom eigentlichen Problem weg und mein Deutschlehrer hätte mit rotem Stift am Rande "Thema verfehlt" geschrieben.