ubuntuusers.de

Lidux schrieb: Allerdings produzieren die Skripte /etc/grub.d/43_custom_proxy und /etc/grub.d/44_custom Müll in dieser Datei, der mir aber wohl nicht ursächlich für Dein Problem erscheint. Diese beiden Skripte gehören aber jedenfalls nicht zum Standard.

An Deiner Stelle würde ich nun folgendes tun:

• grub-customizer deinstallieren.

• Grub deinstallieren, sowohl im Betriebssystem als auch auf der Platte.

• Alles aus dem Ordner /etc/grub.d/ löschen.

• Grub neu installieren, sowohl im Betriebssystem als auch auf der Platte.

Danke. Ich traue mich nicht, grub-customizer zu deinstallieren, weil ich Angst habe, das gerade die Deinstallation das System unrettbar beschädigt. ☹ Grub-customizer hat anscheinend die Grub-Scripte verändert und weitere hinzu gefügt. Ich werde grub-customizer da lassen und nicht mehr nutzen.

Ich habe bisher Grub vollständig neu installiert nach der Anleitung für UEFI https://wiki.ubuntuusers.de/GRUB_2/Reparatur/

Leider erneuert das nicht die Scripte in /etc/grub.d/ sondern diese werden auch wieder vom grub-mkconfig heran gezogen, weshalb Sie in meinen *.cfg immer noch Einträge fanden, die so nicht Standard sind ☹.

Das Löschen von /etc/grub.d sollte dies abstellen, aber wenn das nach hinten los geht und dann gar nicht mehr startet... Es hat sicher seinen Grund, das @schwarzheit komplettes "platt machen" von ubuntu statt "Grub platt machen" und neu installieren vorschlägt?

Zum kompletten Killen des gesamten linux ist mein Leidensdruck aber noch lange nicht hoch genug, (zumal der Erfolg nicht garantiert ist), solange es "nur" alle paar Tage 2 PC-Starts braucht, bis es läuft...

os2_vertriebener schrieb:

Es hat sicher seinen Grund, das @schwarzheit komplettes "platt machen" von ubuntu statt "Grub platt machen" und neu installieren vorschlägt?

Ja hat es. Spätestens beim >> Upgrade << fällt es dir mit Sicherheit auf die Füsse und dann denkt keiner mehr dran das da der Customizer dran war.

Hatten wir hier im Forum schon oft genug das die Upgrades wegen dem Ding nicht gingen und dann neu installiert werden musste.

(zumal der Erfolg nicht garantiert ist)

Doch ist er. Da du ja nach dem neu aufsetzen KEINEN Customizer mehr installieren wirst. Und damit dann das System ja nicht wieder zerrammelt wird.

Zum kompletten Killen des gesamten linux ist mein Leidensdruck aber noch lange nicht hoch genug, (...) solange es "nur" alle paar Tage 2 PC-Starts braucht, bis es läuft...

Wenn der Leidensdruck noch nicht hoch genug ist kannste hier ja nun auch mit dem mimimi aufhören und das Thema beenden.

Beim erneuten Boot nach dem Reset-Knopf-Neustart bootet er IMMER!)

Erinnert mich irgendwie an ein Thema mit ungenügenden Entropie-Daten (war das damals bei 18.04?).

sudo apt-get install haveged

Kostet nichts und ist einen Versuch wert. Ansonsten würde ich eher auf ein Hardwareproblem (Bauteile-Alterung?) im Zusammenspiel mit dem Kernel tippen. Für solcherart Zeugs eine Lösung finden zu wollen ist oft aussichtslos.

Nachtrag:

Vielleicht mal ein paar Tage grundsätzlich per ESC im Grub anhalten und eine oder zwei Minuten warten, bevor man per ENTER weiter starten lässt. Bootet es so zuverlässig(er), ist es ein "Betriebstemperatur-Problem". 😉

dingsbums schrieb:

Beim erneuten Boot nach dem Reset-Knopf-Neustart bootet er IMMER!)

sudo apt-get install haveged

Ansonsten würde ich eher auf ein Hardwareproblem (Bauteile-Alterung?) im Zusammenspiel mit dem Kernel tippen. Für solcherart Zeugs eine Lösung finden zu wollen ist oft aussichtslos.

Vielleicht mal ein paar Tage grundsätzlich per ESC im Grub anhalten und eine oder zwei Minuten warten, bevor man per ENTER weiter starten lässt. Bootet es so zuverlässig(er), ist es ein "Betriebstemperatur-Problem". 😉

Danke für die Anregungen. haveged habe ich installiert. Die Boot-Unterbrechung ist eine gute Idee.

Wenn es die Hardware ist, bin ich ziemlich "angeschmiert", weil es sich um einen kompletten PC in Notebook-Technik auf einer Steckkarte handelt (Intel NUC 9 extreme), der sündhaft teuer war und an dem man faktisch außer dem RAM nichts ersetzen kann.

os2_vertriebener schrieb:

Ich traue mich nicht, grub-customizer zu deinstallieren,

Das allein bringt keine Änderung. Diese Murks-Software hat bereits ihr Werk getan, als Du sie ausgeführt hast.

schwarzheit schrieb:

Spätestens beim >> Upgrade << fällt es dir mit Sicherheit auf die Füsse

Jetzt mach ihm noch davor Angst, damit er ewig auf dem alten Schrappel fährt! Ja, er soll sauber neu installieren. Huh, Angst!

von.wert schrieb:

Jetzt mach ihm noch davor Angst, damit er ewig auf dem alten Schrappel fährt! Ja, er soll sauber neu installieren. Huh, Angst!

ES GIBT KEINEN AUSWEG!

/etc/grub.d/ wird nur EINMAL bei der Installation von ubuntu "befüllt".

(Irgendwie ist das ein System-Nadelöhr - mir fällt nichts Anderes ein, was man nicht reparieren könnte ohne alles neu zu machen...)

Muss man Änderungen in den Grub-Scripten los werden und hat kein Backup der Dateien, dann gibt es nur noch Neuinstallation. ALLE anderen Wege, auch die beschriebene Lösung https://wiki.ubuntuusers.de/GRUB_2/Reparatur/ durch Reparatur aus dem laufenden System heraus oder Boot von einer Live-CD und Reparatur von dort funktionieren NICHT!

Alle "Reparaturen"; egal von wo ausgeführt greifen auf /etc/grub.d/ zu. Sind die Daten dort geändert, werden die Änderungen in die "Reparatur" wieder mit eingepflegt, also direkt wieder kaputt repariert.

Löscht man /etc/grub.d/ vorher scheitern alle Rettungsversuche daran, das die Reinstallation von grub funktionierende Scripte in /etc/grub.d/ erwartet. Sind die nicht da bricht die Grub-Installation mit einer Fehlermeldung ab! (Dabei wird lediglich eine LEERE grub.cfg erzeugt).

So, ubuntu ist neu installiert. Jetzt ist die nächsten Tage erst einmal wieder einrichten angesagt... (Auch wenn /home noch da ist, bin ich von einem rundum laufenden System noch weit entfernt...).

Spätestens mit dem Versuch, grub zu reparieren und die vom grub-customizer geänderten Scripte los zu werden, wurde das System nicht mehr bootfähig → Neuinstallation.

os2_vertriebener schrieb:

So, ubuntu ist neu installiert.

...und auch wieder nur das angegraute Noble statt Questing (danach wäre es nur ein Schritt statt ein Sprung gewesen) oder gleich Resolute.

Jetzt ist die nächsten Tage erst einmal wieder einrichten angesagt.

Was immer Du da fabrizierst.

Im übrigen...an Grub festhalten, pff. Sowas hab' ich hier auf dem Host nicht, sondern...bootet pfeilschnell in Nutzbarkeit.

von.wert

sondern...

Tss, systemd-boot, selbst das ist schon zu viel, jedes UEFI startet .efi's.

von.wert schrieb:

Im übrigen...an Grub festhalten, pff. Sowas hab' ich hier auf dem Host nicht, sondern...bootet pfeilschnell in Nutzbarkeit.

Danke.

Ubuntu installiert bei der Installation GRUB, darum habe ich über Alternativen gar nicht nachgedacht. Im Vergleich zum Windows 11-Boot ist linux mit Grub-Boot aber immer noch pfeilschnell. ☺ (Und bei GRUB wurde der Dual-Boot für Windows auch automatisch mit eingerichtet...)

Bei Ihrem Bootloader wird extra gewarnt: "...Dies sorgt für einen schnelleren Bootvorgang, auf mancher Hardware treten dabei allerdings Probleme auf."

Ich fürchte, das meine Intel NUC9-Einplatinen-Steckkarte zur exotischen Hardware gehört? (Ein testweise installiertes Linux-Mint stürzt z.B. regelmäßig innerhalb von max. 20 Minuten komplett ab - unter ubuntu kenne ich solche Probleme nicht.)

os2_vertriebener schrieb:

Ubuntu installiert bei der Installation GRUB

Schon klar, aber Du hast den ja bei Deinen Versuchen irgendwann gelöscht gehabt. Na, solange hier keiner mit LILO kommt... 😉

Dual-Boot für Windows

Wärx!

Bei Ihrem Bootloader wird extra gewarnt: "...Dies sorgt für einen schnelleren Bootvorgang, auf mancher Hardware treten dabei allerdings Probleme auf."

"Man geht schon ein Risiko ein, wenn man morgens aufsteht, über die Straße geht und sein Gesicht in einen Ventilator steckt."
(Lt. Frank Drebin von der Spezialeinheit)

von.wert schrieb: Na, solange hier keiner mit LILO kommt... 😉

Geh mich weg mit dem modernen Krams - LOADLIN - das einzig Wahre... ☺ {GRÖHL}