Beiträge von avwasser

    Ja, sind ne Menge Festplatten drangeklemmt:

    - sda beherbergt das Windows-System

    - auf sdb sitzt suse Tumbleweed

    - sdc Mabox (eine System- und eine Home-Partition, dazu noch zwei Partitionen, die inzwischen obsolet sind)

    - sdd eine Back-up Platte für Fotos

    - sde eine Platte auf der regelmäßig suse/mabox-Backups landen


    Wie gesagt: Tumbleweed ist das "Master-System". Über Jahre konnte ich (aus dem Grub2 Menü von Suse) auswählen, ob ich Tumbleweed, Mabox oder Windows starten will. Neulich gab es in Mabox allerlei zu updaten. Danach habe ich neu gestartet und hatte den Salat. Seitdem erscheint obigen Meldung in dieser Emergency-Shell.


    Feli: "Gemacht" habe ich nuscht; ich bin froh wenn das Rechner-Zeug läuft; was "schief gelaufen" ist, keine Ahnung.


    Was ich mir nicht erklären kann (in der ewig langen Ausgabe von gestern) ist der Ubuntu-Eintrag. Vielleicht habe ich (vor Mabox) mal ein Ubuntu-Derivat ausprobiert? Kann es sein, dass sich so ein Eintrag dann einfach "in alle Ewigkeit" durchschleppt?


    Na, wie auch immer, vielen Dank bis hier her fürs Mitangucken. Ich überlege inzwischen, ob ich das Maböxchen nicht einfach neu installiere...


    Vorher aber noch die gewünschte Ausgabe:

    Code
    linux-ctqv:/home/ceos # lsblk /dev/sdc
    NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
    sdc      8:32   0 465,8G  0 disk 
    ├─sdc1   8:33   0  58,6G  0 part 
    ├─sdc2   8:34   0 232,9G  0 part 
    ├─sdc3   8:35   0 135,2G  0 part 
    └─sdc4   8:36   0  39,1G  0 part 

    Das Mabox-System liegt auf sdc4.

    Hier kommt die Ausgabe:


    Sorry, schon wieder so ein Haufen Zeugs...

    Nein, das funktioniert nicht. Ich kann im BIOS die Mabox-SSD zwar sehen, wenn ich sie allerdings zum Booten auswähle, erscheint ein schwarzer Schirm mit einem blinkenden Cursor; weiter passiert dann nix.


    Ich bin im Augenblick nicht zuhause, deshalb muss die erwünschte Ausgabe später folgen.

    Die Angaben zu "Parttype" sind bei sda und sdb so "formatsprengend". Ich habe die Abfrage mal rausgelassen und die Schriftgröße verkleinert. Besser so?


    Hallo Sauerland, vielen Dank schon mal fürs Kümmern... Hier kommt der Output:


    Grüße

    Carsten

    OS: Tumbleweed 64 BIt (plus Windows 10, plus Mabox Linux; jeweils auf separaten SSDs)

    PC: Ryzen 5 1600, 16 GB RAM, Mainboard ASRock Fatal1ty B450 Gaming-ITX/ac

    Grafik: AMD RX 5500 XT


    Guten Tag,

    ich nutze seit "Jahr und Tag" o. g. Triple-Boot-System. Mabox Linux (ein Arch/Manjaro-Derivat) eigentlich mehr aus Spaß. Seit kurzem lässt sich Mabox nicht mehr starten. Wähle ich die Installation aus dem Boot-Menü (das Tumbleweed zur Verfügung stellt), lande ich in einer Emergency Shell, in der ich leider keine Ahnung habe, was zu tun wäre. Die Information dort lautet:


    Code
    Can't find UUID=bd5e7ebc-7f64-4745-ba00-6329b39159fd..."

    Das Mabox System sitzt auf dieser Partition. Die betreffende SSD ist per USB angeschlossen und beherbergt 4 Partitionen, alle ext4. Lt. Gparted trägt sdc4 (dort logiert die Mabox-Installation) die UUID bd5e7ebc-7f64-4745-ba00-6329b39159fd, also exakt die, die angeblich nicht gefunden werden kann. Auch in /boot/grub2/grub.cfg lautet die Mabox-Systempartition auf genau diese UUID. Das Gleiche gilt für den fstab Eintrag auf Seiten der Mabox-Installation.


    Wenn ich im Grub-Menü die Mabox-Installation auswähle, "e" drücke und in dem dann präsentierten Eintrag die UUID durch /dev/sdc4" ersetzte, startet Mabox (ein Tipp aus dem Mabox-Forum). Nach einem Neustart habe ich dann wieder dasselbe Problem – es sei denn ich editiere jedesmal den Mabox-Eintrag im Grub-Menü.


    Ich weiß leider nicht, ob das Problem eines des Grub-Menüs in Tumbleweed ist, auf der Mabox-Seite liegt... oder womöglich auch ein Hardware-Problem sein kann.


    Vielleicht hat ja einer der Fachleute hier einen Tip?

    Grüße
    Carsten

    'Tschuldigung, ich hatte dann unversehens mit Corona zu tun...

    Hettrumer: Du logierst im Linuxhaus irgendwie 5 Stockwerke über mir. Heißt: Ich kann dir leider nicht wirklich folgen. Ich habe REfind auf einen, nach deiner Empfehlung formatierten USB-Stick geschrieben. Ich sehe den Stick auch als "UEFI" Bootmedium im Bootmenü des Rechners. Aber REfind bootet nicht. Das Display wird kurz schwarz, als sollte der Bootvorgang starten, dann geht's aber zurück zum Bootmenü.

    Ich hatte auch einen "Test" mit der Qtile-Edition von Garuda gemacht (basiert auch auf Arch Linux) – dasselbe Problem. os-prober findet die Systempartition, sie taucht auch im Grubmenü von suse auf, startet bei Auswahl aber mit dem gleichen Fehler.

    Ich pflege jetzt erstmal meine Coronaschlappheit. Danke bis hierher fürs Supporten!

    Grüße Carsten

    Hallo Hettrumer,

    danke für deine Antwort – ich bin mir allerdings nicht ganz sicher, ob ich dich richtig verstehe: Kann REfind das Problem lösen oder umgeht es das Problem nur? Es ist ja nicht so, dass ich EndeavourOS nicht starten könnte. Ich brauche im Bootmenü des Rechners nur die Festplatte auswählen, auf der das System installiert ist. Blöd ist halt, dass die Auswahl über das Grub-Menü nicht funktioniert und auf einen Fehler hinausläuft, den ich nicht verstehe.

    In der fstab ist die Platte übrigens gar nicht verzeichnet, weil sie nicht standardmäßig gemountet sein muss. Sie lässt sich aber in Dolphin problemlos einhängen und gparted zeigt für die Systempartition der Platte die gleiche UUID wie sie in der grub.cfg hinterlegt ist.

    REfind werde ich trotzdem ausprobieren. Mal sehen, ob mich das Tool weiterbringt :)

    Grüße Carsten

    OS: Tumbleweed 64 BIt (plus Windows 10, plus Mabox Linux; jeweils auf separaten SSDs)

    PC: Ryzen 5 1600, 16 GB RAM, Mainboard ASRock Fatal1ty B450 Gaming-ITX/ac

    Grafik: AMD RX 5500 XT


    Hallo,

    ich komme mit folgendem Problem nicht weiter: Ich habe mir, um ein wenig mit dem Tiling Window Manager Qtile zu spielen, EndeavourOS installiert. Nach der Installation hat

    Code
    os-prober

    die Installation gefunden und ich habe die grub.cfg via

    Code
    grub2-mkconfig -o /boot/grub2/grub.cfg

    neu schreiben lassen. Im Bootmenü taucht jetzt auch ein entsprechender Eintrag auf – nur startet das System nicht, wenn ich es auswähle. Die Fehlermeldungen lauten folgendermaßen:


    Code
    ../../grub-core/fs/btrfs.c:2076: Datei "/boot/vmlinuz-linux" nicht gefunden
    
    ../../grub-core/loader/i386/efi/linux.c: Sie müssen zuerst den Kernel laden


    Ich bekomme das System gestartet, wenn ich während des Bootvorgangs die Boot-Optionen aufrufe und die entsprechende SSD auswähle.


    In einem anderen Thread habe ich gelesen, dass vielleicht die UUIDs "durcheinandergekommen sein könnten", das scheint aber nicht so zu sein. Hier ist die Ausgabe von lsblk -f (in Bezug auf das Laufwerk, auf dem EndeavourOS installiert ist:

    Und hier die Ausgabe von cat /boot/grub2/grub.cfg | grep "vmlinuz-linux"

    Code
    linuxefi /boot/vmlinuz-linux root=UUID=800ecc97-2a5c-4979-9034-9f5e57691961 rw rootflags=subvol=@ loglevel=3 nowatchdog nvme_load=YES
            menuentry 'EndeavourOS, on linux (on /dev/sdc3)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-linux--800ecc97-2a5c-4979-9034-9f5e57691961' {
                    linuxefi /boot/vmlinuz-linux root=UUID=800ecc97-2a5c-4979-9034-9f5e57691961 rw rootflags=subvol=@ loglevel=3 nowatchdog nvme_load=YES
            menuentry 'EndeavourOS, on linux (fallback initramfs) (on /dev/sdc3)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-linux--800ecc97-2a5c-4979-9034-9f5e57691961' {
                    linuxefi /boot/vmlinuz-linux root=UUID=800ecc97-2a5c-4979-9034-9f5e57691961 rw rootflags=subvol=@ loglevel=3 nowatchdog nvme_load=YES

    Und weiter kommt der Laie nicht :) Kann jemand helfen?

    Grüße

    Carsten