kubuntu-22.04 startet nicht aus Startmenü von openSUSE-Leap-15.4

Hinweis: In dem Thema kubuntu-22.04 startet nicht aus Startmenü von openSUSE-Leap-15.4 gibt es 23 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Suse sollte Kubuntu erkennen - zeig mal bitte die Ausgabe von

    Code
    os-prober

    Da sollte dann etwas in der Art angezeigt werden

    Code
    localhost:~ # os-prober
    /dev/sda2:Ubuntu 20.04.5 LTS (20.04):Ubuntu:linux
    localhost:~ # 

    Das ist ein Kubuntu 20.04 und das läuft hier genau so, wie du es gerne haben möchtest - beide Systeme lassen sich über das Grubmenü von Suse starten.

    Funktioniert übrigens auch anders rum - ich kann Suse auch aus dem Grubmenü von Kubuntu heraus starten.

    Für den Inhalt des Beitrages 301072 haftet ausdrücklich der jeweilige Autor: Feli

  • Zunächst einmal danke für eure Tipps. Über das Wochenende bin ich leider nicht dazu gekommen, am Rechner zu arbeiten. Inzwischen habe ich aber darin die große Datenplatte abgeklemmt und eine nvme-ssd ausgebaut. Auf der einzig verbliebenen nvme-ssd habe ich dann erst Kubuntu in die Partition hinter EFI installiert mit einem großen swap-Bereich und dann in eine vierte Partition die SUSE. Es ist jetzt auf dem ganzen System also nur noch eine einzige EFI-Partition vorhanden, in die sich auch beide OS eingetragen haben. Im SUSE Startmenü ist auch Kubuntu eingetragen. Wenn ich aber versuche, Kubuntu von dort zu starten, endet dies wieder mit einer Fehlermeldung:

    Code
    error: ../../grub-core/commands/search.c:296:no such device:
    424f59c1-91f4-449c-b732-ae67a1cdfa69.
    error: ../../grub-core/fs/fshelp.c:258:file `/boot/vmlinuz-5.15.0-47-generic´ not
    found.
    error: ../../grub-core/loader/i386/efi/linux.c:207:you need to load the kernel first.
    
    Press any key to continue...

    Um bequem und schnell in beiden Systemen suchen zu können, habe ich dann noch unter /home neben meinem persönlichen Verzeichnis noch ein Verzeichnis 'kubuntu' angelegt, in welches ich dann die Kubuntu-Partition eingehängt habe. Die /etc/fstab sieht dann so aus:

    Code
    UUID=a9411152-742c-4c30-9e0d-61b8bbe54348  /              ext4  defaults      0  1
    UUID=A585-B80A                             /boot/efi      vfat  utf8          0  2
    UUID=fec33444-b382-485d-a1fe-1095d9dd9edc  /home/kubuntu  ext4  data=ordered  0  2

    Die fstab unter Kubuntu sieht so aus:

    Die Ausgabe von 'os-prober liefert:

    Code
    localhost:~ # os-prober
    /dev/nvme0n1p2:Ubuntu 22.04 LTS (22.04):Ubuntu:linux
    localhost:~ #

    'os-prober' liefert also genau das, was man erwartet. Warum aber wird in der Fehlermeldung beim Kubuntu-Aufruf ein Device

    Code
    424f59c1-91f4-449c-b732-ae67a1cdfa69

    genannt? Die vier Partitionen auf der Platte haben in der Reihenfolge auf der Platte die folgenden UUIDs:

    Code
    UUID=A585-B80A                            /boot/efi   vfat
    UUID=fec33444-b382-485d-a1fe-1095d9dd9edc /           ext4
    UUID=6c788d3e-3749-43f6-af16-3e41c346152a none        swap
    UUID=a9411152-742c-4c30-9e0d-61b8bbe54348 /           ext4

    Warum wird dann auf

    Code
    UUID=424f59c1-91f4-449c-b732-ae67a1cdfa69

    nach dem Kernel gesucht, worauf die Fehlermeldung schließen läßt? Auch im 'grub.cfg' steht weder bei SUSE noch bei Kubuntu etwas davon.

    Bei SUSE sieht 'grub.cfg' so aus:

    Code
    search --fs-uuid --set=root a9411152-742c-4c30-9e0d-61b8bbe54348
    set prefix=(${root})/boot/grub2
    source "${prefix}/grub.cfg"

    und bei Kubuntu so:

    Code
    search.fs_uuid fec33444-b382-485d-a1fe-1095d9dd9edc root
    set prefix=($root)'/boot/grub'
    configfile $prefix/grub.cfg

    An welcher Stelle muß man eingreifen, damit an der richtigen Stelle nach dem Kernel von Kubuntu

    '/boot/vmlinuz-5.15.0-47-generic' gesucht wird? (SUSE verwendet 5.14.21-150400.22-default (64-bit).)

    Für den Inhalt des Beitrages 301240 haftet ausdrücklich der jeweilige Autor: linuxchaot

  • Da ich seit einigen Jahren kein Dualboot mehr betreibe und

    einen neueren UEFI-Rechner (und SecureBoot) mit Windows nutze

    sowie einen älteren im Legacy-Modus (althergebrachtes MBR Schema)

    für Linux, habe ich nur die Theorie um Deinen Fehler nachvollziehen

    zu können.


    Frage:

    In der EFI-Partition sind doch die jeweiligen BS eingetragen. Dort

    wird doch die UEFI-Firmware fündig und bietet eine Auswahl der

    startbaren BS an.

    Warum wird dann bei Dir erst ein SuSE-Auswahlmenü angeboten

    von dem Ubuntu gestartet werden kann?


    Mir fehlt hier die Praxis! Das ist das Problem.


    Wenn das aber so abläuft, wie sieht dann die Auswahl unter

    Ubuntu aus? Bietet Ubuntu das Starten von SuSE-Linux an?

    Wenn ja - startet es dann?


    Ansonsten habe ich bei solchen Problemen in der Vergangenheit

    immer Yast bemüht und dort die Bootloader-Optionen beackert,

    wenn z.B. Windows nicht starten wollte.


    Ich beziehe mich auf diese Logik, nach der die Firmware das

    ausgewählte BS in der EFI-Partition findet und startet.

    (im Gegensatz dazu gehst Du über das Auswahlmenü vom

    SuSE-Bootmanager, der m.M.n. doch überflüssig ist)


    Einmal editiert, zuletzt von Hidalgo () aus folgendem Grund: Screenshot hinzugefügt

    Für den Inhalt des Beitrages 301251 haftet ausdrücklich der jeweilige Autor: Hidalgo

  • Dazu fällt mir noch ein:


    Der große Vorteil vom UEFI-Prinzip ist doch, dass alle

    installierten BS nun voneinander entkoppelt sind,

    d.h. sie starten autark / unabhängig voneinander


    Anders als bei einem MBR-Bootblock, wo ein Bootmanager

    des einen BS das andere BS startet. Gibt es Probleme mit

    dem Bootmanager von SuSE, startet beim MBR-Prinzip auch

    das jeweils andere BS nicht mehr aus diesem heraus.


    Oft kam es z.B. vor, dass nach einem Windows-Update der

    Linux-Bootmanager überschrieben wurde und erst einmal nur

    Windows startete. Eine große Krux war es auch, erst Linux und

    dann Windows zu installieren - das klappte beim alten BIOS nicht,

    weil zwar Microsoft das nicht wollte aber eben auch deshalb, weil

    der Bootvorgang von mehreren Betriebssystemen nicht entkoppelt war.


    Nun ist er also entkoppelt bei UEFI.


    Trotzdem hat linuxchaot die gleichen Probleme wie bei

    nicht entkoppelten Betriebssystemen.


    Es gibt zwei Möglichkeiten:


    1.) Entweder bin ich blöde und sehe das alles verkehrt, dann wird man mir

    im Laufe der Zeit vielleicht hier helfen können, Durchblick zu erhalten ...

    achneeee - kapern will ich hier nichts -

    im Zuge der Fehlerbeseitigung des Problems von linuxchaot sollte ich

    mich selbst erhellen können!


    2.) Da ist etwas falsch eingestellt im UEFI-Bios

    Für den Inhalt des Beitrages 301265 haftet ausdrücklich der jeweilige Autor: Hidalgo

  • Das Thema ist mir gerade zu zäh, der Informationsfluß zu langsam - nur so viel, bei mir funktioniert das mit Kubuntu und Suse ohne Probleme.

    Frage: kannst du Suse aus dem Grubmenü von Kubuntu heraus starten?

    Für den Inhalt des Beitrages 301288 haftet ausdrücklich der jeweilige Autor: Feli

  • keine Lösung, nur als Hinweis.


    Ich hatte das selbe Problem. In der Kombination Leap und Fedora.Fedora hat Leap erkannt und ein korrektes grub.cfg erstellt.

    Leap hat Fedora erkannt, aber nicht in grub eingebunden.

    Leider hatte ich dann ein Hardwareproblem und ich konnte den Fehler nicht mehr ermitteln.


    Beim zweiten Versuch habe ich Leap und ein Ubuntu installiert. Jetzt was alles gut.

    Da ich Ubuntu nicht mag, habe ich es durch Fedora ersetzt.

    Und jetzt klappt es auch bei Leap mit dem neuen Nachbar.


    Beim zweiten Versuch habe bei allen Installation extra kontrolliert, dass die EFI-Partition eingebunden wird.

    Vielleicht war da das Problem. Ich weiß es nicht.


    Perfekt läuft es bei Leap trotzdem nicht. Mehr an anderer Stelle.

    Für den Inhalt des Beitrages 301289 haftet ausdrücklich der jeweilige Autor: 37431

  • Meine Recherche ergab, wie hier auch schon in meinem

    Posting #14 angemerkt, dass z.B. der Grub-Bootmanager

    o.ä. zum Starten des jeweiligen / der jeweilig zusätzlich

    installierten Betriebssysteme beim Mehrfachbootsystem

    ausgedient hat.

    Alle Betriebssysteme, die sich ordnungsgemäß in der EFI-

    Partition eingetragen haben, lassen sich direkt über die

    UEFI-Firmware beim Systemstart auswählen. Das jeweilig

    dort zuletzt gestartete Betriebssystem startet fortan immer

    bis man das eben ändert.

    Das bedeutet aber nicht, dass man ein anderes Betriebssystem

    nicht auf herkömmliche Weise auch über einen Bootmanager

    starten könnte - sofern der denn auch fehlerfrei ein anderes

    Betriebssystem aus der UEFI-Architektur heraus zu starten in

    der Lage ist. Augenscheinlich ist das hier in diesem Thread

    beim SuSE-Grub Manager genau nicht der Fall.

    Dieses Problem hat man sich dann aber auch selbst ausgewählt,

    denn die alten Bootmanager haben eigentlich ausgedient, da

    die Betriebssysteme im UEFI-Modus voneinander entkoppelt

    sind und ohne weiteren Bootmanager aus der UEFI-Firmware

    startbar sind (wie schon beschrieben).


    UEFI-Systeme haben bereits ein eigenes Bootmenü und

    mit fehlerhaften Bootmanagern kann man sich zwar herumschlagen,

    müsste es aber nicht!


    Siehe dazu auch:https://www.pc-magazin.de/ratg…rtitionieren-2785863.html


    Abschnitt: Integriertes Bootmenü

    Für den Inhalt des Beitrages 301315 haftet ausdrücklich der jeweilige Autor: Hidalgo

  • Siehe dazu auch:https://www.pc-magazin.de/ratg…rtitionieren-2785863.html


    Abschnitt: Integriertes Bootmenü

    Naja, also zum einen geht es da nur um Windows und dann stammt der Artikel noch aus einer Zeit, als Grub im Efi-Modus noch kein Windows gefunden hat, bzw., os-prober konnte das seinerzeit noch nicht.


    Aber schon damals konnte man sich mit einem Eintrag in /etc/grub.d/40_custom behelfen und Windows aus dem Grub-Menü heraus starten.

    Für den Inhalt des Beitrages 301329 haftet ausdrücklich der jeweilige Autor: Feli

  • Naja, also zum einen geht es da nur um Windows und dann stammt der Artikel noch aus einer Zeit, als Grub im Efi-Modus noch kein Windows gefunden hat, bzw., os-prober konnte das seinerzeit noch nicht.


    Aber schon damals konnte man sich mit einem Eintrag in /etc/grub.d/40_custom behelfen und Windows aus dem Grub-Menü heraus starten.

    Das geht nicht um Windows, sondern ums Prinzip.

    Dieses Prinzip gilt für alle OS.

    Was os-prober kann und nicht kann, spielt

    dazu absolut keine Rolle, denn wenn os-prober

    ein weiteres Betriebssystem erkennt, aber grub

    nicht funktioniert, ...

    genau!

    Für den Inhalt des Beitrages 301335 haftet ausdrücklich der jeweilige Autor: Hidalgo

  • Was os-prober kann und nicht kann, spielt

    dazu absolut keine Rolle, denn wenn os-prober

    ein weiteres Betriebssystem erkennt, aber grub

    nicht funktioniert, ...

    genau!

    Es funktioniert beim TE nicht - bei mir funktioniert es flutschig und geschmeidig - mein Kubuntu 20.04 lässt sich aus dem Grubmenü heraus von Tumbleweed völlig problemlos starten. Da musste auch nichts "rumgefrickelt" werden, das funktioniert einfach.


    Aber lass gut sein, mir ist der TE zu anstrengend, ich mag nicht nach mehreren Tagen erst den ganzen Strang nochmals lesen und im nächsten Post steht dann, dass neu installiert wurde und man kann gerade wieder von vorne anfangen - letztendlich kann hier der Fehler auch an einer veralteten UEFI-Version liegen oder einem fehlerhaften Kubuntu, vielleicht liegt es auch an Leap (ich nutze Tumbleweed) → wir wissen es nicht und die Kommunikation mit dem TE ist, sagen wir mal, ausbaufähig.

    Für den Inhalt des Beitrages 301337 haftet ausdrücklich der jeweilige Autor: Feli