On Mon, 1 Dec 2014 13:35:04 +0200 Andrei POPESCU
<andreimpope...@gmail.com> wrote:
> On Lu, 01 dec 14, 14:12:01, tv.deb...@googlemail.com wrote:
> >
> > I can reinstall systemd as init and make the system fail again
(outside of
> > office hours ;-) ) if provided with direction as to how collect
additional
> > information.
>
> Please enable the debug console on VT9 (boot with 'systemd.debug-shell'
> as kernel parameter) and attach the output of
>
> journalctl -alb
>
> Kind regards,
> Andrei
I did so, when switching to VT 9 the screen is spamed with the systemd
message about "starting LSB". I typed blindly " journalctl -alb" and
noticed that a shell session was indeed active behind the spam wall !
I can see that the driver "e1000" for the network card is loaded early
without problem.
I have very few errors, I get:
"failed to find module 'lp'" and same for 'ppdev' , which in turn
generates several fail warnings later on for "systemd load kernel modules".
"Failed at step EXEC spawning /usr/lib/systemd/scripts/mdadm_env.sh"
There is no /usr/lib/systemd/scripts directory on my system (system is
mdadm raid + LUKS). "apt-file search" didn't tell me what package is
supposed to provide this "mdadm_env.sh" script, and "find" didn't show
it on my system either.
"ERROR : Duplicate address 192.168.1.2 assigned in the network where
eth1 is connected to"
The last one puzzles me as at the time I booted I was the only machine
on the network, and address is assigned from the DHCP server (openwrt)
through MAC address reservation.
grepping through /etc for string "192.168.1.2" show one occurrence in
/etc/hosts, one in /etc/samba/lmhosts, and one in backuppc configuration.
arp shows no address or MAC conflict on the network, and my router
doesn't either.
Finally I did "pgrep network" and killed the corresponding PID to get
the boot process to resume. It did successfully and the system is fully
functional, including networking, raid and all, which makes me think
some of the failure reports may be bogus ?
What makes me really skeptic of systemd behavior here is the
impossibility to kill a stalled process and resume boot without first
rebooting in systemd debug mode, or at least get a sane timeout (and
advertise it so that users can wait).
Thank you for your assistance.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
