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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Otherwise they will pull down the disk too, which we don't want on soft-reboot
(cherry picked from commit bbb0b72849ebbeeb8e252d9aeed94521df4f0ae8)
(cherry picked from commit 1747350ffd05e2588b808d17befbc36072207c3c)
* Remove extra period at end of unit description.
Having an extra period at the end of this unit description makes log entries pertaining to it appear weirdly, as it seems the default expectation is that there is not to be a period at the end of a unit description.
e.g.: `systemd[1]: Started Displays emergency message in full screen..`
(cherry picked from commit 496b4fa0e974d7a1b10b8af966da445a28f512c5)
(cherry picked from commit 35e2f6296782a7aadd52baad33c17b350a564a09)
Historically, systemd-tmpfiles was designed to manager temporary
files, but nowadays it has become a generic tool for managing
all kinds of files. To avoid user confusion, let's remove "temporary"
from the tool's description.
As discussed in #33349
(cherry picked from commit b5c8cc0a3b8e4e2fea0539d6420a76b524ea5735)
(cherry picked from commit 1a0e6961cfaed42bda542e111738c136f7b4d73f)
The TPM might be password/pin protected for various reasons even if
there is no SRK yet. Let's handle those cases gracefully instead of
failing the unit as it is enabled by default.
(cherry picked from commit d6518003f8ebbfb6f85dbf227736ae05b0961199)
(cherry picked from commit 30df42a9277bbf138d52887c9b79e452db425585)
Currently the associated units fail if full tpm support is not available
on the system. Similar to systemd-pcrextend, let's add a --graceful option
that exits gracefully if no full TPM support is detected and use it in both
units.
(cherry picked from commit 966e05af048bd388921de88ec1a550856b8d4280)
Right now systemd-tpm2-setup-early and systemd-pcrphase-initrd.service
are not ordered against each other. However, they require the same slow
resource to operate: the TPM2. If we allow them to access the device
simultaneously, the kernel resource manager like has to save/restore TPM
state while they operate, slowing things down further.
hence, let's avoid all this mess, and just order them against each other
so that the shared resource is first used in full by one and then by the
other.
I opted to order systemd-pcrphase-initrd before
systemd-tpm2-setup-early, since there's value in having the former as
early as possible in userspace, to be a good marker for the transition
from kernel to first userspace. I can see no benefit in the opposite
order however.
(cherry picked from commit a6e9c37f5e7ecaac81f028bff6b7e206484960e6)
The service will use either, so let's make sure either of them starts
the service as well.
(cherry picked from commit c0aeff4b999318d4da48328fff0ea93c8c457ace)
The unit will be started or restarted a few times during boot, but but it has
StartLimitBurst = DefaultStartLimitBurst = 5, which means that the fifth
restart will already fail. On my laptop, I have exactly 4 restarts, so I don't
hit the limit, but on a slightly different system we will easily hit the limit.
In https://bugzilla.redhat.com/show_bug.cgi?id=2251394, there are five reloads
and we hit the limit.
Since 6ef512c0bb7aeb2000588d7d05e23b4681da8657 we propagate the start counter
over switch-root and daemon reloads, so it's easier to hit the limit during
boot.
In principle there might be systems with lots of vtcon devices, so let's just
allow the unit to be restarted without a limit.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=2251394.
This implements a "storage target mode", similar to what MacOS provides
since a long time as "Target Disk Mode":
https://en.wikipedia.org/wiki/Target_Disk_Mode
This implementation is relatively simple:
1. a new generic target "storage-target-mode.target" is added, which
when booted into defines the target mode.
2. a small tool and service "systemd-storagetm.service" is added which
exposes a specific device or all devices as NVMe-TCP devices over the
network. NVMe-TCP appears to be hot shit right now how to expose
block devices over the network. And it's really simple to set up via
configs, hence our code is relatively short and neat.
The idea is that systemd-storagetm.target can be extended sooner or
later, for example to expose block devices also as USB mass storage
devices and similar, in case the system has "dual mode" USB controller
that can also work as device, not just as host. (And people could also
plug in sharing as NBD, iSCSI, whatever they want.)
How to use this? Boot into your system with a kernel cmdline of
"rd.systemd.unit=storage-target-mode.target ip=link-local", and you'll see on
screen the precise "nvme connect" command line to make the relevant
block devices available locally on some other machine. This all requires
that the target mode stuff is included in the initrd of course. And the
system will the stay in the initrd forever.
Why bother? Primarily three use-cases:
1. Debug a broken system: with very few dependencies during boot get
access to the raw block device of a broken machine.
2. Migrate from system to another system, by dd'ing the old to the new
directly.
3. Installing an OS remotely on some device (for example via Thunderbolt
networking)
(And there might be more, for example the ability to boot from a
laptop's disk on another system)
Limitations:
1. There's no authentication/encryption. Hence: use this on local links
only.
2. NVMe target mode on Linux supports r/w operation only. Ideally, we'd
have a read-only mode, for security reasons, and default to it.
Future love:
1. We should have another mode, where we simply expose the homed LUKS
home dirs like that.
2. Some lightweight hookup with plymouth, to display a (shortened)
version of the info we write to the console.
To test all this, just run:
mkosi --kernel-command-line-extra="rd.systemd.unit=storage-target-mode.target" qemu
modprobe treats "-" and "_" interchangeably, thereby avoiding frequent
errors because some module names contain dashes and others underscores.
Because modprobe@.service unescapes the instance name, an attempt to
start "modprobe@dm-crypt.service" will run "modprobe -abq dm/crypt",
which is doomed to fail. "modprobe@dm_crypt.service" will work as
expected. Thus unescaping the instance name has surprising side effects.
Use "%i" instead.
When --boot is set, and --keep-unit is not, set CoredumpReceive=yes on
the scope allocated for the container. When --keep-unit is set, nspawn
does not allocate the container's unit, so the existing unit needs to
configure this setting itself.
Since systemd-nspawn@.service sets --boot and --keep-unit, add
CoredumpReceives=yes to that unit.
As systemd-journal-upload deals mostly with remote servers, add
some failsafes to its unit to restart on failures.
```
[Service]
Restart=on-failure
RestartSteps=10
RestartMaxDelaySec=60
```
This is primarily supposed to be a 1st step with varlinkifying our
various command line tools, and excercise in how this might look like
across our codebase one day. However, at AllSystemsGo! 2023 it was
requested that we provide an API to do a PCR measurement along with a
matching event log record, and this provides that.
This adds an explicit service for initializing the TPM2 SRK. This is
implicitly also done by systemd-cryptsetup, hence strictly speaking
redundant, but doing this early has the benefit that we can parallelize
this in a nicer way. This also write a copy of the SRK public key in PEM
format to /run/ + /var/lib/, thus pinning the disk image to the TPM.
Making the SRK public key is also useful for allowing easy offline
encryption for a specific TPM.
Sooner or later we should probably grow what this service does, the
above is just the first step. For example, the service should probably
offer the ability to reset the TPM (clear the owner hierarchy?) on a
factory reset, if such a policy is needed. And we might want to install
some default AK (?).
Fixes: #27986
Also see: #22637
Follow-up for d120ce478dc0043c89899799b5c1aaf62901bea9
blockdev@.target is used as a synchronization point between
the mount unit and corresponding systemd-cryptsetup@.service.
After the mentioned commit, it doesn't get a stop job enqueued
during shutdown, and thus the stop job for systemd-cryptsetup@.service
could be run before the mount unit is stopped.
Therefore, let's make blockdev@.target conflict with umount.target,
which is also what systemd-cryptsetup@.service does.
Fixes#29336
So, unfortunately oomd uses "io.system." rather than "io.systemd." as
prefix for its sockets. This is a mistake, and doesn't match the
Varlink interface naming or anything else in oomd.
hence, let's fix that.
Given that this is an internal protocol between PID1 and oomd let's
simply change this without retaining compat.
The tool initially just measured the boot phase, but was subsequently
extended to measure file system and machine IDs, too. At AllSystemsGo
there were request to add more, and make the tool generically
accessible.
Hence, let's rename the binary (but not the pcrphase services), to make
clear the tool is not just measureing the boot phase, but a lot of other
things too.
The tool is located in /usr/lib/ and still relatively new, hence let's
just rename the binary and be done with it, while keeping the unit names
stable.
While we are at it, also move the tool out of src/boot/ and into its own
src/pcrextend/ dir, since it's not really doing boot related stuff
anymore.
When booting from virtiofs, we won't be able to find a root block
device. Let's gracefully handle this similar to how we don't fail
if we can't find a GPT partition table.
Before this commit, the hibernate location logic only exists in
the generator. Also, we compare device nodes (devnode_same()) and
clear EFI variable HibernateLocation in the generator too. This is
not ideal though: when the generator gets to run, udev hasn't yet
started, so effectively devnode_same() always fails. Moreover, if
the boot process is interrupted by e.g. battery-check, the hibernate
information is lost.
Therefore, let's split out the logic of finding hibernate location.
The generator only does the initial validation of system info and
enables systemd-hibernate-resume.service, and when the service
actually runs we validate everything again, which includes comparing
the device nodes and clearing the EFI variable. This should make
things more robust, plus systems that don't utilize a systemd-enabled
initrd can use the exact same logic to resume using the EFI variable.
I.e., systemd-hibernate-resume can be used standalone.
Otherwise the root filesystem might still be readonly and
systemd-userdbd fails to start.
Explicitly pick systemd-remount-fs.service instead of local-fs-pre.target
to prevent a dependency cycle.
- add reference to the service unit in the man page,
- fix several indentation and typos,
- replace '(uint64_t) -1' with 'UINT64_MAX',
- drop unnecessary 'continue'.
This makes tmpfiles, sysusers, and udevd invoked in the following order:
1. systemd-tmpfiles-setup-dev-early.service
Create device nodes gracefully, that is, create device nodes anyway
by ignoring unknown users and groups.
2. systemd-sysusers.service
Create users and groups, to make later invocations of tmpfiles and
udevd can resolve necessary users and groups.
3. systemd-tmpfiles-setup-dev.service
Adjust owners of previously created device nodes.
4. systemd-udevd.service
Process all devices. Especially to make block devices active and can
be mountable.
5. systemd-tmpfiles-setup.service
Setup basic filesystem.
Follow-up for b42482af904ae0b94a6e4501ec595448f0ba1c06.
Fixes#28653.
Replaces #28681 and #28732.
This reverts commits 112a41b6ece19d03e951d886fe2f26512ab31fab,
3178698bb5352989e4bff866641838b1c2a0efcb, and
b768379e8b494b025f41946205944a6f3a1a553f.
The commit 112a41b6ece19d03e951d886fe2f26512ab31fab introduces #28765,
as systemd-tmpfiles-setup.service has ordering after local-fs.target,
but usually the target requires block devices processed by udevd.
Hence, the service can only start after the block devices timed out.
Fixes#28765.
Follow-up for b42482af904ae0b94a6e4501ec595448f0ba1c06.
The commit makes systemd-tmpfiles-setup.service also updates the
permission or owner of device nodes. However, the service does not have
ordering for systemd-udevd.service. So, the service may set different
permission from the one udevd already set.
Fixes#28653.
Replaces #28681.
This reverts commit 31845ef554877525dc4ff4f25ad11ad805ebf81c.
systemd-tmpfiles-setup-dev.service has Before=systemd-udevd.service.
So the commit does not change anything.
If emergency.target is started while initrd-parse-etc.service/start is queued,
the initrd-parse-etc job did not get canceled. In parallel to the emergency
units, it eventually runs the service, which starts initrd-cleanup.service,
which in turn isolates initrd-switch-root.target. This stops the emergency
units and effectively starts the initrd boot process again, which likely
fails again like the initial attempt. The system is thus stuck in an endless
loop, never really reaching emergency.target.
With this conflict added, starting emergency.target automatically cancels
initrd-parse-etc.service/start, avoiding the loop.
Without this change, there are no ordering between udevd and tmpfiles,
and if tmpfiles is invoked later it may discard the permission set by
udevd.
Fixes an issue introduced by b42482af904ae0b94a6e4501ec595448f0ba1c06.
Fixes#28588 and #28653.
In it's latest release, agetty will support reading the agetty.autologin
and login.noauth credentials, so let's make sure we import those in our
getty units so they're available to agetty to read.
Some of the new units using systemd-pcrphase are missing the --graceful
flag which causes them to error if the tpm libraries are not installed.
Add --graceful just like in the other pcrphase units to make systemd-pcrphase
exit gracefully if the tpm libraries are missing.
