[Gelöst] Systemd in einer VM

[trion]

Guten Abend,

seit mehreren Stunden versuche ich jetzt ein Debian testing mit systemd in VirtualBox zum laufen zu bekommen.
Folgendes triviales Howto war meine Anleitung: http://wiki.debian.org/systemd

Dazu
1) Setzte ich eine VM mit Squeeze auf
2) Passe sources.list enstprechend an
3) Mache ein dist-upgrade
4) Boote den neuen Kernel
5) Installiere systemd (kein systemd-sysv o.Ä., wirklich nur systemd)
6) Reboote mit init=/bin/systemd

Der Bootvorgang scheint hängen zu bleiben, nach einem Neustart zeigt dmesg, dass systemd auf udev wartet:

Code: Alles auswählen

....
[    4.226826] systemd[1]: udev.service: main process exited, code=exited, status=203
[    4.327789] systemd[1]: udev.service holdoff time over, scheduling restart.
[    4.327806] systemd[1]: Job pending for unit, delaying automatic restart.
...

(Dieser Abschnitt wiederholt sich)

Hier das komplette Log: 36080

Habe das nun 2 mal from scratch getestet und keine Änderungen außer den angegebenen vorgenommen.
Riecht für mich nach einem Bug, aber vielleicht habe ich etwas übersehen.

Danke
trion


Nachtrag: Das selbe Problem tritt auch bei einem frisch installierten wheezy aus den weekly-builds auf.
Das dist-upgrade ist also nicht die Fehlerquelle.
Nachtrag 2: Der Boot in Runlevel 1 funktioniert, allerdings mit der selben Ausgabe von dmesg.
Nachtrag 3: Ein selbst gebauter systemd verhält sich exakt wie der aus den Quellen.

[rendegast]

Du mußt wohl auch sysvinit durch die Installation von systemd-sysv rausschmeissen.
("Yes, I am aware this is a very bad idea")
Sonst bekomme ich sogar einen Absturz beim Booten.

Dann werden die Dienste gestartet, ich bekomme aber keine login-Shell ("Starting getty on tty1 aborted ...")
Wohl was vergessen?
Oder lag es am vorherigen Austausch von getty->ngetty?:

Code: Alles auswählen

ng:2345:respawn:/sbin/ngetty tty1 tty2 tty3 tty4
5:2345:respawn:/sbin/getty tty5 --noclear
6:2345:respawn:/sbin/getty tty6 --noclear

EDIT Hat nichts damit zu tun,
(artemis:) Es liegt am nicht startenden udev aufgrund dessen fehlerhafter "Startdatei" udev.service, s.u.

[trion]

Du mußt wohl auch sysvinit durch die Installation von systemd-sysv rausschmeissen.

Ändert nichts.

Oder lag es am vorherigen Austausch von getty->ngetty?

Ich habe da nichts bewusst ausgetauscht.
Gut möglich, dass ich dich falsch verstehe, was genau meinst du damit?

[artemis]

Hallo...

UDev hat zur Zeit einen Bug. Dadurch startet das System nicht. Das sieht mir bei dir ganz danach aus.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=649175
Die Lösung ist einfach:
- Starte den System mit init=/bin/bash
- Mach ein remount rw des Root Filesystems (mount -o remount,rw / )
- Bearbeite die Datei /lib/systemd/system/udev.service: ExecStart=/sbin/udevd
- Neustarten.

(So in etwa musste ich das machen. Das ist ein Fehler, den ich nicht so ganz nachvollziehen kann, auch nicht bei SID. Vor allem ist der anscheinend immer noch nicht gelöst. Was ja eigentlich einfach wäre... )

Bis dann,
artemis

[rendegast]

Danke artemis!!

Auf sowas wäre ich nicht gekommen:
Habe wegen der fehlenden Logins xdm / twm installiert, um mich dort einzuloggen.
Kam auch bis zum xdm, aber mit Tastatur- und Maus-Freeze.
Im Xorg...log steht dann ganz locker:

... Kernel command line ..... init=/bin/systemd
... (II) config/udev: Adding input device ... (/dev/input/...)
... (**) Option "config_info" "udev:/sys/devices/...... "
... (II) config/udev: Adding input device ... (/dev/input/...)
... (**) Option "config_info" "udev:/sys/devices/...... "
... (II) config/udev: Adding input device ... (/dev/input/...)
usw.

Wie soll mensch denn da auf udev schließen?
Daß im syslog die Einträge "udev(d)[]: starting version ..." einfach fehlten, fiel mir gar nicht auf.

[trion]

Danke atremis, funktioniert einwandfrei!

Systemd hat auf jeden Fall meine Bootzeit schon mal von 14 auf 9 Sekunden gebracht.
Mal sehen wie er sich in der Praxis so schlägt.

[artemis]

Danke atremis, funktioniert einwandfrei!

Systemd hat auf jeden Fall meine Bootzeit schon mal von 14 auf 9 Sekunden gebracht.
Mal sehen wie er sich in der Praxis so schlägt.

Kein Problem. Wie gesagt, bin selber bei den Fehler hängen geblieben... Ich finde es nur schade, dass der nicht gefixt wird. Ist ja schon ein paar Tage alt und schon wichtig. Auch die Antworten im Bug Report sind schon komisch...

Systemd läuft hier auf meinem Laptop schon seit dem Einzug in SID ohne große Probleme. Tja, bei SID muss man ja immer mit was rechnen. Obs besser ist als die anderen Init Systemen kann ich nicht beurteilen. Genauer untersucht hab ich das noch nicht...

Bis dann,
artemis