/sbin/init not found

**pibi** · 06.12.13, 20:03

Vorgeschichte:
Ich habe quasi als "Versuchskaninchen " auf meinem Laptop die SuSI 12.2 ersetzt durch die openSuSI 13.1 (komplette Neuinstallation). Weil ich der ganzen Geschichte aus Erfahrungen der Vergangenheit nicht getraut habe, habe ich erstmal in eine separate Partition am Ende der Platte installiert. Wider Erwarten funktioniert alles wie gewuenscht. Also wollte ich die provisorische Installation in die definitiven Partitions /, /var und /usr verschieben, die ich seit Jahren so aufgeteilt habe. Die Definitionen in /etc/fstab habe ich selbstverstaendlich angepasst, so wie ich das schon gefuehlte hundert Mal gemacht habe. Als Boot-Loader benutze ich grub 0.97.

Damit faengt das Problem an, denn jetzt bootet das System nicht mehr;-( Am Anfang sieht der Bootvorgang relativ normal aus, doch schnell erscheint eine Meldung dass /sbin/init nicht gefunden wird und darauf eine "kernel panic". Dieses File ist aber definitiv vorhanden. /sbin/init ist allerdings ein symbolic link auf /usr/lib/systemd/systemd. Und so, wie es fuer mich aussieht, ist zu diesem Zeitpunkt die Partition /usr noch nicht gemountet. Dieser daddelige "systemd" treibt mich noch zur Verzweiflung:-( Aber zum Glueck ist es eine Parallel-Installation, so dass ich immer noch ein funktionierendes System booten kann.

Frage: Gibt es irgendwelche Optionen, dass zuerst alle Partitions gemountet werden, bevor der eigentliche Bootvorgang beginnt? Oder noch besser: Kann ich den systemd durch den guten alten sysvinit ersetzen, so wie es bei der 12.2 noch moeglich war?

Gruss Pit.

Rain_maker · 06.12.13, 21:43

Jaja, immer ist systemd schuld....

https://fedoraproject.org/wiki/Features/UsrMove

http://www.freedesktop.org/wiki/Soft...orTheUsrMerge/

Rain_maker · 06.12.13, 22:06

Nach längerem rumwurschteln in den (Un)tiefen meiner Linkliste:

http://lizards.opensuse.org/2011/08/...in-the-initrd/

Also seit langem default, aber eben nur, wenn /usr bei der Installation (bzw. dem Aufruf von mkinitrd während selbiger) eine eigene Partition hat.

Wenn man natürlich _nachträglich_ diese Verschiebung macht und irgendeine Ressource von /usr benötigt wird, dann geht das daneben, eigentlich ganz logisch.

Also statt auf systemdzu schimpfen hätte ich folgende Vorgehensweise vorzuschlagen.

a) Mit $LIVEDISTRO booten

b) Aus $LIVE_DISTRO in die "kaputte" Installation chrooten***

c) initrd neu bauen lassen

Greetz,

RM

*** in diesem Fall / /boot /dev /proc /sys und eben auch /usr vor dem chrooten passend einbinden

**nopes** · 06.12.13, 22:13

Nur um da gerade mal den Bogen für mich zu kriegen (als Debian user, habe ich ja noch den gewohnten sysv-init).
Das ganz kracht, weil teilweise Verzeichnissen das Basissystems in eigene Partitionen ausgelagert wurden?

This leaves us with the following well-defined directories, which compose the base of the system

EDIT: Danke, also muss nur dran denke die initrd neu zu backen, oder - und hat das überhaupt was mit dem init zu tun? habe gerade irgendwie knoten beim grübeln

Rain_maker · 06.12.13, 22:22

Das Problem ist hier nur, daß eben eine bestehende Installation _ohne_ extra /usr verschoben wurde, wobei nun eine extra Partition für /usr vorhanden ist,

Da aber nach dem "UsrMerge" /sbin/init auf /usr/lib/systemd/systemd zeigt, fällt das System beim Booten auf die Fresse, denn beim letzten Mal, als mkinitrd ausgeführt wurde, war /usr keine eigene Partition, also gibt es auch keinen passenden mount-Befehl, der früh im Bootprozess ausgeführt wird.

Hat man eine eigene Partition für /usr bei der Installation, dann finden die Skripte, die bei "mkinitrd" ausgeführt werden, auch automagisch, daß /usr eine eigene Partition ist, und fügen in die initrd einen passenden miunt.Befehl ein, damit /usr beim Ausführen von /sbin/init verfügbar ist und fertig.

Greetz,

RM

**nopes** · 06.12.13, 22:38

Und noma danke.

Also wäre es so oder so hingefallen. Da die Bürokratie sich für "einen Speicherort" entschieden hat der durch eine Verkettung ungünstiger Umstände unerreichbar ist. Und das hat nichts mit dem Init-System zu tun.

Rain_maker · 06.12.13, 22:46

Zitat von nopes

Also wäre es so oder so hingefallen. Da die Bürokratie sich für "einen Speicherort" entschieden hat der durch eine Verkettung ungünstiger Umstände unerreichbar ist. Und das hat nichts mit dem Init-System zu tun.

Ganz genau, so bald sich z.B. eine Distro mit anderem Init-System ebenfalls für einen "UsrMerge" entscheiden würde und /sbin/init "nur noch" als Symlink auf irgendwas in /usr zeigt, würde es genau so krachen.

Es muss ja nicht einmal "init" selbst sein, das würde für jede Ressource des frühen Bootprozesses gelten, die Daten von /usr benötigt und vor dem "mount /dev/irgendwas -o <optionen> /usr" ausgeführt wird. Natürlich fällt es bei "init" selbst am schnellsten auf.

Greetz,

RM

**pibi** · 07.12.13, 10:48

Zitat von Rain_maker

Wenn man natürlich _nachträglich_ diese Verschiebung macht und irgendeine Ressource von /usr benötigt wird, dann geht das daneben, eigentlich ganz logisch.

Also statt auf systemd zu schimpfen hätte ich folgende Vorgehensweise vorzuschlagen.

a) Mit $LIVEDISTRO booten
b) Aus $LIVE_DISTRO in die "kaputte" Installation chrooten***
c) initrd neu bauen lassen
*** in diesem Fall / /boot /dev /proc /sys und eben auch /usr vor dem chrooten passend einbinden

Wieder mal: BINGO! Die gleiche Idee hatte ich uebrigens in einer schlaflosen Minute letzte Nacht auch, als mir dieser Thread wieder in den Sinn kam.

Vielleicht interessiert es ja jemanden im Klartext:

Code:

[booten Rescue System von DVD, dann]
mount /dev/sda6 /mnt
mount /dev/sda7 /var
mount /dev/sda8 /usr
mount /dev/sda1 /boot
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
chroot /mnt
cd /boot
mkinitrd

Das /sys hat es nicht gebraucht. Tausend Dank fuer Deine wertvolle Hilfe und Schoenes (sturmfreies) Wochenende

Pit.

PS: systemd mag ich trotzdem nicht;-)

Rain_maker · 07.12.13, 13:13

Zitat von pibi

PS: systemd mag ich trotzdem nicht;-)

Vor 6-9 Monaten hätte ich hier noch "man gewöhnt sich dran" geantwortet, aber mittlerweile muss ich sagen, daß mir die Möglichkeiten, die systemd bietet, immer mehr gefallen.

Dabei geht es nicht nur um "1337-kr4zz0r-5up0r"-schnelles Booten, das ist gerade bei meinen Systemen der geringste Vorteil, da es nun mal auch mit systemd die meiste Zeit dauert, bis die Entschlüsselung der ganzen Partitionen fertig ist.

Es geht mir auch (noch) nicht um die neuen Fähigkeiten, die man mit systemd nutzen kann, auch wenn ich da gerade ein wenig anfange mich einzuarbeiten, denn das Feature "eine systemd-Instanz als Nutzer und damit verwaltet mnan dann seine eigenen Dienste" halte ich für eine verdammt gute Idee.

Aber auch die "altgedienten" Dinge sind in vielen Fällen deutlich einfacher geworden und oft sogar zuverlässiger.

Schau Dir mal die klassischen Initscripte an, was da teilweise veranstaltet werden muss, damit hinterher auch sichergestellt ist, daß man genau die Prozesse (PID) kennt, die man da gestartet hat.

Ein besonders drastisches Beispiel ist da Tor, welches im klassischen Initscript ein weiteres Script (torctl) aufruft, welches dann ein paar Vorarbeiten erledigt (pid-file anlegen, Rechte setzen, etc. pp.) und schliesslich tor aufruft.

Das ist dermassen grotesk, daß es schon fast weh tut, aber selbst bei nicht so drastischen Beispielen graut(e) es mir jedes mal, wenn ich ein Initsrcipt für dieses Services in eines meiner RPM-Pakete einbauen musste.

Mit systemd ist das für mich sehr viel entspannter, die Unitfiles sind übersichtlich und man hat trotzdem sehr viele, mächtige Features.

Beispiel tor:

Code:

[Unit]
Description=The Onion Router - An anonymizing overlay network for TCP
After=network.target

[Service]
Type=simple
ExecStart=/usr/bin/tor -f /etc/tor/torrc --runasdaemon 0 --defaults-torrc /etc/tor/defaults-torrc --quiet
ExecReload = /bin/kill -HUP ${MAINPID}
TimeoutSec = 30
Restart = on-failure
LimitNOFILE = 32768

[Install]
WantedBy=multi-user.target

Und als Eigenheit (die aber eher Feautre als Hindernis ist), braucht es noch eine Datei /usr/lib/tmpfiles.d/tor.conf, die das Erstellen benötigter, flüchtiger Verzeichnisse mit den richtigen Zugriffsrechten übernimmt.

Code:

d /var/run/tor 0700 tor tor -

Das war schon die ganze Magie und sytemd kümmert sich jetzt automatisch darum, daß das OS auch weiß, welche PID(s) ein Service wirklich benutzt, daß die Rechte für /var/run/tor/ ordentlich sind (Tor beschwert sich bei zu "offener" Konfiguration und weigert sich zu starten), kein Gefummel mehr mit irgendwelchen Wrappern, ps, grep und derlei Gedöns.

Natürlich gibt es gerade bei Debian&Co. Befindlichkeiten, weil z.B. Debian auch mit BSD-Kernel installierbar ist und *Buntu mit Upstart sein eigenes Initsystem entwickelt hat, aber letztendlich ändert das wenig, denn ich bin mir ziemlich sicher, daß auch Debian für ihre BSD-Variante ein angepasstes Init brauchte und *Buntu mit Upstart auch für eine Kompatibilitätsschicht zu den alten Initscripten sorgen musste, so daß das einzige, wirklich valide Argument des "ist nicht so portabel" (stimmt, systemd ist Linux-only, z.B. wg. "cgroups") auf einmal bei weitem nicht so groß erscheint, wie es wirklich ist.

Greetz,

RM