Kenne mich mit refind nicht wirkich aus, aber wenn man das bei refind auch manipulieren kann, würde ich /dev/sda3 mal durch den entsprechenden Eintrag unter /dev/disk-by-uuid ersetzen. Dass deine Wechsel ins Bios Erfolg hatten, deutet für mich darauf hin, dass /dev/sda bei dir ab und zu mal /dev/sdb wird und umgekehrt.

Das prüfe ich mal. Wird bißchen dauern wegen der Zufälligkeit, Danke.

Nein, das genügt leider nicht. Die Umstellung war ja dank rEFInd sehr einfach und seitdem hab ich ungefähr zehn erfolgreiche Boot-Vorgänge mit der UUID gemcht, aber gerade eben ist einer leider genauso nach der ersten Zeile hängengeblieben wie mit der ursprünglichen Einstellung, die ich bisher hatte.

Ich habe mir mal kurz das Wiki zu refind angeschaut, evtl. noch zwei Ideen:

Im Wikibeitrag wird für alternative Devicebezeichner statt /dev/sdXY ja in den Beispielen ja meist die Part-UUID verwendet statt - wie Stefan es vorschlug - die Dateisystem-UUID. Evtl. spielt das eine Rolle.

Du bootest nur Archlinux mit refind? Also kein Windows oder ein System auf der anderen Harddisk oder einer anderen ESP?
Vielleicht wäre dann trotzdem ein Test sinnvoll wie im Wiki hier:
https://wiki.archlinux.org/title/REFInd#Blank_rEFInd_menu_screen
beschrieben. Wobei du für "dont_scan_volumes" die Part-UUIDs der anderen Platte(Datenplatte oder was auch immer) verwenden könntest. Das also diese andere Platte bei "Scan"/Bootvorgängen möglichst ignoriert wird.

Zusatztool wie diese refind-UEFI-Shell hast du nicht installiert bzw. sind an dem Problempunkt nicht verfügbar?

In den Links bei:
https://wiki.archlinux.org/title/REFInd#See_also
gibt es da ggf. eine Möglichkeit refind "gesprächiger" zu machen? Oder sowas wie einen Timeout (statt 10+Minuten zu "warten" ob sich noch was tut), der dann ggf. eine "Fehlermeldung" zum Grund des "Aufhängers" bringt oder in eine Shell droppt...

Part-UUID - probier ich als nächstes aus.

Ja, ich hab nur genau ein Linux auf meiner Maschine. Und rEFInd bootet auch immer ein und denselben Kernel, einmal mit intel-ucode und einmal ohne, ich boote eigentlich immer mit. Das ist alles, mehr hab ich nicht konfiguriert.

Was mich wirklich wundert ist diese Zufälligkeit. Ich behaupte sogar, die ist erst mit der Zeit gekommen, die ersten Jahre, auch schon mit rEFInd, hat es super funktioniert. Dann plötzlich, nach mehreren Jahren, ging das los, ab und zu bleibt er stecken.

    T.M. Part-UUID - probier ich als nächstes aus.

    Ja, und wie oben gesagt ggf. dieses "dont_scan_volumes".

    T.M. die ersten Jahre, auch schon mit rEFInd, hat es super funktioniert.

    Gibt es für refind denn ggf. eine aktuellere Version in den Repos als deine vor Jahren installierte? refind wird AFAIK ja nicht automatisch "neu installiert"(???)...

    //Edit: Ggf. auch mal einen smart-Test der Festplatten machen.

    • T.M. hat auf diesen Beitrag geantwortet.

      weiß das journal etwas von den misslungenen bootversuchen?
      kannst du mit systemd-nspawn booten, und bleibts da auch hängen?
      hast dus mal mit einer älteren kernel/systemd version versucht?
      eigentlich brauchts refind nicht: systemd-boot

      • T.M. hat auf diesen Beitrag geantwortet.

        T.M. Was mich wirklich wundert ist diese Zufälligkeit. Ich behaupte sogar, die ist erst mit der Zeit gekommen, die ersten Jahre, auch schon mit rEFInd, hat es super funktioniert. Dann plötzlich, nach mehreren Jahren, ging das los, ab und zu bleibt er stecken.

        Für mich klingt das doch sehr nach einem Hardwaredefekt.
        Es genügt schon wenn es beim Startvorgang zu einer Unterspannung kommt, dann wird der Datenträger nicht mehr erkannt. Eventuell kann es helfen die Kabel zu wechseln oder die Kontakte ein paar mal rein und raus zu stecken. Eine Prüfung der Festplatte (SMART) ist auch nicht verkehrt. Oft kann so etwas aber auch am Mainboard (z.B. an verbrauchten Kondensatoren) liegen.
        Interessant wäre es, die Festplatte extern mit Strom zu versorgen bzw. zu testen ob das selbe Verhalten auch auftritt, wenn man den Rechner über einen externen Datenträger mit separater Stromversorgung startet.

        T.M. Ich habe den Eindruck, daß dann, wenn das passiert, ein kurzer Ausflug ins BIOS nützlich ist. Ich tausche dort dann kurz die Boot-Reihenfolge hin und wieder zurück, speichere das und anschließend bootet es allermeistens richtig. Kann natürlich auch eine Täuschung sein. Vielleicht spielt allein schon die Zeit eine Rolle, die die Maschine läuft.

        Es kann durchaus sein, dass dieser Fehler bei einem Warmstart sehr viel seltener auftritt.

        • T.M. hat auf diesen Beitrag geantwortet.

          brikler Ja, rEFInd braucht's eigentlich nicht. Es erfüllt nur den Zweck, daß man verschiedene Kernel-Zeilen leicht editieren kann, das ist z.B. gerade jetzt ziemlich nützlich. Ich habe vorher auch ohne rEFInd ganz einfache UEFI-boots durchgeführt. Aber das alle paar Jahre mal umzukonfigurieren erfordert jedesmal ein Erforschen des aktuellen Weges. Und wenn man dabei einen Fehler macht, bootet u.U. gar nix mehr, dann fängste wieder mit einer CDROM an und mußt hoffen, daß da die benötigten UEFI-Werkzeuge drauf sind.

          Im BIOS steht übrigens als zweite Boot-Option auch noch der frühere UEFI-boot drin, den ich mal konfiguriert hatte, glaub allerdings ohne ucode. Ich kann deshalb rEFInd vom BIOS aus überspringen.

          tuxnix Ich vermute leider ähnliches. Es ist auch tatsächlich so: wenn ein Bootvorgang mal geklappt hat, dann gelingen in der Regel auch alle weiteren Warmstarts. Daß es mal nicht klappt, hat praktisch immer einen Kaltstart als Voraussetzung.

          Korrodierte Kontakte wäre eine Idee. Darum könnte ich mich kümmern. Die CMOS-Batterie hab ich inzwischen auch ersetzt.

          GerBra Das Booten mit Part-UUID gelang sieben Mal, dann blieb es auch genauso stecken wie die zuvor erprobten Varianten. Zudem hatte ich auch bereits alle irrelevanten Partitionen in dont_scan_volumes mit Part-UUID aufgelistet.

          Ich mach jetzt noch einen Versuch mit einem direkten UEFI-Boot, ohne rEFInd.

          Ansonsten schraub ich das Ding tatsächlich mal auf und rüttele an allen Kontakten ...

          • GerBra hat auf diesen Beitrag geantwortet.

            T.M. gelang sieben Mal, dann blieb es auch genauso stecken wie die zuvor erprobten Varianten

            Schade (wobei es mich eigentlich gewundert hätte wenn PartUUID vs. (FS)UUID die Lösung gewesen wäre)

            Und das waren jetzt alles Kaltstarts? Warmstarts scheinen das Problem ja nicht auszulösen...

            Was macht refind (bzw. dein UEFI) denn wenn du z.B. einen wirklich fehlerhaften Booteintrag verwendest? Gibt es da Fehlermeldungen bzw. eine UEFI-Shell? Aktuell kommt ja "garnüscht" woran man festmachen könnte: Ist es ein noch BIOS/UEFI-Problem oder schon ein OS-Problem.
            Wenn du dann rund 10mal so einen fehlerhaften Eintrag booten würdest (mit Meldung), käme dann ggf. in der Situation wo der Bootteufel wieder zuschlägt diese Fehlermeldung eben nicht?

            Hast du mal geschaut, ob es in refind nicht doch eine Möglichkeit gibt in dieser Situation zu einer Shell abzubrechen? Da könntest du wenigstens Infos über gerade verfügbare Devices o.ä. bekommen (denke ich).
            Schau doch (wenn nicht schon gemacht) ob es für dein UEFI ggf. ein Hersteller-Update gäbe, daß wäre dann schon mal ein Indiz.

            Sieht für mich aber auch nach einem Hardware bzw. ggf. noch UEFI/BIOS "soft"-Problem aus, wie andere es schon früher anmerkten. Ist "eklig"...

            So, ich hab jetzt mal mit efibootmgr einen ordnungsgemäßen, aktuellen Eintrag mit intel-ucode gemacht und diesen im BIOS als ersten Eintrag gesetzt. Somit wird nun zum Test rEFInd immer übersprungen. Sah auch gut aus, aber der vierte Kaltstart ging schief.

            Und das waren jetzt alles Kaltstarts? Warmstarts scheinen das Problem ja nicht auszulösen...

            Wenn der Kaltstart schiefgeht, gelingt später wahrscheinlich auch kein Warmstart mehr, man kann dann vier, fünf machen, aber es führt zu nichts. Immerhin reagiert er noch auf Ctrl-Alt-Delete. Strom ausschalten, kaltstarten. Wenn das hingegen mal geklappt hat, geht kein weiterer Warmstart mehr schief, die gelingen dann alle.

            Was macht refind (bzw. dein UEFI) denn wenn du z.B. einen wirklich fehlerhaften Booteintrag verwendest? Gibt es da Fehlermeldungen bzw. eine UEFI-Shell?

            Es bleibt einfach so stehen. Sagt nix, geht auch nicht vorwärts. Zumindest ist das momentan bei mir so, vielleicht kann man da noch konfigurieren. Die Konfigurationsdatei hat einen ganzen Sack voll Einstellungen ... Ein originaler UEFI-Start ohne rEFInd bleibt auch einfach stehen, im allerersten Bildschirm, wo groß "lenovo" steht, es geht nicht weiter.

            Hast du mal geschaut, ob es in refind nicht doch eine Möglichkeit gibt in dieser Situation zu einer Shell abzubrechen? Da könntest du wenigstens Infos über gerade verfügbare Devices o.ä. bekommen (denke ich).

            Könnte interessant sein. Aber die Lösung wäre dann immer noch unklar.

            Schau doch (wenn nicht schon gemacht) ob es für dein UEFI ggf. ein Hersteller-Update gäbe, daß wäre dann schon mal ein Indiz.

            Das letzte Update für meinen Lenovo-Laptop ist von 2014, und das hat er drauf.

            Sieht für mich aber auch nach einem Hardware bzw. ggf. noch UEFI/BIOS "soft"-Problem aus, wie andere es schon früher anmerkten. Ist "eklig"...

            Es läuft auf Aufmachen hinaus. Mal sehen, momentan ist Zeit knapp, das nächste Wochenende ist auch schon wieder verbucht ...

            (Es stünde auch einem Neukauf eigentlich nichts im Wege, die Kiste ist mindestens zweimal abgeschrieben. In Großfirmen geben sie Laptops offiziell drei Jahre, dieser hier ist mindestens acht ... (aber halt noch immer wie neu!!!) ...)

            16 Tage später

            Ich hab jetzt seit etwa einer Woche tatsächlich mal systemd-boot (ex gummiboot) im Einsatz. Das ist in dreierlei Hinsicht interessant:

            1. man muß nichts zusätzlich installieren, es ist schon drauf
            2. es hat im Prinzip (von der Optik mal abgesehen) denselben Funktionsumfang wie rEFInd
            3. ... was soll ich sagen? Bis jetzt hat es nicht einen einzigen Aussetzer gemacht, funktioniert tadellos.

            Habe nun darin dieselben Einträge konfiguriert wie in rEFInd und dieses anschließend uninstalliert. Danach mit efibootmgr die UEFI-Tabelle von alten (rEFInd- u.a. experimentellen) Einträgen bereinigt.

            Ich traue der Sache noch nicht ganz. Immerhin hat der Bootvorgang vorher auch dann ab und zu mal ausgesetzt, wenn ich gleich vom BIOS aus direkt einen kernel gebootet hatte, also rEFInd daran gar nicht beteiligt war. Aber bis jetzt funktioniert's. (Vermutlich geht's ab morgen los, nachdem ich das hier heute geschrieben habe ...)

            • Dirk hat auf diesen Beitrag geantwortet.

              T.M. Ich traue der Sache noch nicht ganz.

              systemd-boot habe ich schon einige Jahre im Einsatz. Auf insgesamt 3 verschiedenen Geräten, und das völlig problemlos was den Bootvorgang selbst angeht.

              Wo wir gerade bei Trivia sind: Wir Booten ca. 1700 unserer Arch basierten Digital Signage Systeme mit Systemd Boot. Bisher keine Aussetzter - nunja zumindest nicht wegen Systemd Boot.

              11 Tage später

              Argh ... es ist, wie ich vorhergesagt habe: der Bootvorgang bleibt bei mir auch mit systemd-boot irgendwann stecken, allerdings seltener als vorher, ich sach mal einer von 20 Bootvorgängen. Der Bildschirm zeigt dann zunächst das Bootmenü von systemd-boot, wenn dann der eigentliche Bootvorgang losgeht, wird er schwarz und bleibt so, es ist nichts weiter mehr zu sehen.

              Es wird eine Hardwaregeschichte sein, es läuft also auf eine neue Maschine hinaus.

              • brikler hat auf diesen Beitrag geantwortet.

                T.M. hast du mal einen älteren kernel versucht?
                ich hab ein ähnliches problem an meinen zweit notebook: es lässt sich mit dem aktuellen kernel überhaupt nicht booten, mit dem lts kernel funktionierts aber.

                24 Tage später

                Ich habe herausgefunden, daß die BIOS-Option, mit der Boot-Vorgänge von USB-Sticks ermöglicht werden, einen offensichtlich positiven Einfluß hat. Die war bei mir bis jetzt aus. Wenn die jedoch eingeschaltet ist, braucht das BIOS offenbar ein paar zig Millisekunden länger, bevor es auf die Platte geht und dort etwas Bootfähiges sucht. Das scheint in den meisten Fällen auszureichen, damit anschließend der eigentlich beabsichtigte Boot-Vorgang von der Platte erfolgreich ist. Als Benutzer bemerkt man davon nichts.

                Es gäbe da auch noch die Möglichkeit nach einem bootfähigen Medium auf dem DVD Laufwerk suchen zu lassen. Das dauert dann noch ein wenig länger. 😉