Age | Commit message (Collapse) | Author |
|
https://code.launchpad.net/~curtin-dev/curtin/+git/curtin/+merge/461452
|
|
Some systems (such as centos7) do not include /usr/bin/ischroot,
which will cause the bind mount to it in ChrootableTarget to fail.
Adding a check for this ensures that the file exists before
mounting and aborts the mount if it does not.
|
|
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.
|
|
|
|
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.
Signed-off-by: Olivier Gayot <[email protected]>
|
|
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.
Signed-off-by: Olivier Gayot <[email protected]>
|
|
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.
Signed-off-by: Olivier Gayot <[email protected]>
|
|
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.
|
|
When network is required in the initramfs for NVMe over TCP, we need to
the nvme-tcp kernel module and the nvme CLI available in the initramfs.
This is now done using an initramfs-tools hook.
Signed-off-by: Olivier Gayot <[email protected]>
|
|
When configuring NVMe over TCP, we can only rely solely on nvme-stas if
none of the essential filesystems required for booting are on remote
storage. In other scenarios, use the wording "NVMe over TCP".
Signed-off-by: Olivier Gayot <[email protected]>
|
|
|
|
|
|
Previously, cryptoswap was acting strangely, in that at install time it
was considered to be a LUKS2 device and durign actual system use it
would be considered a PLAIN device, in the cryptsetup(8) meanings of
these terms.
This caused problems when attempting to reference the device, as we
would do get_volume_spec(), the returned /dev/disk/by-id/dm-uuid-...
value would be wrong - it would change from dm-uuid-CRYPT-LUKS2-... to
dm-uuid-CRYPT-PLAIN-...
As the real runtime behavior is to be a PLAIN device for cryptoswap,
stop creating it as a LUKS2 device and just use it as a PLAIN device,
which doesn't involve a "create" step at all, you just open it as PLAIN
directly.
|
|
|
|
blkid can return 3 different types of UUIDs, and they aren't
interchangable. Clarify which one we're using.
Also, leverage the existing blkid() wrapper to do so.
|
|
returning the exception is probably a typo
|
|
Should fix curtin-style-tip job.
|
|
|
|
https://code.launchpad.net/~ogayot/curtin/+git/curtin/+merge/458446
|
|
|
|
When a NVMe controller is present in the storage config, we now
configure nvme-stas so that the remote drives can be discovered and made
available using nvme-tcp at boot.
Signed-off-by: Olivier Gayot <[email protected]>
|
|
In the storage config, disks now support the optional "nvme_controller"
property.
This property holds the identifier of an existing "nvme_controller"
object (which is new).
a nvme_controller object has the following properties:
* id: a unique identifier that can be referenced in a disk.
* type: hardcoded to "nvme_controller"
* transport: usually "pcie", but we will look for the value "tcp"
* tcp_port: only if transport is set to "tcp" - will indicate the port
to connect to as an integer.
* tcp_addr: only if transport is set to "tcp" - will indicate the
IP address (could be IPv4 or IPv6) to connect to.
The presence of a "nvme_controller" object in the config will trigger
installation of nvme-cli and nvme-stas during curthooks, even if the
controller specifies transport = "pcie" or if the controller is actually
unused for the installation. For now, we will recommend not having
any "nvme_controller" objects in the config if we don't install to a
drive connected using NVMe over TCP.
Signed-off-by: Olivier Gayot <[email protected]>
|
|
|
|
Refactor TestDmCryptHandler a bit so that tests can inherit from
DmCryptCommon and use setUpStorageConfig to provide a custom storage
config.
|
|
|
|
|
|
When building debian packages for curtin, the test suite runs and fails
because of a few missing dependencies.
Add what's missing so we can have a green build.
Signed-off-by: Olivier Gayot <[email protected]>
|
|
|
|
|
|
On systems affected by the statfs kernel bug for efivarfs, we now export
the LIBEFIVAR_OPS=efivarfs variable to work around the issue. The variable
instructs libefivar (and therefore efibootmgr) to access EFI variables
through /sys/firmware/efi/efivars without leaning on statfs.
LP: #2040190
|
|
|
|
|
|
This reverts commit abebab1e1e30a16d4be891a051060e81254ff0c5.
|
|
When zkey is properly setup, we do not invoke cryptsetup luksFormat
ourselves. Instead we lean on zkey to invoke cryptsetup luksFormat for
us.
zkey seems to have no native support for invoking cryptsetup luksAddKey,
so we need to manually call it if we want to add a recovery key in a
second slot.
Signed-off-by: Olivier Gayot <[email protected]>
|
|
|
|
|
|
|
|
(cherry picked from commit 7c7c29b008128ee5476cfa82b24762c18a0d2fcc)
|
|
(cherry picked from commit 5acd262e37cd3f2ae2b6134bf568806bd2736b0e)
|
|
(cherry picked from commit 48e5bc483e15d56b456fe629c8a9544cf61d8d64)
|
|
Turn off migration to deb822 by default, and update appropriate
docs/test to reflect this. When we are actually ready for this, the
logic in want_deb822() can be restored.
|
|
In LP: #2035034, a user reported that the layout of existing
partitions was showing as 1/8th the correct size. Update storage_config
to no longer hard-code a 512 byte sector and read the value instead.
|
|
|
|
If you try hard enough and follow mount commands backwards you can
surely get this same information, but when analyzing what the extract is
actually doing it's nice to just be able to see what the image stack is.
|
|
When no suite is set for a given repository, we end up with a
deb822 styled source such as:
Type: deb
Suites:
URIs: http://archive.ubuntu.com/ubuntu
This is invalid and apt/apt-get will raise the following error:
E: Malformed entry 2 in sources file
/etc/apt/sources.list.d/ubuntu.sources (Suite)
Signed-off-by: Olivier Gayot <[email protected]>
|
|
|
|
The suggested swap size code just sort of returns 0 sometimes and
figuring out why is a complicated analysis of several variables.
Provide diagnostic info on those values, and the reason for the
decision.
|
|
The existing code tries to avoid redundant calls to 'apt update' but it
has flaws and redundant calls to 'apt update' should be fairly quick
anyway.
|
|
The current code has the side-effect of ignoring deb822 .sources files
which is a problem that could be fixed but really it's hard to see why
this code is still useful (we do not expect to deploy images with
deb-src enabled!) so just deleting it makes more sense.
|
|
I was sure curtin did this already but LP: #2033496 says not.
|