(#2006762) resolved: synthesize option #64
Closed
+25,901
−7,022
Conversation
This file contains 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
systemd-rhel-bot
added
pr/needs-ci
|
@jacekmigacz You need to prepare upstream PR and get it merged. We can't merge this downstream before this lands in systemd/systemd. Thanks! |
|
@msekletar I've proposed it to the upstream at: systemd/systemd#22599. |
systemd-rhel-bot
changed the title
systemd-rhel-bot
added
pr/needs-ci
jamacku
changed the title
…again (cherry picked from commit a520d5d) Related: #2065061
kernel-install would continue after errors… We don't want this, as it makes the results totally unpredicatable. If we didn't install the kernel or didn't do some important part of the setup, let's just return an error and let the user deal with it. When looking at output, the error was often hard to distinguish, esp. with -v. Add "Error:" everywhere to make the output easier to parse. (cherry picked from commit 680cec6) Related: #2065061
The general approach of kernel-install was that each plugin would drop in some files into the entry directory. But this doesn't scale well, because if we have multiple initrd generators, or multiple initrds, each generator would need to recreate the logic to put the generated files in the right place. Also, effective cleanup is impossible if anything goes wrong on the way, so we could end up with unused files in $BOOT. So let's invert the process: plugins drop files into $KERNEL_INSTALL_STAGING_AREA, and at the end 90-loaderentry.install DTRT with those files. This allow new plugins like 50-mkosi-initrd.install to be significantly simpler. (cherry picked from commit 367165a) Related: #2065061
(cherry picked from commit 29f6041) Related: #2065061
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.
(cherry picked from commit 11ce3ea)
Related: #2065061
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. (cherry picked from commit 3907044) Related: #2065061
… if 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. (cherry picked from commit 953b610) Related: #2065061
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. (cherry picked from commit 6637cf9) Related: #2065061
…we discovered (cherry picked from commit c73cf41) Related: #2065061
Add rules for `needs-ci` label management RHEL-only Related: #2087652
RHEL-only Related: #2087652
Fixes #23317 (cherry picked from commit 2aaf6d4) Related: #2087652
Empty files and empty strings seem to have triggered various issues in the past so it seems they shouldn't be ignore by the fuzzers just because fmemopen can't handle them. Prompted by systemd/systemd#21939 (comment) (cherry picked from commit 5df66d7) Related: #2087652
We'd connect to the bus twice: the first time to check networkd namespace, and then the second time to do the deed we were asked to do. It's nicer to open the bus just once, for efficience and also to avoid the open call in all functions. An ASSERT_PTR helper is added: - sd_bus *bus = userdata; ... - assert(bus); + sd_bus *bus = ASSERT_PTR(userdata); ... It can be used in other place too, but I'm leaving that for a later refactoring. (cherry picked from commit d821e40) Related: #2087652
(cherry picked from commit 5ea8bcd) Related: #2087778
It has the same issue as the Google Hangouts Meet speakermic but a different VID/PID. (cherry picked from commit 1a2134f) Related: #2087778
(cherry picked from commit cc9e3a5) Related: #2087778
This enables the microphone mute and programmable hotkey for the HP Dev One. (cherry picked from commit 295e029) Related: #2087778
The USB ID v0483pDF11 is used by the ROM code in many STMicroelectronics devices (for firmware download) and not just signal analyzers. (cherry picked from commit 5d049ff) Related: #2087778
(cherry picked from commit c3b8113) Related: #2087778
(cherry picked from commit 8170627) Related: #2087778
Enables the power button on the Acer Aspire 3 A317-33 (cherry picked from commit 0216462) Related: #2087778
(cherry picked from commit e18569c) Related: #2087778
* Added DERE DBook D10 (cherry picked from commit 2d2efed) Related: #2087778
(cherry picked from commit 838d0fd) Related: #2087778
They're floppy disk flux readers and writers used in digital preservation and can be broadly considered to be "analyzers" of magnetic fluxes. This will have the intended side-effect of giving access to the device to users at the console, obsoleting: https://github.com/keirf/greaseweazle/blob/master/scripts/49-greaseweazle.rules (cherry picked from commit 9ab755d) Related: #2087778
The cros-ec-accel and cros-ec-accel-legacy kernel modules internally correct for the board-specific accelerometer mounting orientations. Their sensor outputs are in a standard reference frame consistent across different boards, so the orientation matrix already added for a number of devices should apply to every device using cros-ec accelerometers. The different matrix for the 'Nocturne' board seems to be an error. Replace the existing hwdb rules for select Chromebooks with generic rules that apply to all Chromebooks. (cherry picked from commit 1800f70) Related: #2087778
systemd-rhel-bot
changed the title
(cherry picked from commit 6e961ae) Resolves: #2120222
jamacku
changed the title
Previously it was possible to set delegate property for scope, but you were not able to allow unprivileged process to manage the scope's cgroup hierarchy. This is useful when launching manager process that will run unprivileged but is supposed to manage its own (scope) sub-hierarchy. Fixes #21683 (cherry picked from commit 0386019) Resolves: #2120604
RHEL-only Resolves: #2121144
It performs differential ShellCheck scans and report results directly in pull request. documentation: https://github.com/redhat-plumbers-in-action/differential-shellcheck (inspired by commit systemd/systemd@3f3c718) RHEL-only Related: #2122500
(cherry picked from commit d896260) Resolves: #2006762
jacekmigacz
force-pushed
the
bz2006762
branch
from
1376ee4
to
24631ac
Compare
|
This is a lightweight version of the original patch; limited to controlling hostname synthesis. |
|
This change should no longer be needed since the rebase to v252. |
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.
It is currently possible to query with
resolvectland provide--synthesize=noflag for non-synthesized answers.This patch provides systemd-resolved synthesize control switch and makes possible to disable synthesized answers for the regular DNS questions (like these emitted from
nslookupordig).