| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Modify TPM2 authentication policy to optionally include an authValue, i.e.
a password/PIN. We use the "PIN" terminology since it's used by other
systems such as Windows, even though the PIN is not necessarily numeric.
The pin is hashed via SHA256 to allow for arbitrary length PINs.
v2: fix tpm2_seal in sd-repart
v3: applied review feedback
|
| |
|
|\
| |
| | |
test: fixes for TEST-58-REPART
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
It seems there exists a short time period that we cannot see the
loopback device after `losetup` is finished:
```
testsuite-58.sh[367]: ++ losetup -b 1024 -P --show -f /tmp/testsuite-58-sector-1024.img
kernel: loop1: detected capacity change from 0 to 204800
testsuite-58.sh[285]: + LOOP=/dev/loop1
testsuite-58.sh[285]: + systemd-repart --pretty=yes --definitions=/tmp/testsuite-58-sector/ --seed=750b6cd5c4ae4012a15e7be3c29e6a47 --empty=require --dry-run=no /dev/loop1
testsuite-58.sh[368]: Device '/dev/loop1' has no dm-crypt/dm-verity device, no need to look for underlying block device.
testsuite-58.sh[368]: Failed to determine canonical path for '/dev/loop1': No such file or directory
testsuite-58.sh[368]: Failed to open file or determine backing device of /dev/loop1: No such file or directory
```
|
| |
| |
| |
| |
| | |
It seems that the change on the image file sometimes not propagated on
the loopback device immediately.
|
| |
| |
| |
| |
| |
| | |
The Ubuntu CI on ppc64el seems to have a issue on tmpfs, and files
may not be fsynced. See c10caebb98803b812ebc4dd6cdeaab2ca17826d7.
For safety, let's use /var/tmp to store disk images.
|
|\ \
| |/
|/| |
A couple of follow-ups for #22721
|
| |
| |
| |
| | |
Fixes: #16274
|
| |
| |
| |
| |
| | |
Pointed out in: https://github.com/systemd/systemd/pull/22721#discussion_r826014227
Follow-up for: 5a1355d848a0f6564a04c6d8268e72bc93d173de
|
| |
| |
| |
| |
| |
| |
| |
| | |
Make sure we reset the JSON format flags if the format option is used
multiple times, e.g. `journalctl -o json-format -o export`.
Pointed out in: https://github.com/systemd/systemd/pull/22721#discussion_r826018985
Follow-up for: 5a1355d848a0f6564a04c6d8268e72bc93d173de
|
|\ \
| | |
| | | |
Add AV production devices to hwdb
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Stream Deck products from Elgato are simple key pads
intended to be used as macro pads. They're popular within
the streaming community.
This commit adds all 5 Stream Deck variants available to
the AV production file.
See https://www.elgato.com/en/stream-deck
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This adds support for AV production controller devices, such
as DJ tables, music-oriented key pads, and others.
The USB vendor and product IDs come from Mixxx, Ctlra, and
Ardour.
Fixes #20533
Co-developed-by: Georges Basile Stavracas Neto <georges.stavracas@gmail.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The current description for the factory reset target does not add any
value and doesn't respect the definition of the related property as
described in systemd.unit(5).
Starting the target currently results in the following log:
[ 11.139174] systemd[1]: Reached target Target that triggers factory reset. Does nothing by default..
[ OK ] Reached target Target that…set. Does nothing by default..
Simply update the target description to "Factory Reset".
Signed-off-by: Vivien Didelot <vivien.didelot@gmail.com>
|
|\ \ \
| | | |
| | | | |
DECIMAL_STR_WIDTH() + DECIMAL_STR_MAX() tweaks
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
So far DECIMAL_STR_MAX() overestimated the types in two ways: it would
also adds space for a "-" for unsigned types.
And it would always return the same size for 64bit values regardless of
signedness, even though the longest maximum numbers for signed and
unsigned differ in length by one digit. i.e. 2^64-1 (i.e. UINT64_MAX) is
one decimal digit longer than -2^63 (INT64_MIN) - for the other integer
widths the number of digits in the "longest" decimal value is always the
same, regardless of signedness. by example: strlen("65535") ==
strlen("32768") (i.e. the relevant 16 bit limits) holds — and similar
for 8bit and 32bit integer width limits — but
strlen("18446744073709551615") > strlen("9223372036854775808") (i.e. the
relevant 64 bit limits).
Let's fix both misestimations.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Hence, check if the value is negative, not whether the type can carry
negatives.
Follow-up for: e3dd9ea8ea4510221f73071ad30ee657ca77565d
|
| | |/
| |/|
| | |
| | |
| | | |
We use // comments only for "FIXME" style comments, and explanatory
comments get /* */, as per coding style.
|
|\ \ \
| | | |
| | | | |
Journald preserve acl when rotating
|
| | | | |
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | | |
When restoring the COW flag for journals on BTRFS, the full journal contents
are copied into new files. But during these operations, the acls of the
previous files were lost and users were not able to access to their old
journal contents anymore.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
/dev/urandom is seeded with RDRAND. Calling genuine_random_bytes(...,
..., 0) will use /dev/urandom as a last resort. Hence, we gain nothing
here by having our own RDRAND wrapper, because /dev/urandom already is
based on RDRAND output, even before /dev/urandom has fully initialized.
Furthermore, RDRAND is not actually fast! And on each successive
generation of new x86 CPUs, from both AMD and Intel, it just gets
slower.
This commit simplifies things by just using /dev/urandom in cases where
we before might use RDRAND, since /dev/urandom will always have RDRAND
mixed in as part of it.
And above where I say "/dev/urandom", what I actually mean is
GRND_INSECURE, which is the same thing but won't generate warnings in
dmesg.
|
| | | |
|
| | | |
|
|/ /
| |
| |
| | |
Follow-up for: #22711
|
| |
| |
| |
| | |
Follow-up for 2f782044986a30bf73f1fe00209dbd204b3efe33.
|
|/
|
|
|
|
| |
We don't use non-blocking mode anymore, since 31234fbeec1c4a8e500106dff4779ccaa5baef83
Follow-up for: 31234fbeec1c4a8e500106dff4779ccaa5baef83
|
|\
| |
| | |
journal: convert --list-boots to a table
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
so it can be output as JSON as well.
```
$ build-san/journalctl --list-boots --file boot-test.journal
IDX BOOT ID FIRST ENTRY LAST ENTRY
-3 39d66eb1925f4d01b8464d502650a714 Sat 2022-03-05 15:20:33 CET Sat 2022-03-05 16:19:21 CET
-2 5dffeb08a27344d5ae9e2fc244bbcbc5 Fri 2022-03-11 17:23:57 CET Fri 2022-03-11 17:38:31 CET
-1 c8ebd52915b642c39eda4bf00f864f79 Fri 2022-03-11 17:38:41 CET Fri 2022-03-11 20:03:46 CET
0 00bcba97c7094fa88cc5d1cf2a389057 Sat 2022-03-12 20:39:08 CET Sat 2022-03-12 20:40:18 CET
$ build-san/journalctl --list-boots --file boot-test.journal -q
-3 39d66eb1925f4d01b8464d502650a714 Sat 2022-03-05 15:20:33 CET Sat 2022-03-05 16:19:21 CET
-2 5dffeb08a27344d5ae9e2fc244bbcbc5 Fri 2022-03-11 17:23:57 CET Fri 2022-03-11 17:38:31 CET
-1 c8ebd52915b642c39eda4bf00f864f79 Fri 2022-03-11 17:38:41 CET Fri 2022-03-11 20:03:46 CET
0 00bcba97c7094fa88cc5d1cf2a389057 Sat 2022-03-12 20:39:08 CET Sat 2022-03-12 20:40:18 CET
$ build-san/journalctl --list-boots --file boot-test.journal -o json-pretty
[
{
"index" : -3,
"boot_id" : "39d66eb1925f4d01b8464d502650a714",
"first_entry" : 1646490033438495,
"last_entry" : 1646493561047353
},
{
"index" : -2,
"boot_id" : "5dffeb08a27344d5ae9e2fc244bbcbc5",
"first_entry" : 1647015837289036,
"last_entry" : 1647016711595489
},
{
"index" : -1,
"boot_id" : "c8ebd52915b642c39eda4bf00f864f79",
"first_entry" : 1647016721056382,
"last_entry" : 1647025426397414
},
{
"index" : 0,
"boot_id" : "00bcba97c7094fa88cc5d1cf2a389057",
"first_entry" : 1647113948506002,
"last_entry" : 1647114018943637
}
]
```
Resolves: #14625
|
| |
| |
| |
| |
| |
| | |
With negative numbers we wouldn't account for the minus sign, thus
returning a string with one character too short, triggering buffer
overflows in certain situations.
|
| |
| |
| |
| | |
Fixes #22724.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
so we can feed journalctl the localized syslog-style timestamps it shows
by default, e.g.:
```
$ LANG=cs_CZ.utf-8 build-san/journalctl -b --no-hostname | head -n1
led 30 22:13:54 systemd-journald[981]: System Journal (/var/log/journal/1588e1d9d0b74acdbaada907b163b837) is 4.1G, max 4.0G, 0B free.
$ LANG=cs_CZ.utf-8 build-san/journalctl --no-hostname --since 'led 30 22:13:54' -n1
led 30 22:13:54 systemd-journald[981]: System Journal (/var/log/journal/1588e1d9d0b74acdbaada907b163b837) is 4.1G, max 4.0G, 0B free.
$ LANG=cs_CZ.utf-8 build-san/journalctl --no-hostname --since 'led 30 22:13:54.9999' -n1
led 30 22:13:58 rsyslogd[1300]: imjournal: journal files changed, reloading... [v8.2102.0-4.fc35 try https://www.rsyslog.com/e/0 ]
```
Resolves: #15899
|
|\
| |
| | |
kernel-install: clean-up machine-id handling
|
| |
| |
| |
| | |
"gold image" builders
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This makes a bunch of closely related changes:
1. The "entry-token" concept already introduced in kernel-install is now
made use of. i.e. specifically there's a new option --entry-token=
that can be used to explicitly select by which ID to identify boot
loader entries: the machine ID, or some OS ID (ID= or IMAGE_ID= from
/etc/os-release, or even some completely different string. The
selected string is then persisted to /etc/kernel/entry-token, so that
kernel-install can find it there.
2. The --make-machine-id-directory= switch is renamed to
--make-entry-directory= since after all it's not necessarily the
machine ID the dir is named after, but can be any other string as
selected by the entry token.
3. This drops all code to make automatic changes to /etc/machine-info.
Specifically, the KERNEL_INSTALL_MACHINE_ID= field is now more
generically implemented in /etc/kernel/entry-token described above,
hence no need to place it at two locations. And the
KERNEL_INSTALL_LAYOUT= field is not configurable by user switch or
similar anyway in bootctl, but only read from
/etc/kernel/install.conf, and hence copying it from one configuration
file to another appears unnecessary, the second copy is fully
redundant. Note that this just drops writing these fields, they'll
still be honoured when already set.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This drops documentation of KERNEL_INSTALL_MACHINE_ID as machine-info
field (though we'll still read it for compat).
This updates the kernel-install man page to always say "ENTRY-TOKEN"
instead of "MACHINE-ID" where appropriate, to clear the confusion up
between the two.
This also tries to fix how we denote env vars (always prefix with $ and
without = suffix), and other vars (without $ but with = suffix)
Other fixes.
|
| |
| |
| |
| | |
discovered
|
| |
| |
| |
| |
| |
| | |
If not explicitly configured, let's search a bit harder for the
ENTRY_TOKEN, and let's try the machine ID, the IMAGE_ID and ID fields of
/etc/os-release and finally "Default", all below potential $XBOOTLDR.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
used for naming the boot loader spec files/dirs
Now that we can distinguish the naming of the boot loader spec
dirs/files and the machine ID let's tweak the logic for suffixing the
kernel cmdline with systemd.boot_id=: let's only do that when we
actually need the boot ID for naming these dirs/files. If we don't,
let's not bother.
This should be beneficial for "golden" images that shall not carry any
machine IDs at all, i.e acquire their identity only once the final
userspace is actually reached.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This cleans up naming of boot loader spec boot entries a bit (i.e. the
naming of the .conf snippet files, and the directory in $BOOT where the
kernel images and initrds are placed), and isolates it from the actual machine
ID concept.
Previously there was a sinlge concept for both things, because typically
the entries are just named after the machine ID. However one could also
use a different identifier, i.e. not a 128bit ID in which cases issues
pop up everywhere. For example, the "machine-id" field in the generated
snippets would not be a machine ID anymore, and the newly added
systemd.machine_id= kernel parameter would possibly get passed invalid
data.
Hence clean this up:
$MACHINE_ID → always a valid 128bit ID.
$ENTRY_TOKEN → usually the $MACHINE_ID but can be any other string too.
This is used to name the directory to put kernels/initrds in. It's also
used for naming the *.conf snippets that implement the Boot Loader Type
1 spec.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reworks the how machine ID used by the boot loader spec snippet
generation logic. Instead of persisting it automatically to /etc/ we'll
append it via systemd.machined_id= to the kernel command line, and thus
persist it in the generated boot loader spec snippets instead. This has
nice benefits:
1. We do not collide with read-only root
2. The machine ID remains stable across factory reset, so that we can
safely recognize the path in $BOOT we drop our kernel images in
again, i.e. kernel updates will work correctly and safely across
kernel factory resets.
3. Previously regular systems had different machine IDs while in
initrd and after booting into the host system. With this change
they will now have the same.
This then drops implicit persisting of KERNEL_INSTALL_MACHINE_ID, as its
unnecessary then. The field is still honoured though, for compat
reasons.
This also drops the "Default" fallback previously used, as it actually
is without effect, the randomized ID generation already took precedence
in all cases. This means $MACHNE_ID/KERNEL_INSTALL_MACHINE_ID are now
guaranteed to look like a proper machine ID, which is useful for us,
given you need it that way to be able to pass it to the
systemd.machine_id= kernel command line option.
|
|\ \
| | |
| | | |
move to C11 (gnu11) and use u8 specifier for special characters
|
| | |
| | |
| | |
| | | |
As it does not handle assert_not_reahed() gracefully.
|
| | | |
|
| | | |
|
| | | |
|