IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If a root hash is specified, we should be checking that it matches
the root hash in the verity signature partition, so let's not skip
processing of the verity signature partitions if a root hash is
specified.
We need explicit support to generate read-only filesystems, since we
always need to pass a source tree to the mkfs binary to populate the
filesystem. As such, let's add an explicit check to return a
recognizable error when users try to generate a read-only filesystem
that we don't support.
With this, I can now easily do:
systemd-nspawn --load-credential=ssh.authorized_keys.root:/home/lennart/.ssh/authorized_keys --image=… --boot
To boot into an image with my SSH key copied in. Yay!
let's make things a bit less racy: whenever we create an inode,
immediately open it via O_PATH, compare type and continue operations
with the acquired fd.
In some cases it is useful to specify the access mode/uid/gid for inodes
we create without also enforcing them on existing inodes. Let's add a
new flag for that: if the uid/gid/mode specificaitons are prefixed with
":", then they only apply to creation, not otherwise.
This is specifically useful for provisioning SSH keys later. Those we'd
like to provision like this:
<snip>
d /root :0700 root root -
d /root/.ssh :0700 root root -
f^ /root/.ssh/authorized_keys - - - - ssh.authorized_keys
</snip>
While /root/ + /root/.ssh/ being owned by root is pretty uncontroversial
the access mode of /root/ and /root/.ssh/ might not be. Hence we should
only have a default mode defined that is used when we create the dir,
but not otherwise.
For some purposes we had CreationMode which indicates whether an inode
was created by us, or is pre-existing. Let's generalize that for *all*
operations. This is later useful to conditionalize certain operations on
that (and makes the codebase more systematic)
If multipath feature is enabled, nvme block devices may belong to the
"nvme-subsystem" subsystem, instead of "nvme" subsystem.
(What a confusing name...)
Then, the syspath is something like the following,
/sys/devices/virtual/nvme-subsystem/nvme-subsys0/nvme0n1
Hence, we need to find the 'real parent' device, such as
/sys/devices/pci0000:00/0000:00:1c.4/0000:3c:00.0/nvme/nvme0
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2031810.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2124964.
Replaces #24748.
See https://bugzilla.redhat.com/show_bug.cgi?id=2121106 for the
background on this. One of Fedora's QA folks ran an install
and chose two keyboard layouts: Czech (qwerty) and US. Due to
the sad details of how the whole logic flow for trying to decide
what kbd layout best matches a given xkb config works (see
details in the bug comments), we wound up deciding the best-
matching kbd layout for this situation was cz-us-qwertz, which
is a czech/us switched layout, but is qwertz, not qwerty. This
seems like a poor outcome. Adding this line should result in us
picking cz-qwerty in this case. Which may be the 'legacy'
cz-qwerty.map from upstream kbd project (which is switched
cz/us), or may be the auto-converted xkb layout (which obviously
isn't switched). But either way, at least its primary mode is
Czech qwerty, which seems like a *better* choice than a layout
whose primary mode is Czech qwertz.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
