[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#668001: debootstrap: cant install systemd instead of sysvinit



Hello,

I think this bug has a lot of dev and ops misunderstanding.  It's not 
surprising dev folks think the postinstall hack is good enough, but from 
an ops perspective it very much is not.  Rather than trying to argue 
that point, let's just move ahead with solving the core problem 
(debootstrap not honoring excludes).

I can confirm from moderately extensive testing the patch provided in 
this bug resolves the problem of excludes not working and I have not 
seen any undesired behavior resulting from this.  Could we get this 
uploaded at least to experimental, if not to unstable now that the 
jessie release has been cut?  Are the developers merely too busy and 
would they welcome an NMU for this?

Also, for the other ops folks out there, I have seen quite a bit of 
back-and-forth discussion about what you can and can't do without 
patching debootstrap.  Here's a quick run-down of the current status 
(i.e. what we're stuck with for jessie):

* You cannot avoid systemd getting installed when using the debootstrap 
shipped with jessie.  Full stop.  This impacts both the bare metal 
installer and debootstrap used for things like LXC containers.  You can 
use debootstrap to install a package which conflicts with systemd in the 
second phase, but this will merely remove systemd, not purge it.  It 
also will not uninstall systemd's dependencies.

* You can provide your own patched version of debootstrap for LXC 
container hosts but unless you are willing to maintain your own version 
of the installer images as well, you cannot do anything about the bare 
metal installs.  (Remember, the installer gets rebuilt from time to time 
to accommodate kernel upgrades and you may be forced to do the same to 
keep your preseeds working...)

* If you are using patched debootstrap, installing sysvinit instead of 
systemd looks like this:

  * bare metal:

Preseed with something like the following:

# Individual base packages to exclude
d-i base-installer/excludes string systemd systemd-sysv
# Additional base packages to include
d-i base-installer/includes string sysvinit-core

  * LXC container:

Adjust the container template so it looks something like this:

PACKAGES_EXCLUDE="systemd,systemd-sysv"
PACKAGES_INCLUDE="...,sysvinit-core"

echo "Downloading debian minimal ..."
debootstrap --verbose --variant=minbase --arch="${ARCH}" \
        --exclude "${PACKAGES_EXCLUDE}" --include "${PACKAGES_INCLUDE}" \
        ${RELEASE} "${CACHE}/partial-${RELEASE}-${ARCH}" "http://${BITBUCKET}/debian";

(Ours is pretty heavily customized; sorry the variable names are all 
different than they are in the script provided by Debian...)

* If you aren't using patched debootstrap, you probably want something 
like the following in your post-install (f.e. in a script executed as an 
installer late command in-target):

# We are running non-interactive
export DEBIAN_FRONTEND=noninteractive
export DEBIAN_PRIORITY=critical

# Clean up if the installer used a defective debootstrap which installed systemd
dpkg -l | egrep -q '^.[^n]. (systemd|systemd-sysv) ' && {
        echo -e "Defective installer debootstrap; systemd was installed at some point...\n"

        # In the worst case, systemd may be the only thing installed
        apt-get -mqy install sysvinit-core

        # The installer may have left config files around
        dpkg -P systemd systemd-sysv

        # Remove non-Important systemd dependencies unless depended by another package
        for PKG in acl dbus libcap2-bin libcryptsetup4 libpam-systemd lvm2 systemd-shim systemd-ui; do
                dpkg -P ${PKG} || true
        done

        # Remove files which systemd messily leaves around the filesystem
        rm -vrf /etc/dbus-1 /etc/pam.d/systemd-user /etc/systemd/*.conf

        echo
}

(Of course, one of the reasons ops folks don't like having to do this is 
Debian might change the systemd deps and then we have to go change the 
post-install script to accommodate...)

Thanks,
-Jacob

-- 

An original IBM 4.77MHz PC reports 0.7 bogomips running Linux 8086, but
can still run a webserver!

 -Alan Cox, lkml post, 21 Mar 2003


Reply to: