Testing - nach Update bricht Bootvorgang ab, Kernel 3.16

[Hans-Martin]

Hallo zusammen,

meine Frage ist schwierig, da ich aber mit einem Kernel 14.1 AMD 64 kein Problem habe, stehe ich nicht unter Zeitdruck.

Ich habe gestern ca. 25 Pakete upgedated, und stellte am Abend nach einem Neustart fest, dass der verwendete Kernel (Basis 3.14) nach dem Laden abbrach (sbin/init würde fehlen). Ich bin also noch im Bereich mit den großen Buchstaben gleich nach dem Start. Dieser Kernel wurde von mir selbst erstellt, hatte gegenüber dem Debian 14.1er nur marginale Unterschiede (Möglichkeit verschiedener Zeichensätze eingefügt) und lief monatelang problemlos.

Ich habe deshalb heute den Debian Kernel 4.16-2 installiert, stellte aber zu meiner Überraschung dasselbe Problem fest. Diese Pakete wurden gestern upgedated:

cups (1.7.5-4+b1) to 1.7.5-5
cups-client (1.7.5-4+b1) to 1.7.5-5
cups-common (1.7.5-4) to 1.7.5-5
cups-core-drivers (1.7.5-4+b1) to 1.7.5-5
cups-daemon (1.7.5-4+b1) to 1.7.5-5
cups-ppdc (1.7.5-4+b1) to 1.7.5-5
cups-server-common (1.7.5-4) to 1.7.5-5
dosfstools (3.0.26-3) to 3.0.26-4
four-in-a-row (1:3.14.0-1) to 1:3.14.1-1
gir1.2-gnomekeyring-1.0 (3.12.0-1) to 3.12.0-1+b1
gnome-keyring (3.14.0-1) to 3.14.0-1+b1
gnome-klotski (1:3.14.0-1) to 1:3.14.1-1
gnome-robots (1:3.14.0-1) to 1:3.14.1-1
gtk2-engines-pixbuf (2.24.24-1) to 2.24.25-1
icedove (31.0-3) to 31.1.2-1
libblkid1 (2.20.1-5.11) to 2.25.1-5
libcommons-compress-java (1.8.1-1) to 1.9-1
libcups2 (1.7.5-4+b1) to 1.7.5-5
libcupscgi1 (1.7.5-4+b1) to 1.7.5-5
libcupsimage2 (1.7.5-4+b1) to 1.7.5-5
libcupsmime1 (1.7.5-4+b1) to 1.7.5-5
libcupsppdc1 (1.7.5-4+b1) to 1.7.5-5
libgadu3 (1:1.12.0-3) to 1:1.12.0-5
libgail-common (2.24.24-1) to 2.24.25-1
libgail18 (2.24.24-1) to 2.24.25-1
libgexiv2-2 (0.10.2-1) to 0.10.2-2
libgnome-keyring0 (3.12.0-1) to 3.12.0-1+b1
libgnutls-deb0-28 (3.3.8-2) to 3.3.8-3
libgnutls-openssl27 (3.3.8-2) to 3.3.8-3
libgtk2.0-0 (2.24.24-1) to 2.24.25-1
libgtk2.0-bin (2.24.24-1) to 2.24.25-1
libgtk2.0-common (2.24.24-1) to 2.24.25-1
libjbig-dev (2.1-3) to 2.1-3.1
libjbig0 (2.1-3) to 2.1-3.1
libmount1 (2.20.1-5.11) to 2.25.1-5
libofa0 (0.9.3-6) to 0.9.3-7
liborcus-0.8-0 (0.7.0+dfsg-7) to 0.7.0+dfsg-9
libpam-gnome-keyring (3.14.0-1) to 3.14.0-1+b1
libpcap0.8 (1.6.2-1) to 1.6.2-2
libpulse-mainloop-glib0 (5.0-6+b1) to 5.0-13
libpulse0 (5.0-6+b1) to 5.0-13
libpulsedsp (5.0-6+b1) to 5.0-13
libsigc++-2.0-0c2a (2.2.11-4) to 2.4.0-1
libssl1.0.0 (1.0.1i-2) to 1.0.1j-1
libsub-name-perl (0.07-1+b1) to 0.12-1
libuuid1 (2.20.1-5.11) to 2.25.1-5
libyaml-tiny-perl (1.63-1) to 1.64-1
man-db (2.7.0.2-1) to 2.7.0.2-2
mount (2.20.1-5.11) to 2.25.1-5
ndiff (6.47-2) to 6.47-3
nmap (6.47-2) to 6.47-3
ntfs-3g (1:2014.2.15AR.1-5) to 1:2014.2.15AR.2-1
openssh-client (1:6.6p1-8) to 1:6.7p1-2
openssl (1.0.1i-2) to 1.0.1j-1
ppp (2.4.6-2) to 2.4.6-3
pulseaudio (5.0-6+b1) to 5.0-13
pulseaudio-module-x11 (5.0-6+b1) to 5.0-13
pulseaudio-utils (5.0-6+b1) to 5.0-13
shotwell (0.18.1-2) to 0.20.1-1
shotwell-common (0.18.1-2) to 0.20.1-1
util-linux (2.20.1-5.11) to 2.25.1-5
wpasupplicant (2.2-1) to 2.3-1

Da zuvor nirgends Probleme auftauchten, muss logisch die Ursache in einem der Pakete zu finden sein. Gibt es hier Leute, die tief genug im System stecken, um hier eine Ursache zu sehen?.

Danke im Voraus

Hans-Martin

[cronoik]

sbin/init enthält nur einen symbolischen Link zum init-System. Verwende einfach den Bootparameter init=deininitsystem* um zu prüfen ob es nur daran liegt. Danach installierst du dein Initsystem einfach nochmal neu, weil sbin/init Bestandteil des jeweiligen Paketes ist.

systemd: /lib/systemd/systemd
sysvinit: init=/lib/sysvinit/init

[smutbert]

sieht die Fehlermeldung vielleicht so aus?

Code: Alles auswählen

Loading, please wait...
Scanning for Btrfs filesystems
-f: No such file or directory
fsck: No such file or directory
fsck exited with status code 1
Usage: mount [-r] [-w] [-o options] [-t type] [-f] [-i] [-n] device directory
mount: No such file or directory
Could not copy file: No such file or directory
Target filesystem doesn't have requested /sbin/init.
No init found. Try passing init= bootarg.
(initramfs)

(das wäre dann nicht die Schuld des Kernels, es genügt busybox zu installieren und die initrd für diesen Kernel neu zu bauen)

[Hans-Martin]

Erst einmal danke.

busybox ist und war installiert.
Zu systemd gab es 4 Pakete, die als überholt angezeigt wurden. Ich habe sie gelöscht und die anderen systemd-Pakete vorsorglich neu installiert.
Ich habe das initrd.img zu Kernel 3.16-2 gelöscht, wollte es mit update-initramfs neu anlegen, erhalte dabei aber diese Fehlermeldung:

mkinitramfs: for root /boot/807 missing /boot /sys/block entry
...
mkinitramfs: Error please report the bug

Wie eingangs geschrieben, läuft mein Debian 3.14-er Kernel problemlos. Was mich interessiert ist, wieso nach dem Update der oben aufgeführten Pakete ein Kernel, der immer funktioniert hatte, auf einmal nicht mehr lief und dieselbe Meldung erfolgte wie beim danach installierten 3.16er? Das einzige Paket, das ich hier als verdächtig ansehen könnte, wäre mount.

Wenn das Problem wirklich unabhängig vom Kernel wäre, müsste ja der Debian 3.14er, der in der identischen Umgebung bootet, auch ein Problem machen. Dass er es nicht tut, scheint mir ein zwingender Beweis zu sein, dass es etwas Kernel-spezifisches ist. Allerdings war der eingangs erwähnte, von mir selbst erzeugte 3.14er Kernel nur minimal unterschiedlich, davon habe ich mich mit einem diff der Konfig-Dateien des Debian 3.14er und meines eigenen überzeugt.Dennoch gab es den Abbruch. Ich habe allerdings für die Erzeugung des Kernel einen neueren gcc verwendet als es beim Debian-Kernel der Fall war. Dann könnte hier ein Übeltäter zu suchen sein.

Ich habe hier gepostet, weil ich hoffe, dass der versammelte große Sachverstand dieses Forums den manchmal rätselhaften Innereien des Systems auf die Spur kommen kann.

[smutbert]

wenn du die initrd des Kernel 3.14 neu bauen ließest, hättest du mit dem Kernel vielleicht dasselbe Problem (automatisch wird ja immer nur die initrd des aktuell laufenden Kernels aktualiesert/neu gebaut).
Mit meiner Idee lag ich aber sowieso daneben.

Ist das "No init found. Try passing init= bootarg." die einzige Fehlermeldung beim Versuch mit dieser initrd zu starten?

[Hans-Martin]

Hallo Smutbert,

spielst Du Lotto? Wenn nein: Bei Deiner offensichtlich gewordenen seherischen Veranlagung wäre das vielleicht eine Idee.

Ich habe am 12.11. wieder einmal viele Jessie-Pakete upgedatet. Nachdem heute der Bootvorgang abbrach, sah ich mir in boot die initrd an. Ergebnis: Sie war neu gebildet worden. Nach deren Löschen habe ich mit demselben Ergebnis, derselben Meldung, wie oben ergebnislos versucht, eine neue zu estellen. Aufforderung: der Fehler sollte gemeldet werden.

Es liegt also nur an der initrd. Die letzte Meldung beim Booten ist, direkt vor der TSC-Meldung, der Hinweis, dass auf das root fs gewartet wird. Nach einer Pause wird dann das Notsystem eingeschaltet. Ich habe es aber vorgezogen, neu zu starten. Da ich es mir angewöhnt habe, mehrere Kernel zur Verfügung zu haben, bootete ich erfolgreich mit dem 3.11er, zu dem es glücklicherweise keine Verschlimmbesserung geben wird.

Was kann der Grund sein? Ich starte mit lilo, der MBR liegt im ersten Plattensektor. Die Angabe der Platte mit der UUID-Bezeichnung statt /dev/sda... in der lilo.conf (root = [Angabe des root-device] ) hat mir schon bei den Versuchen vor ein paar Wochen nichts gebracht.

Vielleicht findet Doch jemand den Grund. Im Moment trage ich mich mit dem Gedanken, Jessie, sobald es stable ist, ganz neu zu installieren. Es gab in testing eine Menge gravierende Veränderungen, z.B. mit der Einführung von systemd statt sysv. Auch hier habe ich experimentiert, sysv-core installiert und festgestellt, dass nun meine init-Einstellungen befolgt werden, und einiges mehr, was aber inhaltlich nicht in diesen Thread passt. Ich kann nicht ausschließen, dass mit der Konfiguration irgendetwas nicht mehr stimmt.

[smutbert]

Das Problem hat mich auch überrascht und die Fehlermeldung komplett in die Irre geleitet. Naja und bei diesem Thread habe ich sofort daran gedacht…
Die Ursache (von habakug entdeckt) und Lösung habe ich verlinkt.

[Hans-Martin]

Hallo smutbert,

hast Du den Link in Deiner letzten Antwort vergessen, oder steht er an anderer Stelle?

[smutbert]

☺

[…]
(das wäre dann nicht die Schuld des Kernels, es genügt busybox zu installieren und die initrd für diesen Kernel neu zu bauen)