Your message dated Sat, 11 Apr 2015 13:51:39 +0100
with message-id <[email protected]>
and subject line Re: Bug#778581: systemd install breaks chroot jail and 
compromises guest system
has caused the Debian Bug report #778581,
regarding systemd install breaks chroot jail and compromises guest system
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


-- 
778581: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778581
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: systemd
Version: 215-8
Severity: normal

Dear Maintainer,


I'm trying to configure nfsroot installation for diskless clients.
- <server$> debootstrap .... /path/to/client-root
- <server$> chroot /path/to/client-root /bin/bash
- CHR#>  apt-get install <lots of stuff w/o problems>
- CHR#>  apt-get install systemd

The last command leads to some error message (I can't remember)
Then, after googling, I run something like dpkg -a (still in the chrooted shell)
This made my server completely frozen.

After forceful reboot, It seems that I got parts of systemd installed on the 
server, too, not only on the chrooted client-root.


root@cruncher:/cluster/tftp/active/pxelinux.cfg# dpkg --list | grep systemd
ii  libpam-systemd:amd64                  215-8                                 
 amd64        system and service manager - PAM module
ii  libsystemd-login0:amd64               44-11+deb7u4                          
 amd64        systemd login utility library
ii  libsystemd0:amd64                     215-8                                 
 amd64        systemd utility library
ii  systemd                               215-8                                 
 amd64        system and service manager
ii  systemd-shim                          9-1                                   
 amd64        shim for systemd

root@cruncher:/cluster/tftp/active/pxelinux.cfg# grep systemd 
/var/log/apt/history.log

..... is EMPTY ....

So I think systemd got installed accidentially by breaking the chroot.

I also think that my mount list is weird and contains both systemd and 
sysv-init mounts:

sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs (rw,relatime,size=10240k,nr_inodes=2036655,mode=755)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=1637124k,mode=755)
/dev/sda2 on / type ext4 
(rw,relatime,errors=remount-ro,user_xattr,barrier=1,data=ordered)
tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k)
tmpfs on /run/shm type tmpfs (rw,nosuid,nodev,noexec,relatime,size=9524120k)
/dev/sda4 on /home type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
/dev/sdb2 on /ssd type ext4 (rw,relatime,user_xattr,barrier=1,data=ordered)
rpc_pipefs on /run/rpc_pipefs type rpc_pipefs (rw,relatime)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc 
(rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup type tmpfs (rw,relatime,size=12k)
configfs on /sys/kernel/config type configfs (rw,relatime)
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
systemd on /sys/fs/cgroup/systemd type cgroup 
(rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/x86_64-linux-gnu/systemd-shim-cgroup-release-agent,name=systemd)
tmpfs on /run/user/0 type tmpfs 
(rw,nosuid,nodev,relatime,size=1637124k,mode=700)
tmpfs on /run/user/1000 type tmpfs 
(rw,nosuid,nodev,relatime,size=1637124k,mode=700,uid=1000,gid=1000)


However, the system behaviour seems OK as far as I can tell.

How can I get rid of the situation?

I think such things should not happen.
May be it is difficult / impossible to install such fundamental stuff like 
systemd into a chrooted debootstrap.
Nevertheless, then I'd expect a graceful fail with some decent error message, 
and not a poke into the host system.


Wolfgang Rosner


-- Package-specific info:

-- System Information:
Debian Release: 7.7
  APT prefers stable
  APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 
'stable-updates'), (100, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl             2.2.52-2
ii  adduser         3.113+nmu3
ii  initscripts     2.88dsf-58
ii  libacl1         2.2.52-2
ii  libaudit1       1:2.4-1+b1
ii  libblkid1       2.25.2-4
ii  libc6           2.19-13
ii  libcap2         1:2.22-1.2
ii  libcap2-bin     1:2.24-6
ii  libcryptsetup4  2:1.6.6-4
ii  libgcrypt20     1.6.2-4+b1
ii  libkmod2        18-3
ii  liblzma5        5.1.1alpha+20120614-2
ii  libpam0g        1.1.3-7.1
ii  libselinux1     2.3-2
ii  libsystemd0     215-8
ii  mount           2.25.2-4
ii  sysv-rc         2.88dsf-41+deb7u1
ii  udev            215-8
ii  util-linux      2.25.2-4

Versions of packages systemd recommends:
ii  dbus            1.6.8-1+deb7u5
ii  libpam-systemd  215-8

Versions of packages systemd suggests:
pn  systemd-ui  <none>

-- no debconf information

--- End Message ---
--- Begin Message ---
Hello Wolfgang,

Wolfgang Rosner [2015-02-19 21:36 +0100]:
> > However, my chroots have a policy-rc.d which avoids the startup of
> > daemons from postinst scripts, as this conceptually doesn't work in
> > chroots and *would* mess up the host indeed. Is that the case for you?
> 
> Yes, this souds like a reasonable explanation of what had happened.
> To be honest, I've never heard of "policy-rc.d" before.
> 
> 
> > (Note that mk-sbuild etc. set up policy-rc.d automatically, but I
> > figure that's not what you did). See man invoke-rc.d.
> 
> So I didn't see any reason to look for something like man invoke-rc.d.

This explains what happened, and is a fundamental property of how
chroots work, so this isn't specific to systemd or any other package
really. As there's nothing actionable from our side here I close the
bug now.

Thanks,

Martin
-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

--- End Message ---
_______________________________________________
Pkg-systemd-maintainers mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers

Reply via email to