use /etc/clonetab to provide devices to be cloned#1
Open
src-up wants to merge 79 commits into
Open
Conversation
src-up
pushed a commit
that referenced
this pull request
Jan 21, 2026
Otherwise, if the VM is unexpectedly rebooted, then `importctl --user pull-tar` may fail as the file may already exist. ``` [ 123.351751] TEST-13-NSPAWN.sh[3946]: + run0 -u testuser importctl --user pull-tar file:///var/tmp/image-tar/kurps.tar.gz nurps --verify=checksum -m [ 123.541603] TEST-13-NSPAWN.sh[4311]: Enqueued transfer job 3. Press C-c to continue download in background. [ 123.552456] TEST-13-NSPAWN.sh[4311]: Pulling 'file:///var/tmp/image-tar/kurps.tar.gz', saving as 'nurps'. [ 123.552788] TEST-13-NSPAWN.sh[4311]: Operating on image directory '/home/testuser/.local/state/machines'. [ 123.819942] TEST-13-NSPAWN.sh[4311]: Got 1% of file:///var/tmp/image-tar/kurps.tar.gz. [ 124.156557] TEST-13-NSPAWN.sh[4311]: * shutting down connection #0 [ 124.156896] TEST-13-NSPAWN.sh[4311]: * Could not open file /var/tmp/image-tar/kurps.tar.gz.sha256 [ 124.157223] TEST-13-NSPAWN.sh[4311]: * closing connection #-1 [ 124.159198] TEST-13-NSPAWN.sh[4311]: * Could not open file /var/tmp/image-tar/kurps.nspawn [ 124.159493] TEST-13-NSPAWN.sh[4311]: * closing connection #-1 [ 124.159818] TEST-13-NSPAWN.sh[4311]: Acquired 68.5M. [ 124.160395] TEST-13-NSPAWN.sh[4311]: Download of file:///var/tmp/image-tar/kurps.tar.gz complete. [ 124.160664] TEST-13-NSPAWN.sh[4311]: Transfer failed: Could not read a file:// file [ 124.160923] TEST-13-NSPAWN.sh[4311]: Settings file could not be retrieved, proceeding without. [ 124.404733] TEST-13-NSPAWN.sh[4311]: * shutting down connection #1 [ 124.405162] TEST-13-NSPAWN.sh[4311]: Acquired 79B. [ 124.406170] TEST-13-NSPAWN.sh[4311]: Download of file:///var/tmp/image-tar/SHA256SUMS complete. [ 124.406734] TEST-13-NSPAWN.sh[4311]: SHA256 checksum of file:///var/tmp/image-tar/kurps.tar.gz is valid. [ 124.455446] TEST-13-NSPAWN.sh[4311]: Failed to rename to final image name to /home/testuser/.local/state/machines/.tar-file:\x2f\x2f\x2fvar\x2ftmp\x2fimage-tar\x2fkurps\x2etar\x2egz: File exists [ 124.457251] TEST-13-NSPAWN.sh[4311]: Exiting. ``` Workaround for issue systemd#38240.
aff7c48 to
63e0b1d
Compare
c35a30a to
bccc71a
Compare
src-up
pushed a commit
that referenced
this pull request
Apr 9, 2026
Fix a typo which causes a segfault when processing a user record
with matchHostname when it's an array instead of a simple string:
$ echo '{"userName":"crashhostarray","perMachine":[{"matchHostname":["host1","host2"],"locked":false}]}' | userdbctl -F -
Segmentation fault (core dumped)
$ coredumpctl info
...
Message: Process 1172301 (userdbctl) of user 1000 dumped core.
Module libz.so.1 from rpm zlib-ng-2.3.3-1.fc43.x86_64
Module libcrypto.so.3 from rpm openssl-3.5.4-2.fc43.x86_64
Stack trace of thread 1172301:
#0 0x00007fded7b3a656 __strcmp_evex (libc.so.6 + 0x159656)
#1 0x00007fded7e95397 per_machine_hostname_match (libsystemd-shared-260.so + 0x295397)
systemd#2 0x00007fded7e955b5 per_machine_match (libsystemd-shared-260.so + 0x2955b5)
systemd#3 0x00007fded7e957c6 dispatch_per_machine (libsystemd-shared-260.so + 0x2957c6)
systemd#4 0x00007fded7e96c97 user_record_load (libsystemd-shared-260.so + 0x296c97)
systemd#5 0x000000000040572d display_user (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x572d)
systemd#6 0x00007fded7ea9727 dispatch_verb (libsystemd-shared-260.so + 0x2a9727)
systemd#7 0x000000000041077c run (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x1077c)
systemd#8 0x00000000004107ce main (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x107ce)
systemd#9 0x00007fded79e45b5 __libc_start_call_main (libc.so.6 + 0x35b5)
systemd#10 0x00007fded79e4668 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3668)
systemd#11 0x00000000004038d5 _start (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x38d5)
ELF object binary architecture: AMD x86-64
src-up
pushed a commit
that referenced
this pull request
Apr 9, 2026
The fido2_hmac_salt/fido2_hmac_credential/recovery_key fields kept
leaking memory as the array itself wasn't deallocated after deallocating
each of its elements data:
$ build-san/userdbctl -F fuzz-corpus-userdb/auth-fido2.json
...
=================================================================
==1292840==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 112 byte(s) in 1 object(s) allocated from:
#0 0x7f56f00e5e4b in realloc.part.0 (/lib64/libasan.so.8+0xe5e4b) (BuildId: 25975f766867e9e604dc5a71a8befeaed3301942)
#1 0x7f56ed869e42 in greedy_realloc ../src/basic/alloc-util.c:65
systemd#2 0x7f56ed7ff5e9 in dispatch_fido2_hmac_salt ../src/shared/user-record.c:836
systemd#3 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
systemd#4 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
systemd#5 0x7f56ed80100b in dispatch_privileged ../src/shared/user-record.c:998
systemd#6 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
systemd#7 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
systemd#8 0x7f56ed80622c in user_record_load ../src/shared/user-record.c:1697
systemd#9 0x000000408c15 in display_user ../src/userdb/userdbctl.c:447
systemd#10 0x7f56ed83cc9a in dispatch_verb ../src/shared/verbs.c:137
systemd#11 0x00000041df2b in run ../src/userdb/userdbctl.c:1908
systemd#12 0x00000041dfbe in main ../src/userdb/userdbctl.c:1911
systemd#13 0x7f56ec8105b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
systemd#14 0x7f56ec810667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
systemd#15 0x000000404a44 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/userdbctl+0x404a44) (BuildId: 19e8b7e7b7038d2cea20bc18a55bea2a9e4406d5)
Direct leak of 64 byte(s) in 1 object(s) allocated from:
#0 0x7f56f00e5e4b in realloc.part.0 (/lib64/libasan.so.8+0xe5e4b) (BuildId: 25975f766867e9e604dc5a71a8befeaed3301942)
#1 0x7f56ed869e42 in greedy_realloc ../src/basic/alloc-util.c:65
systemd#2 0x7f56ed7fe779 in dispatch_fido2_hmac_credential_array ../src/shared/user-record.c:775
systemd#3 0x7f56edd73cbc in sd_json_dispatch_full ../src/libsystemd/sd-json/sd-json.c:5204
systemd#4 0x7f56edd745fc in sd_json_dispatch ../src/libsystemd/sd-json/sd-json.c:5276
systemd#5 0x7f56ed80622c in user_record_load ../src/shared/user-record.c:1697
systemd#6 0x000000408c15 in display_user ../src/userdb/userdbctl.c:447
systemd#7 0x7f56ed83cc9a in dispatch_verb ../src/shared/verbs.c:137
systemd#8 0x00000041df2b in run ../src/userdb/userdbctl.c:1908
systemd#9 0x00000041dfbe in main ../src/userdb/userdbctl.c:1911
systemd#10 0x7f56ec8105b4 in __libc_start_call_main (/lib64/libc.so.6+0x35b4) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
systemd#11 0x7f56ec810667 in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x3667) (BuildId: 2b5beec0fd24fe9c9f43eddfdd5facf0b8a1b805)
systemd#12 0x000000404a44 in _start (/home/fsumsal/repos/@systemd/systemd/build-san/userdbctl+0x404a44) (BuildId: 19e8b7e7b7038d2cea20bc18a55bea2a9e4406d5)
SUMMARY: AddressSanitizer: 176 byte(s) leaked in 2 allocation(s).
src-up
pushed a commit
that referenced
this pull request
Apr 9, 2026
…d#40979) Fix a typo which causes a segfault when processing a user record with `matchHostname` when it's an array instead of a simple string: ``` $ echo '{"userName":"crashhostarray","perMachine":[{"matchHostname":["host1","host2"],"locked":false}]}' | userdbctl -F - Segmentation fault (core dumped) $ coredumpctl info ... Message: Process 1172301 (userdbctl) of user 1000 dumped core. Module libz.so.1 from rpm zlib-ng-2.3.3-1.fc43.x86_64 Module libcrypto.so.3 from rpm openssl-3.5.4-2.fc43.x86_64 Stack trace of thread 1172301: #0 0x00007fded7b3a656 __strcmp_evex (libc.so.6 + 0x159656) #1 0x00007fded7e95397 per_machine_hostname_match (libsystemd-shared-260.so + 0x295397) systemd#2 0x00007fded7e955b5 per_machine_match (libsystemd-shared-260.so + 0x2955b5) systemd#3 0x00007fded7e957c6 dispatch_per_machine (libsystemd-shared-260.so + 0x2957c6) systemd#4 0x00007fded7e96c97 user_record_load (libsystemd-shared-260.so + 0x296c97) systemd#5 0x000000000040572d display_user (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x572d) systemd#6 0x00007fded7ea9727 dispatch_verb (libsystemd-shared-260.so + 0x2a9727) systemd#7 0x000000000041077c run (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x1077c) systemd#8 0x00000000004107ce main (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x107ce) systemd#9 0x00007fded79e45b5 __libc_start_call_main (libc.so.6 + 0x35b5) systemd#10 0x00007fded79e4668 __libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x3668) systemd#11 0x00000000004038d5 _start (/home/fsumsal/repos/@systemd/systemd/build/userdbctl + 0x38d5) ELF object binary architecture: AMD x86-64 ```
src-up
pushed a commit
that referenced
this pull request
Apr 27, 2026
There are only a few target dirs we place resources in when generating on-the-fly initrd cpios. These dirs have very specific attributes. Instead of repeating this everywhere, let's encapsulate them in a new explicit structure, that we can reuse at various places. This is preparation for placing extra resources of Type #1 entry also in them without having to encode access modes at multiple places redundantly.
src-up
pushed a commit
that referenced
this pull request
Jun 2, 2026
On some architectures like m68k, alignof(void*) is 2, not sizeof(void*)
(which is 4). So the natural alignment of struct Option is 2 and
sizeof(Option) == 26.
However, each variable placed in the SYSTEMD_OPTIONS ELF section via
_OPTION() carries _alignptr_ (= __attribute__((aligned(sizeof(void*))))),
which forces each entry to start at a 4-byte boundary. The linker
therefore inserts 2 bytes of padding between adjacent entries, producing
an actual stride of 28 in the section.
option_parse() iterates over the section with pointer arithmetic
("opt++"), which advances by sizeof(Option) == 26 and lands inside the
padding. The fields read back as zero, and since commit cf88903
("tree-wide: get rid of most uses of ALIGN_PTR") added the ordering
assertion below, the resulting "0 < 0" trips it when running --help:
Assertion 'opt->id < (opt + 1)->id' failed at src/shared/options.c:116, function option_parse(). Aborting.
#0 0xc0a7b248 in ?? () from /usr/lib/m68k-linux-gnu/libc.so.6
#1 0xc0a7b2ce in pthread_kill () from /usr/lib/m68k-linux-gnu/libc.so.6
systemd#2 0xc0a2edc6 in raise () from /usr/lib/m68k-linux-gnu/libc.so.6
systemd#3 0xc0a1c128 in abort () from /usr/lib/m68k-linux-gnu/libc.so.6
systemd#4 0xc05c6f78 in option_parse (options=0x0, options_end=0x0, state=0xc09ca968) at ../src/shared/options.c:116
Fix this by applying _alignptr_ to the struct definition itself, so that
sizeof(Option) is padded up to a multiple of sizeof(void*) and matches
the actual on-disk stride. Add an assert_cc() so any future regression
is caught at compile time.
The same latent bug applies to Verb and TestFunc, which use the same
section-placement pattern. Their natural sizeof was already a multiple
of sizeof(void*) so no crash was observed, but apply the same fix
defensively.
Follow-up for cf88903
Co-developed-by: Claude Opus 4.7 <noreply@anthropic.com>
src-up
pushed a commit
that referenced
this pull request
Jun 2, 2026
sd_journal_get_data() can return a MESSAGE data object whose payload does not start with "MESSAGE=", e.g. when the journal file is corrupted. Instead of aborting the whole process, log and skip over such an entry like we do for other bad/missing fields. [ 87.287390] post.sh[1619]: + journalctl -q -o short-monotonic --grep 'didn'\''t pass validation' [ 87.287844] post.sh[1620]: + grep -v test-varlink-idl [ 87.325676] post.sh[1619]: Assertion 'message = startswith(message, "MESSAGE=")' failed at src/journal/journalctl-show.c:261, function show(). Aborting. #0 0x00007fb47b49a29c n/a (libc.so.6 + 0x9a29c) #1 0x00007fb47b43e7d0 raise (libc.so.6 + 0x3e7d0) systemd#2 0x00007fb47b425681 abort (libc.so.6 + 0x25681) systemd#3 0x00007fb47b8a1ace log_assert_failed (libsystemd-shared-261~rc2.so + 0xa1ace) systemd#4 0x000055f8e1ef9ddb show (journalctl + 0xcddb) systemd#5 0x000055f8e1efa6ee action_show (journalctl + 0xd6ee) systemd#6 0x000055f8e1ef3c20 run (journalctl + 0x6c20) systemd#7 0x00007fb47b427741 n/a (libc.so.6 + 0x27741) systemd#8 0x00007fb47b427879 __libc_start_main (libc.so.6 + 0x27879) systemd#9 0x000055f8e1ef4915 _start (journalctl + 0x7915) Co-developed-by: Claude Opus 4.8 <noreply@anthropic.com>
52ef5aa to
ba6ab28
Compare
Replace assert_se() with the typed ASSERT_* macros throughout, matching the conversions done across the rest of src/test/.
Just a tiny simplification
…pecifier_table[] It's byte-by-byte exactly the same thing, hence drop the local copy.
This is preparation for later adding a per-component metadata file, so that we can have nicely symmetric functions for this.
This function only reads the .transfer files, hence give it a precise name.
These are located at two distinct places, and are very similar, let's put them in a common place. This is preparation for reusing them later.
…th nodes device_path_next_node() advances by the current node's Length field, which per the EFI device path protocol includes the 4-byte node header; a well-formed node is therefore at least sizeof(EFI_DEVICE_PATH) bytes long. A malformed node with Length < sizeof(EFI_DEVICE_PATH), in particular Length == 0, makes the helper return its input pointer unchanged. Advance by at least sizeof(EFI_DEVICE_PATH). Follow-up for 5080a60
When a variable exists but is empty, the initial size-query GetVariable() in efivar_get_raw_full() returns EFI_SUCCESS instead of EFI_BUFFER_TOO_SMALL: the zero-length payload already "fits" the zero-length query buffer. The helper returns success, but does not initialize the return parameters. Handle a couple of corner cases by checking the return size. Follow-up for a409607
de0da85 switched the unquote check to strchr8(QUOTES, value[0]), which is not equivalent to the old explicit comparison for an empty value: strchr8(), like strchr(3), returns a pointer to the haystack's terminating NUL when the needle is '\0', so strchr8(QUOTES, '\0') is non-NULL. For a line whose separator is the last byte (e.g. "ID=") the split leaves value[0] == '\0' and line[linelen - 1] == '\0' too, so both conjuncts hold and value++ steps one byte past the value's terminator. Follow-up for de0da85
pe_kernel_info() returned AddressOfEntryPoint (and the .compat section entry_point) straight from the PE header with no check against SizeOfImage. Since cab9c7b the stub calls the inner kernel directly as ImageBase + entry_point, and only EFI_SIZE_TO_PAGES(SizeOfImage) pages are allocated for it. Follow-up for cab9c7b
The inner-kernel section loader checks VirtualAddress + SizeOfRawData against kernel_size_in_memory (for the memcpy), but the memzero right after it clears up to VirtualAddress + VirtualSize, and VirtualSize is only constrained to be >= SizeOfRawData. Reject a VirtualAddress + VirtualSize that overflows or exceeds kernel_size_in_memory, mirroring the existing SizeOfRawData checks. Follow-up for cab9c7b
pe_locate_sections_internal() stores each matching section's VirtualSize and VirtualAddress into PeSectionVector.memory_size/memory_offset with only SIZE_MAX overflow guards, never checking them against the image's SizeOfImage. Wire up the image's SizeOfImage down to pe_locate_sections_internal() and skip any section whose in-memory section does not fit within it. Follow-up for fb974ac
linux_exec() marks code sections RO+X for W^X and reverts them to RW+NX in a loop just before returning, because EDK2 requires freed buffers to be writable and non-executable or FreePages() crashes. Not every error path is currently covered. Switch to a _cleanup_ helper so that every return path is covered. Follow-up for 56d19b6
linux_exec() patches the stub's own EFI_LOADED_IMAGE_PROTOCOL to point at the loaded inner kernel, and restores the saved original only after the entry point returns. The initrd_register() failure path returns without restoring, leaving the firmware's protocol pointing to freed data. Follow-up for f405165
verify_pe() only checked SizeOfOptionalHeader against a SIZE_MAX wrap (a clause that, given SizeOfOptionalHeader is a uint16_t, can never reject anything) and never read NumberOfRvaAndSizes. But pe_kernel_info(), pe_kernel_check_nx_compat() and pe_kernel_check_no_relocation() then read SizeOfImage, AddressOfEntryPoint, DllCharacteristics and the base relocation data directory entry from the optional header. Require SizeOfOptionalHeader to be large enough to contain everything down to the base relocation data directory entry, and require the image to declare that many data directory entries. Follow-up for bacc2ed
For some reason claude refuses to review systemd#42651. Let's see if we can make it work by splitting up the big PR into smaller ones. So here's the first one with 5 commits that should be relatively easy to review and get merged early.
Currently translated at 99.3% (284 of 286 strings) Co-authored-by: Michal Čihař <michal@cihar.com> Translate-URL: https://translate.fedoraproject.org/projects/systemd/main/cs/ Translation: systemd/main
Currently translated at 100.0% (286 of 286 strings) Co-authored-by: Léane GRASSER <leane.grasser@proton.me> Translate-URL: https://translate.fedoraproject.org/projects/systemd/main/fr/ Translation: systemd/main
Currently translated at 100.0% (286 of 286 strings) Co-authored-by: Jesse Guo <jesseguotech@outlook.com> Translate-URL: https://translate.fedoraproject.org/projects/systemd/main/zh_CN/ Translation: systemd/main
Translations update from [Fedora Weblate](https://translate.fedoraproject.org) for [systemd/main](https://translate.fedoraproject.org/projects/systemd/main/). Current translation status: 
Let's not manually create comments, but use the usual varlink_idl_format_comment() function which does line break handling properly. This polishes the output for very narrow outputs, since we'll line break these synthetic comments too.
The mic-mute key on the Logitech K950 keyboard (046D:B388, Bluetooth) emits BTN_0 (scancode 0x100e1) instead of a usable key, so it does nothing under GNOME/KDE. Map it to KEY_MICMUTE, its intended function. Scancode determined with evtest on the device.
Adds dm-clone device setup at boot via a new /etc/clonetab config file, following the crypttab/veritytab pattern. - Add systemd-clonesetup-generator to parse /etc/clonetab and generate units. - Add systemd-clonesetup binary to create/remove dm-clone devices via ioctl. - Add clonesetup.target for ordering dm-clone activation at boot. - Add region_size= option in clonetab to configure dm-clone hydration granularity. - Add clonetab(5) and systemd-clonesetup-generator(8) man pages. Fixes: systemd#39500
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.