Habe meiner Siduction-vbox mal wieder ein upgrade gegönnt. Nun bootet (systemd) die nicht mehr und bleibt mit folgender Meldung hängen. Mehrfach probiert, booten ist nich mehr möglich.
A start job is running for lsb: raise network interface
Davor rotiert ein kleiner rote punkt. Die Box scheint wohl kaputt zu sein, ich komm nirgends mehr ran. Das ist wohl was ungesundes gekommen beim D-U. Jemand ne Idee was da los ist oder was das ist.
danke...
Das hier hab ich gelesen, scheint ähnlich zu sein:
http://forum.siduction.org/index.php?topic=4232.0 (http://forum.siduction.org/index.php?topic=4232.0)
Aufpassen Leute, es ist nicht nur in Virtualbox so!
Das gleiche Problem bei meiner Daddelkiste, d-u gemacht und keine bootem mehr möglich. Ich hab keine Ahnung was da los ist.
...
unter anderem soll hier (kde) upgedatet werden:
glib-networking glib-networking-common glib-networking-services network-manager
Ich nehme mal an es hängt hiermit zusammen:
http://forum.siduction.org/index.php?topic=4501.0
Nein ayla, ich habe kein Gnome sondern xfce.
Aber ich kann noch eins drauf legen, bei meinem Laptop exakt das gleiche, der bootet auch nicht mehr und hängt mit besagter Meldung. Da ist was kaputtes im D-U, jede Wette. Die glib-pakete sind bei mir auch gekommen, vielleicht sind die ja die schuldigen.
...
So, ich hab die Lösung. Es sind die systemd Pakete 204-9 die neu kommen. Gefixte 204-10 sind schon in incoming.
Also Füße still halten bis nachher zum nächsten Sync.
...
Hallo hsp,
eine kleine Blitzumfrage im Team hat ergeben, dass die beschriebenen Probleme sonst auf keinem Rechner aufgetreten sind. Vermutlich sind also nicht alle Anwender betroffen.
Hängt es eventuell an deinen NFS-Mounts? systemd reagiert empfindlich, wenn Teile der /etc/fstab nicht abgearbeitet werden können.
Laß doch mal den Bootparameter "quiet" weg, um mehr Ausgaben zu sehen.
Mit freundlichem Gruß
musca
musca du liest immer nur die Hälfte oder nicht richtig.
Was meinste woher ich die Meldung habe, ja genau weil ich noch 3x zusätzlich quiet in die command-zeile gemalt habe. Schalt dein Kopf vorher ein, das ist dir schon öfters passiert.
.....
Hi,
bei mir war es in der Tat ein NFS-mount, der den Bootvorgang aufhängt. Nach Auskommentieren in der fstab bootet das System wieder.
Gruß dsat
hsp du solltest vielleicht auch Deinen Kopf einschalten, bevor Du hier andere User beleidigst!
Obwohl Du postuliert hast, daß Du mit siduction fertig hast, bist Du aber nicht verlegen, Hilfe hier in Anspruch zu nehmen.
towo ich bin grundsätzlich um nix verlegen.
Und User anpupen, da bist immer noch du der Beste. Keiner kanns besser.
...
@hsp: gibts ein vernünftigen grund, das du hier so rumpöbeln musst???
Hallo dsat,
danke für das positive Feedback :)
Das nächste systemd ist jetzt eingetroffen (bin noch am testen),
aber im Changelog von systemd 204-10 sind keine gröberen Klötze erwähnt worden.
Gruß
musca
Die Lösung sieht so aus, nfs-mounts per fstab mit systemd gehen ab jetzt nicht mehr über netdev. Man muss es zwingend mit systemd machem
hsp1:/home/holgi/vdr /home/holgi/vdr nfs vers=3,user,noauto,x-systemd.automount,x-systemd.device-timeout=10,timeo=14,noatime,nodiratime,async,rsize=32768,wsize=32768,hard,intr 0 0
Und ja, das 'noauto' muss da rein sonst schlägt mount über netdev wieder zu.
bitte...
Hallo hsp,
danke Dir für das Feedback. Ich werde den Thread als gelöst kennzeichnen.
Eine weitere nützliche Option dürfte "nofail" sein, die das Fortsetzen des Bootvorgangs auch dann erlaubt, wenn das Mounten scheitert. Diese und die von von Dir gefundenen Optionen stehen in der (leider englischen) Manpage zu systemd.mount (http://www.freedesktop.org/software/systemd/man/systemd.mount.html).
Mit freundlichen Grüßen
musca
Hi,
meine nfs-mount zeile in der fstab sieht jetzt so aus:
192.168.xxx.xxx:/media/md0 /media/<directory> nfs noauto,x-systemd.automount,defaults 0 0
Damit läuft der Bootvorgang wieder ungestört durch.
Danke für die Tipps.
Gruß dsat
Die korrekte Option für automount in Debian wäre nichtx-systemd.automount sondern comment=systemd.automount
Grund hierfür ist util-linux 2.20. Mit 2.21, das irgendwasnn kommt, ist dann auch x-systemd.automount korrekt.
Hintergrund: https://lists.debian.org/debian-ctte/2014/06/msg00003.html
greetz
devil
Ich grabe den alten Thread mal aus, weil ich seit gestern auch diese Meldung bekomme "A start job is running for LSB: Raise network interfaces". Davor wandern rote Sternchen hin und her (Weihnachten? ;) ) und dahinter ist eine laufende Zeitangabe "(43 s/no limit)". Die 43 ist ein Beispiel, das geht hoch bis zu 1 min 30 sec ca. und dann geht es weiter... Ich habe keine nfs mounts und ähnliche Späße in der /etc/fstab, nur die ganz normalen Partitionen...
Wenn Du im Forum schaust, kann das viel sein - bei mir war es ein Graphiktreiber, bei den meisten anderen ist Netzwerk ganz groß in Mode. Mit dem nm solls gehen.
Den nm möchte ich, wenn es irgend geht, vermeiden. Es funktioniert ja alles, nur der Boot ist seit dem d-u um ca. anderthalb Minuten verzögert. Inwiefern war der Grafikkartentreiber bei dir daran Schuld?
der Treiber war nach einem Kernelwechsel klotten - und dann kam dieses wunderbare 'A start job is running for LSB ...' mit wunderschöner Weihnachtsbeleuchtung (die roten wandernden Sterne) und der geschätzten Zeit von 53 min. Ich hab mich dann dazu entschlossen, nicht zu warten und das manuell zu prüfen :) - ging irgendwie schneller.
Das mit dem Netzwerk ist irgendwie auch nicht so recht einzusehen - wtf hat LSB damit zu tun? Entweder das Ding wird wie auch immer gestartet, das hat jahrelang mehr oder weniger vernünftig funktioniert, was brauchts dazu die Linux Standard Base?? ich gebe aber auch zu, dass ich noch nicht so verzweifelt bin, dass ich das diffe.
EDIT sagt: Doch, ich bin so verzweifelt und mach das mal.
Quote from: melmarker on 2014/12/04, 23:11:16
Das mit dem Netzwerk ist irgendwie auch nicht so recht einzusehen - wtf hat LSB damit zu tun? Entweder das Ding wird wie auch immer gestartet, das hat jahrelang mehr oder weniger vernünftig funktioniert, was brauchts dazu die Linux Standard Base?? ich gebe aber auch zu, dass ich noch nicht so verzweifelt bin, dass ich das diffe.
(Excuse me for replying in English, but with German it'd take me the whole day.. :)
Systemd uses "LSB" to refer to sysvinit scripts (from /etc/init.d), i.e. those which (still) have not been migrated to Systemd.
So probably the /etc/init.d/networking script is failing to do something (dhcp, wpa_supplicant, network-manager, the whole mess), or systemd thinks it hasn't finished yet.
I use systemd with systemd-networkd and I do not have this problem.
reinob: the 'problem' ist - it seems that the problems occour with the new package iteration of systemd. So i think, one unit, patch, something is eventually wrong - the codebase (Release-Tarball) is the same as before. Thats why i think that a diff might be a good idea.
EDIT: hmm - some times just waiting and cursing seems to be a good idea - it looks like the problems are fixed with -8 8)
Thanks for the info. Good to know.
Anyway, my reply was more directed to your "wtf hat LSB damit zu tun? ". Hence my explanation that systemd considers everything "legacy" (from /etc/init.d) as "LSB".
Cheers.
(I just got -8 and it continues to work OK. Knock on wood :)
Hmm - i was wrong, the update don't solve the problem. Finally i decide to purge ifupdown, dhclient, ceni and such crap, follow reinob's hint and use systemd-networkd with a static network setting. Nice, clean and fast - and fit my needs for my workstation :D
@melmarker,
Good to know networkd works OK for you as well!
I'm using it with bonding (bond0 as active-backup for eth0 and wlan0) and it works like a charm.
Also die Meldung kommt hier immer noch, aber nur ganz kurz, gefolgt von jeder Menge anderer Meldungen (alles zu schnell zum Lesen und zuordnen zu können), aber der Bootvorgang erscheint mir nicht mehr dadurch verzögert zu sein. Ich habe aus der /etc/network/interfaces meine zweite ungenutzte Netzwerkkarte auskommentiert
#allow-hotplug eth1
#iface eth1 inet dhcp
und das hat es gebracht. Nur vorher war das ja auch kein Problem...
@melmarker: Was ist denn "and such crap"? Sachen die beim purgen von ifupdown, dhclient (heißt das so? finde ich nicht) und ceni automatisch mit entfernt werden oder noch was spezifisches?
Wird anschließend noch "ifup eth0" funktionieren? Weil ohne dem hab ich bislang kein Netzwerk nach dem Wechsel ins multiuser.target... Funktioniert anschließend noch das Zuweisen einer dynamischen IP-Adresse?
@reinob: What do I have to do exactly to use systemd-networkd? I don't have any wlan, just eth0 which gets a dynamic IP address from the router.
Quote from: spacepenguin on 2014/12/06, 14:49:19
@reinob: What do I have to do exactly to use systemd-networkd? I don't have any wlan, just eth0 which gets a dynamic IP address from the router.
Create /etc/systemd/network/eth0.network with these contents:
[Match]
Name=eth0
[Network]
DHCP=v4
Then you'd need to enable networkd: systemctl enable systemd-networkd
and be sure you disable any programs handling your network (network manager, ceni, etc.)
That should work. If not, perhaps the best would be to open a new thread!
Cheers.
(und nochmals entschuldigung, dass ich nicht auf Deutsch schreibe. Es dauert wirklich viel länger :)
spacepenguin: auf die meisten Deiner Fragen: weiss ich nicht. probiers halt aus - und wenn dabei was fürs forum, wiki oder manual abfällt - um so besser. Is nicht patzig gemeint, ich weiss es wirklich nicht. Netzwerkkonfiguration interessiert mich genau so weit, dass ich meine Ramme statisch verdrahten kann und auf dem/den Notbüchern einen wie auch immer gearteten Manager habe.
* ip - hab ich bewusst boykottiert
* systemd-network - bis gestern bewusst ignoriert
* dhcp - 2x im Jahr benutzt für jeweils 3 tage
ansonsten gehe ich immer davon aus, dass man das irgendwie anschalten kann und dass es meistens funktioniert - zu mehr interesse hats in den letzten 20 Jahren nicht gelangt.
Bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771943
solved by new package:
# LANG=C apt-cache policy ifupdown
ifupdown:
Installed: 0.7.51
Candidate: 0.7.51
Version table:
*** 0.7.51 0
500 http://ftp.de.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
0.7.50 0
500 http://ftp.de.debian.org/debian/ testing/main amd64 Packages
But now launching lightdm.service unacceptable slow. :'(
http://forum.siduction.org/index.php?topic=5238.msg42864
Update:
After D-U-ing next morning regular KDE start behavior again. :)
Greetings
Tom
show output of systemd-analyze blame
greetz
devil
Here you go:
7.202s binfmt-support.service
6.712s alsa-restore.service
6.712s console-kit-log-system-start.service
6.712s pppd-dns.service
6.710s rsyslog.service
6.684s systemd-logind.service
6.678s lm-sensors.service
6.641s udftools.service
6.641s vboxdrv.service
6.641s loadcpufreq.service
6.641s rc-local.service
6.640s kexec.service
6.640s gpm.service
6.640s systemd-user-sessions.service
6.640s ifplugd.service
2.143s mdadm-raid.service
2.138s lightdm.service
1.882s exim4.service
1.873s systemd-fsck-root.service
1.366s keyboard-setup.service
1.176s networking.service
1.122s systemd-modules-load.service
1.094s avahi-daemon.service
1.036s nfs-common.service
853ms hdparm.service
789ms colord.service
690ms sys-kernel-debug.mount
616ms hddtemp.service
590ms kbd.service
580ms systemd-tmpfiles-setup.service
577ms systemd-tmpfiles-setup-dev.service
572ms rpcbind.service
454ms dev-hugepages.mount
454ms dev-mqueue.mount
436ms udisks2.service
370ms acpi-support.service
334ms systemd-sysctl.service
288ms systemd-udev-trigger.service
252ms cpufrequtils.service
239ms kmod-static-nodes.service
166ms polkitd.service
164ms keymap.service
163ms irqbalance.service
161ms speech-dispatcher.service
153ms console-kit-daemon.service
153ms systemd-random-seed.service
146ms console-setup.service
144ms udev-finish.service
130ms user@1000.service
130ms qemu-system-x86.service
129ms dev-disk-by\x2duuid-e2e02f4d\x2d0204\x2d4242\x2d93c5\x2dc13108236ef5.swap
113ms media-DATEN.mount
113ms media-Work.mount
108ms user@113.service
108ms dns-clean.service
101ms media-lubuntu.mount
83ms upower.service
77ms proc-sys-fs-binfmt_misc.mount
68ms systemd-udevd.service
63ms resolvconf.service
53ms systemd-update-utmp.service
41ms saned.service
15ms kexec-load.service
15ms systemd-update-utmp-runlevel.service
15ms vboxballoonctrl-service.service
14ms vboxautostart-service.service
13ms vboxweb-service.service
12ms ntp.service
9ms systemd-remount-fs.service
6ms systemd-journal-flush.service
2ms sys-fs-fuse-connections.mount
Thanks for help
Tom