Bug#778581: systemd install breaks chroot jail and compromises guest system

[Wolfgang Rosner]

Hello, Michael Biebl

Am Dienstag, 17. Februar 2015 10:39:45 schrieben Sie:
> > So I think systemd got installed accidentially by breaking the chroot.
>
> What you describe sounds highly unlikely. Merely installing systemd in a
> chroot will not "break the chroot".
>
> To me it looks like you accidentally installed systemd on the host
> system yourself, or it was already installed.

Of course, this is the first explanation that came to my mind, too.

However, I had reconfigured the bash prompt of the chroot to take care of this 
risk.


Am Dienstag, 17. Februar 2015 18:42:11 schrieben Sie:
> Since the given information is not sufficient to diagnose your issue, it
> would be great if you can provide step-by-step instructions how to
> reproduce the problem and a more detail log of the events that happened.

hm ... I understand your desire, but this not so easy from a system that 
crashed.

Il try to collect some of my copy/pastes from a database where I'm collecting 
my notes and merge it with my memory:

---------------8<-------------------------------------------------------------------------

dracut module 'systemd' will not be installed, because 
command '/lib/systemd/systemd' could not be found!


CHR#root at blade-001:~# apt-get install systemd
W: Not using locking for read only lock file /var/lib/dpkg/lock
E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to 
correct the problem.

root at cruncher:/cluster/node_roots/wheezy-dbstr-2015_02_10/mp-aufs-admin# 
chroot /cluster/node_roots/wheezy-dbstr-2015_02_10/mp-aufs-admin  
dpkg --configure -a    

-----------------8<---------------------------------------------------------------------

This
	CHR#root at blade-001:~#

is the chrooted prompt

This
root at cruncher:/cluster/node_roots/wheezy-dbstr-2015_02_10/mp-aufs-admin#

is the host system prompt

So, as it looks, you are half way right:
I did call the "dpkg configure -a"  command from the host, however, chrooting 
it.

But shouldn't this be the same???
And even if I called "dpkg --configure -a" from the host - it is not supposed 
to screw the machine, is it?
Or may be, that something else was in the dpkg configuration pipeline, that 
screwed the box - completely unrelated to the chrooted systemd?

Hm, well, this could be....

I'll include the dpkg.log
Does this tell anything to you?


> reproduce the problem
setting up systems just to screw them?
Well, if this is the only option, I'd prefer to keep the issue for the 
archives.
If this never and nowhere happened before and after - fine for everybody.


Wolfgang Rosner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dpkg.log
Type: text/x-log
Size: 110522 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20150217/2a5e8724/attachment-0001.bin>