Bootproblem mit Eigenbaukern (gelöst)

[fischig]

Gibt es eine Möglichkeit, festzustellen, an welcher Stelle der Bootvorgang mit Eigenbaukern (bookworm) scheitert (möglichst ohne systemd). Die letzte Bootmeldung ist, soweit ich informiert bin, nicht aussagekräftig.

[TRex]

Mir fällts schwer, dir zu helfen, wenn du quasi keine Informationen über deinen Kernel und dessen Bootversuch rausgibst... du erwartest wohl, dass diese Informationen, soweit dir bekannt, nichts mit dem Problem zu tun haben und die Antworten in die falsche Richtung führen würden.

Was weiß ich vom Boot-Vorgang?

1. grub/... ruft die kernel-binary auf
2. sofern existent, lädt der kernel die initrd und damit dann die Kernelmodule
3. Übergabe ans eigentliche rootfs, der init-Prozess wird aufgerufen

Wenn ich also über debugging nachdenken müsste, würde ich vermutlich bei der initrd ansetzen... mit init=/bin/bash komm ich um die Frage rum, ob mein Kernel "fertig" ist.

[JTH]

Eine andere generische Möglichkeit wär, das übliche „quiet“ aus der Kernel-Cmdline zu entfernen (über den verwendeten Bootloader). Als weitere Steigerung kann man dort stattdessen noch „debug“ eintragen. Falls du überhaupt nicht soweit kommst, müsstest du das verraten (obwohl es dann nicht direkt ein Kernelproblem ist.)

[fischig]

du erwartest wohl, dass diese Informationen, soweit dir bekannt, nichts mit dem Problem zu tun haben und die Antworten in die falsche Richtung führen würden.

Genau so. Also fang ich mal mit den (bekannten) roten Tüchern an: kein udev, kein systemd. Keine initrd. kernel-sourcen 6.1 von kernel.org. bootloader ist lilo. bookworm soll ohne GUI auf einem alten eeepc 1000h laufen. ( Eigenbaukernel 4.19.297 von kernel.org tut unter den genannten Voraussetzungen ). Wenn's der Wahrheitsfindung dient, würde ich zumindest testweise udev installieren und eine inird bauen. Letzteres habe ich wissentlich noch nie gemacht.

[KP97]

Bis wohin kommt denn das System? Das hast Du nicht gesagt.
Starte lilo doch mal ohne Xserver und ohne quiet, evtl. siehst Du dann schon mehr. udev allein kannst Du nicht installieren, da es mittlerweile Teil von systemd ist.
Es kommen also alle Abhängigkeiten mit, die Du nicht haben willst.

Bei den Systemvorausetzungen wird kaum jemand helfen können/wollen ... vermute ich mal.

[TRex]

Bei den Systemvorausetzungen wird kaum jemand helfen können/wollen ... vermute ich mal.

Bei offenen Karten - wieso nicht?

Also: init=/bin/bash - tut das, und wenn nein, bis wohin tut es?

Edit: man könnte noch anmerken, dass das kein debian-Problem ist, weil nichts von dem Problem mit dem debian-System (lies: Umfeld) zu tun hat oder auch nur in Berührung kommt - ist ja vermutlich auch ein devuan. Dennoch haben doch wohl ein paar hier den Anspruch zu verstehen, wie beispielsweise der Bootprozess oder der Kernel (zumindest von außen) funktioniert. Eine initrd löst vermutlich einige Probleme, aber wenn ich in Richtung embedded/IoT schaue, gibt es sowas auch nicht. Es ist also machbar, und das notwendige Verständnis dafür (was sicher nicht die Welt ist) aufzubauen, sollte wohl drin sein, ohne dass gleich jemand nach Smalltalk/"nicht debian" schreit.

[KP97]

So war das auch nicht gemeint, ganz sicher sind hier einige Leute mit guten Systemkenntnissen.
Nein, ich meinte eher die Konstellation des Ganzen, es unterscheidet sich doch sehr von einem Standard. Wenn es Devuan wäre, hätte er das sicher gesagt.
Aber das wird er sicher noch mitteilen.

[Livingston]

Hilfreich wäre zum Vergleich die Kernel-config eines funktionierenden Systems mit gleichem Kernel oder wenigstens einer Version, die nicht allzu weit von dem anderen entfernt ist. Dann könnte man ein diff über beide Versionen laufen lassen.

Devuan ist übrigens nicht soo weit von Debian entfernt. Darüberhinaus haben wir sogar Wiki-Artikel, um ein systemd-freies Debian zu installieren. Ich finde fischigs Konstellation auch nicht wirklich schräg, man sieht sowas lediglich selten bei Desktop-Systemen.

Debian ohne systemd
Debootstrap <- Unterpunkt 2.1

[Tintom]

Gibt es eine Möglichkeit, festzustellen, an welcher Stelle der Bootvorgang mit Eigenbaukern (bookworm) scheitert (möglichst ohne systemd). Die letzte Bootmeldung ist, soweit ich informiert bin, nicht aussagekräftig.

Ohne zu wissen, ob's die Ursache ist, aber der Klassiker sind fehlende Module bzw. nicht fest einkompilierte Module. Wenn du das Ding eh baust, könntest du auch den anderen Weg gehen: Mit make allyesconfig einen fetten, monolithischen Kern bauen, der alle Module beinhaltet. Von der Config ausgehend wählst du dann alle nicht benötigten Bestandteile ab oder machst sie modular. Anschließend neu bauen und sehen, was sich verändert hat

[fischig]

So, ich will dann mal meine weiteren (, hoffentlich abschließenden) Versuche mitteilen:
Ob zur Beantwortung meiner Frage: „Gibt es eine Möglichkeit, festzustellen, an welcher Stelle der Bootvorgang mit Eigenbaukern (bookworm) scheitert“ es tatsächlich wichtig war,ob es sich um ein Devu- oder Debian-System handelt, hatte ich nicht auf dem Schirm. Also: zunächst habe ich das Devuan-System (daedalus) via Klonen zum backup gemacht, den Klon dann via sources.list und dist-upgrade auf bookworm gebracht. (apt war ziemlich knifflig.) Ein paar Devuan-Pakete blieben erhalten, aber apt meinte dazu, dass das die aktuellen Debian-Pakete seien. ob das jetzt ein authentisches Bookworm oder aber ein Franken-Debian ist, kann ich nicht beurteilen. Die von Knopper (oder war's Kofler?) in einem im DF vor kurzem verlinkten Video (Thread finde ich nicht mehr) gezeigten Klimmzüge, systemd auf einem Debiansystem nachträglich rückgängig zu machen, wollte ich mir nicht antun. Dazu fehlen mir vermutlich auch die Kenntnisse.
Auf dieses System habe ich dann schlicht meinen Kernel 6.1 von kernel.org mit der config eines auf einem bookworm-System (TP-X31)laufenden 6.1.-Eigenbau-Kernels, das meines Wissens nach noch nie mit Devuan in Berührung gekommen war (seit wheezy immer nur upgegraded), gebaut. Bootet einwandfrei. Anschließend habe ich die für KraKa und NICs zuständigen (auf dem eeepc 1000h unpassenden) Kernel-Bestandteile beseitigt bzw. korrigiert. System läuft bisher.


Den bisherigen Antworten entnehme ich, dass sich meine eigentliche Frage wohl nur mit „nein“ beantworten lässt.

Also: init=/bin/bash - tut das, und wenn nein, bis wohin tut es?

Das habe ich leider nicht verstanden und bis wohin es tut, weiß ich ja nicht, oder ist die letzte, im Bootvorgang erscheinende Meldung doch relevant? Die könnte ich nachliefern.

Andererseits: offenbar war ich bisher der irrigen Meinung, man müsse, sofern die Sourcen für einen neuen Kernel kein Punkt-Release seien (höhere Nummer nach dem 2.Punkt) zuerst aus der alten config via make oldconfig eine neue config für den neuen Kern erstellen. Mit den dabei auftauchenden Fragen war und bin ich angesichts der Menge der Bestandteile eigentlich überfordert. Jetzt habe ich, nachdem schon alles wie o.a. funktioniert, mal spaßeshalber die config des 4.19er Eigenbaukerns unverändert den Sourcen für 6.1 vorgeworfen. Kernel wird klaglos gebaut und funktioniert ebenfalls!

Ziele/Überlegungen
Ich möchte einen Kernel bauen, der zumindest annähernd nur das enthält, was auf der jeweiligen Maschine tatsächlich benötigt wird. In diesem Zusammenhang ist mir unklar, was allyesconfig (TinTom) eigentlich macht: Wenn damit alle in den Quellen möglichen Bestandteile fest einkompiliert werden, dann ist das so ungefähr das Gegenteil dessen, was mir vorschwebt. Ich will's ja möglichst maßgeschneidert für die jeweilige Maschine. Ob nun modular oder monolithisch ist für mich sekundär/vorgabenabhängig (manche Bestandteile können ja gar nicht als Module kompiliert werden.)