apt: ensure systemd knows it runs in a chroot, when executing postinst
Since we added the --mount-proc option to unshare, the postinst script
for openssh-server (and most likely other packages) started failing with
the following error when `systemctl daemon-reload` was invoked:
> Failed to connect to bus: No data available
Before the option was added, it would simply do nothing because systemd
rightly understood it was running in a chroot.
To determine if we are running in a chroot, systemd checks if
/proc/1/root (corresponding to the init process) and / are the same
inode. If they are different, systemd assumes we are in a chroot.
However, we are running apt-get in a new PID namespace which means that
in the new namespace, apt-get gets assigned PID 1 and is therefore the
"init" process.
Now that /proc is properly mounted in the chroot, when systemd compares
/proc/1/root and /, it sees they are identical because the init process
(which is apt-get) is actually running inside the chroot.
Without the --mount-proc option, /proc/1 in the chroot would still refer
to the systemd init process (running outside the chroot), so it would
work properly.
With the SYSTEMD_OFFLINE variable, one can "force" systemd to assume
it is running in a chroot. Let's use it when running commands in a
chroot, and the variable is not already defined.
apt-config: enable deb822 sources from 24.04 onwards
This reverts commit a7640fdcac396f9f09044dc7ca7553043ce4231c and applies
further modifications to enable deb822 sources starting from 24.04 and
not 23.10.
Bind ischroot->true in ChrootableTarget and --mount-proc in unshare
Some programs that are installed by default in Ubuntu rely on checking
/proc/$pid to determine if certain processes are still alive. Curtin's
current default behavior for "curtin in-target" is to run children
inside a separate PID namespace without also isolating /proc,
meaning checks for /proc/$pid usually wait on the wrong process
entirely. One such example is in any DKMS package, as DKMS checks
/proc/$pid. (I have submitted a similar patch to them to address
this as well: https://github.com/dell/dkms/pull/403).
Adding --mount-proc to unshare --pid args resolves that issue since
/proc is already mounted in util.py. However, it introduces a new
issue with postinstall scripts that rely on ischroot to determine
whether to restart systemd, since ischroot behavior is undefined
in pid namespaces. Bind-mounting /usr/bin/ischroot to /usr/bin/true
resolves this issue and is always correct since the symlink is
added only within ChrootableTargets.
curthooks: nvmeotcp: check if network in initramfs is needed
To decide if we should bring up the network in the initramfs and then
run `nvme connect-all` commands, we now look for mounpoints that have
the `_netdev` option. Those are the ones that require the network to be
up before mounting. If any of those mounpoints corresponds to something
essential for booting (e.g., /, /usr, /var or alike), then we decide
that the network is required in the initramfs.
curthooks: nvmeotcp: bring up the network in the initramfs
If the network is required in the initramfs for NVMe over TCP, we now
extract the netplan configuration, generate a set of `ip` commands (plus
dhcpcd if needed) and execute those in the initramfs. This is a bit of a
hack because the netplan configuration supplied by subiquity is provided
using write_files directives. Also, only trivial network configurations
are supported at the moment.
curthooks: nvmeotcp: run nvme connect-all commands in the initramfs
If the network is required in the initramfs for NVMe over TCP, we now
execute a set of `nvme connect-all` commands as required by the NVMe
over TCP configuration.
Add support for the 'luks_keystore' style encrypted ZFS install. Native
ZFS encryption is supported by a small dm_crypt dataset containing the
real key. This is a functional transcription of the way that Ubiquity
has implemented encrypted guided ZFS.
