Neuinstallation leap 15.5: init Prozess scheitert beim Booten - Kernel Panik

Hinweis: In dem Thema Neuinstallation leap 15.5: init Prozess scheitert beim Booten - Kernel Panik gibt es 28 Antworten auf 3 Seiten. Der letzte Beitrag () befindet sich auf der letzten Seite.
  • Luigi: Ja, es gibt noch eine HD auf dem Rechner. Ich nehme an Du schlägst vor, auf dieser die Neuinstallation zu machen.

    Nein, das wollte ich nicht vorschlagen.


    Zeige bitte die Partitionierung von dieser Platte. Es könnte sein, dass das Problem daher kommt.


    Auf welcher Platte ist grub installiert?

    Einmal editiert, zuletzt von luigi ()

    Für den Inhalt des Beitrages 313309 haftet ausdrücklich der jeweilige Autor: luigi

  • Wenn das Bootmedium eine UEFI-Umgebung erkennt, sollte es laut

    Boot parameters | openSUSE Leap 15.5
    openSUSE Leap allows setting several parameters during boot, for example choosing the source of the installation data or setting the network configuration.
    doc.opensuse.org


    in GRUB die Möglichkeit geben, unter More-> eine Recovery-Umgebung zu starten. Klappt das?



    Ansonsten: Startet z.B. eine aktuelle Tumbleweed-Live-CD mit XFCE auf den Desktop?

    openSUSE Tumbleweed
    Learn about the openSUSE distributions and download them for free
    get.opensuse.org

    https://download.opensuse.org/tumbleweed/iso/openSUSE-Tumbleweed-XFCE-Live-x86_64-Current.iso


    was liefert

    Code
    btrfs scrub start /

    2 Mal editiert, zuletzt von Spaceloop ()

    Für den Inhalt des Beitrages 313310 haftet ausdrücklich der jeweilige Autor: Spaceloop

  • Luigi: Die HD ist /dev/sda und hat nur eine Partition sda1. Eine reine Datenplatte, Grub ist nicht darauf installiert


    Spaceloop: Von der InstallationsCD kann ich ein rescue system starten

    Die Tumlbleweed liveCD startet normal

    btrfs scrub start / liefert


    scrub started on /mnt, fsid 7921... (pid=2984)

    (root system auf /dev/sdb2 von Hand gemountet auf /mnt)

    Für den Inhalt des Beitrages 313315 haftet ausdrücklich der jeweilige Autor: hajix

  • Falls du es noch nicht probiert hast, so würde ich die Partitionen sdb1 und sdb2 komplett entfernen (z.B. mit gparted o.ä.). Danach den Installer von Leap 15.5 den freien Platz ohne Eingreifen ausfüllen lassen. Die weiteren Partitionen würde ich erst nach einem erfolgreichen Neuboot einhängen. Auch eine Installation mit ext4-Filesystem anstatt btrfs würde ich alternativ einmal ausprobieren, um so der Ursache des Problems vielleicht näher zu kommen.


    Was führte zu dem von dir erwähnten 'zerschießen' der früheren Installation? Vielleicht Eingriffe ins Bios, Firmwareupdate o,ä.?

    Einmal editiert, zuletzt von luigi ()

    Für den Inhalt des Beitrages 313331 haftet ausdrücklich der jeweilige Autor: luigi

  • Luigi: So was ähnliches habe getan und bin jetzt einen Schritt weiter. Allerdings nicht, was das Verständnis angeht. Ich habe die root und EFI Partition gelöscht und in anderen Grenzen neu mit fdisk erzeugt , dann neu installiert und nur die beiden Partitionen mounten lassen und tatsächlich hat der Rechner gebootet. Dann habe ich nochmals neu installiert und dabei auch die anderen Partitionen mounten lassen und zack.... war wieder zurück auf Start - Kernel panic. Nach weiteren Installationsläufen ist reproduzierbar klar, dass es an einer Partition liegt (dev/sdb8) die auf /usr/local gemountet wird. Lasse ich die Partition

    über das Installationsprogram nicht mounten (in fstab eintragen) bootet der Rechner. Auch dann wenn ich anschließend

    die Partition händisch in die fstab eintrage. Wenn ich umgekehrt den Eintrag den das Installationsprogramm vorgenommen hat (was wie gesagt dazu führt dass der Rechner nicht mehr bootet), händisch aus der fstab raus nehme

    bootet der Rechner trotzdem nicht (was wohl eher nicht verwundert). Im Moment bleibt mir wohl nur, entweder versuchsweise die gesamte Platte komplett neu zu partitionieren, was wegen der Datenrettung ein beachtlicher Aufwand wäre, oder vorerst mit der momentanen Lösung zu leben und die /usr/local erst nach der Installation von Hand einzubinden. Außer jemand hat noch eine zündende Idee....


    Auf jeden Fall herzlichen Dank schon mal an alle Ratgeber..

    Für den Inhalt des Beitrages 313332 haftet ausdrücklich der jeweilige Autor: hajix

  • Oh ja, die Partition ist randvoll. Dort installiere ich alle 3rd-party software die nichts mit Suse-OS zu tun hat.

    Für den Inhalt des Beitrages 313334 haftet ausdrücklich der jeweilige Autor: hajix

  • Also ich würde jetzt in den sauren Apfel beissen und das System neu aufsetzen... Denn auch wenn man jetzt noch eine Lösung finden würde, wäre mir die Gefahr zu groß, dass irgendeine Inkonsistenz später wieder für Probleme sorgt.

    Für den Inhalt des Beitrages 313350 haftet ausdrücklich der jeweilige Autor: Spaceloop

  • Also ich würde jetzt in den sauren Apfel beissen und das System neu aufsetzen...

    Ich denke nicht, dass dies zielführend ist, solange das grundlegende Problem nicht beseitigt wird.


    In einfachen Worten: Beim boot-Prozess werden im frühen Stadium nur einige wenige Dateien bzw. Verzeichnisse geladen, da der Speicherplatz noch sehr beschränkt ist. Zu den geladenen Strukturen gehört anscheinend auch /usr/local, welches aber in der Regel leer ist oder nur wenige Dateien enthält. Bei hajix dagegen wird eine gut gefüllte Partition unter /usr/local gemountet, so dass der initiale Speicher vermutlich überläuft und dann z.B. libsystemd-shared-249.so nicht mehr gefunden werden kann.


    Daher würde ich diese Partition nicht unter /usr/local, sondern an einer anderen Stelle mounten, die beim init-Prozess nicht geladen wird, oder nur wenige Dateien nach /usr/local kopieren, falls diese beim booten benötigt werden sollten.


    Sofern es aus irgendeinem Grunde notwendig ist, dass die gesamte Partition unter /usr/local erscheint, so würde ich diese erst später, nach dem erfolgreichen Systemstart, über ein script einhängen.

    Für den Inhalt des Beitrages 313357 haftet ausdrücklich der jeweilige Autor: luigi