Bug#754218: boot hangs forever on LSB job "raise network interfaces"

[tv.debian at googlemail.com]

On Mon, 1 Dec 2014 13:35:04 +0200 Andrei POPESCU 
<andreimpopescu at gmail.com> wrote:
 > On Lu, 01 dec 14, 14:12:01, tv.debian at 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.