[systemd-devel] systemd 255 released

2023-12-06 Thread systemd tag bot
 A new, official systemd release has just  been  tagged . Please download 
the tarball here:

https://github.com/systemd/systemd/archive/v255.tar.gz

Changes since the previous release:

Announcements of Future Feature Removals and Incompatible Changes:

* Support for split-usr (/usr/ mounted separately during late boot,
  instead of being mounted by the initrd before switching to the rootfs)
  and unmerged-usr (parallel directories /bin/ and /usr/bin/, /lib/ and
  /usr/lib/, …) has been removed. For more details, see:
  
https://lists.freedesktop.org/archives/systemd-devel/2022-September/048352.html

* We intend to remove cgroup v1 support from a systemd release after
  the end of 2023. If you run services that make explicit use of
  cgroup v1 features (i.e. the "legacy hierarchy" with separate
  hierarchies for each controller), please implement compatibility with
  cgroup v2 (i.e. the "unified hierarchy") sooner rather than later.
  Most of Linux userspace has been ported over already.

* Support for System V service scripts is now deprecated and will be
  removed in a future release. Please make sure to update your software
  *now* to include a native systemd unit file instead of a legacy
  System V script to retain compatibility with future systemd releases.

* Support for the SystemdOptions EFI variable is deprecated.
  'bootctl systemd-efi-options' will emit a warning when used. It seems
  that this feature is little-used and it is better to use alternative
  approaches like credentials and confexts. The plan is to drop support
  altogether at a later point, but this might be revisited based on
  user feedback.

* systemd-run's switch --expand-environment= which currently is disabled
  by default when combined with --scope, will be changed in a future
  release to be enabled by default.

* "systemctl switch-root" is now restricted to initrd transitions only.

  Transitions between real systems should be done with
  "systemctl soft-reboot" instead.

* The "ip=off" and "ip=none" kernel command line options interpreted by
  systemd-network-generator will now result in IPv6RA + link-local
  addressing being disabled, too. Previously DHCP was turned off, but
  IPv6RA and IPv6 link-local addressing was left enabled.

* The NAMING_BRIDGE_MULTIFUNCTION_SLOT naming scheme has been deprecated
  and is now disabled.

* SuspendMode=, HibernateState= and HybridSleepState= in the [Sleep]
  section of systemd-sleep.conf are now deprecated and have no effect.
  They did not (and could not) take any value other than the respective
  default. HybridSleepMode= is also deprecated, and will now always use
  the 'suspend' disk mode.

Service Manager:

* The way services are spawned has been overhauled. Previously, a
  process was forked that shared all of the manager's memory (via
  copy-on-write) while doing all the required setup (e.g.: mount
  namespaces, CGroup configuration, etc.) before exec'ing the target
  executable. This was problematic for various reasons: several glibc
  APIs were called that are not supposed to be used after a fork but
  before an exec, copy-on-write meant that if either process (the
  manager or the child) touched a memory page a copy was triggered, and
  also the memory footprint of the child process was that of the
  manager, but with the memory limits of the service. From this version
  onward, the new process is spawned using CLONE_VM and CLONE_VFORK
  semantics via posix_spawn(3), and it immediately execs a new internal
  binary, systemd-executor, that receives the configuration to apply
  via memfd, and sets up the process before exec'ing the target
  executable. The systemd-executor binary is pinned by file descriptor
  by each manager instance (system and users), and the reference is
  updated on daemon-reexec - it is thus important to reexec all running
  manager instances when the systemd-executor and/or libsystemd*
  libraries are updated on the filesystem.

* Most of the internal process tracking is being changed to use PIDFDs
  instead of PIDs when the kernel supports it, to improve robustness
  and reliability.

* A new option SurviveFinalKillSignal= can be used to configure the
  unit to be skipped in the final SIGTERM/SIGKILL spree on shutdown.
  This is part of the required configuration to let a unit's processes
  survive a soft-reboot operation.

* System extension images (sysext) can now set
  EXTENSION_RELOAD_MANAGER=1 in 

Re: [systemd-devel] Manual start of user@.service failed with permission denied

2023-12-06 Thread Luca Boccassi
On Wed, 6 Dec 2023 at 16:00, Christopher Wong  wrote:
> Hi,
>
> I’m trying to do the following:
>
> root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/503"

Why are you setting this?
Anyway, enable debug level log and attach the output, otherwise it's hard to say


Re: [systemd-devel] Manual start of user@.service failed with permission denied

2023-12-06 Thread Lennart Poettering
On Mi, 06.12.23 14:46, Christopher Wong (christopher.w...@axis.com) wrote:

> Hi,
>
> I’m trying to do the following:
>
> root@host:~# systemctl set-environment
> XDG_RUNTIME_DIR="/run/user/503"

Why would you do that?

user@.service automatically pulls in user-runtime-dir@.service which
is responsible for creating that dir with right perms.

is 504 a system user? or a regular user?

systemd generally assumes the boundary between system and regular
users is between 999 and 1000.

But user@.service is really just for regular users, not system users,
hence my question.

Lennart

--
Lennart Poettering, Berlin


Re: [systemd-devel] How to debug systemd-pcrphase-initrd.service failure

2023-12-06 Thread Daan De Meyer
Note that we also have `InitrdPackages=` in the latest mkosi release
which allows you to add extra packages to the default initrd without
having to build one separately.

Cheers,

Daan

On Wed, 6 Dec 2023 at 14:26, Renjaya Raga Zenta  wrote:
>
> Yes, I think now I understand that mkosi will build default initrd image 
> without tpm2-tss libraries. Perhaps because the package names are different 
> for each distro.
>
> I need to build the initrd image separately at first, then use it to build OS 
> image with --initrd flag.
>
> Thanks.
>
> On Wed, Dec 6, 2023 at 8:02 PM Lennart Poettering  
> wrote:
>>
>> On Mi, 06.12.23 18:28, Renjaya Raga Zenta (ragaze...@gmail.com) wrote:
>>
>> > Hi,
>> >
>> > I am exploring OS image building with mkosi. It works great until I add TPM
>> > 2.0 in qemu.
>> >
>> > I found that the systemd-pcrphase-initrd.service failed. There are 3
>> > pcrphase service:
>> >
>> > 1. systemd-pcrphase-initrd.service (failed)
>> > 2. systemd-pcrphase.service (ok)
>> > 3. systemd-pcrphase-sysinit.service (ok)
>>
>> So the latter two run from the host fs, the first one from the initrd fs.
>>
>> > Related journal log:
>> > systemd[1]: Failed to start systemd-pcrphase-initrd.service - TPM2 PCR
>> > Barrier (initrd).
>> > ...
>> > systemd-pcrphase[130]: Failed to load TPM2 libraries: Operation not
>> > supported
>> > ...
>>
>> It appears you are lacking the tpm2-tss libraries in your initrd image.
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Berlin
>
>
>
> --
> Renjaya Raga Zenta
> Mobile:
> +62 811 572 4400


[systemd-devel] Manual start of user@.service failed with permission denied

2023-12-06 Thread Christopher Wong
Hi,

I’m trying to do the following:

root@host:~# systemctl set-environment XDG_RUNTIME_DIR="/run/user/503"
root@host:~# systemctl start user@503.service

On systemd 253.4, the user can be started manually, and I can list the 
directory:

root@host:~# ls -la /run/user/503
drwx--3 debugar  debugar 80 Dec  4 09:08 .
drwxr-xr-x3 root root60 Dec  4 09:08 ..
srw-rw-rw-1 debugar  debugar  0 Dec  4 09:08 bus
drwxr-xr-x4 debugar  debugar120 Dec  4 09:08 systemd

On last systemd v254-stable and v255-stable, I got the following instead:

root@host:/var/log# journalctl -xeu user@503.service
Dec 06 12:40:41 host systemd[1]: Starting User Manager for UID 503...
Dec 06 12:40:41 host systemd[7939]: Failed to copy os-release for propagation, 
ignoring: Permission denied
Dec 06 12:40:41 host systemd[7939]: Failed to allocate manager object: 
Permission denied
Dec 06 12:40:41 host systemd[1]: user@503.service: 
Main process exited, code=exited, status=1/FAILURE
Dec 06 12:40:41 host systemd[1]: user@503.service: 
Failed with result 'exit-code'.
Dec 06 12:40:41 host systemd[1]: Failed to start User Manager for UID 503.

systemd was able to create the dir /run/user/503, but got errno -13 (Permission 
denied) when it was trying to do mkdirat with path /run/user/503/systemd in 
function mkdirat_label() in file mkdir-label.c.

Do I need to do something else before starting 
user@.service or is this a bug?

Best regards,
Christopher Wong





Re: [systemd-devel] How to debug systemd-pcrphase-initrd.service failure

2023-12-06 Thread Renjaya Raga Zenta
Yes, I think now I understand that mkosi will build default initrd image
without tpm2-tss libraries. Perhaps because the package names are different
for each distro.

I need to build the initrd image separately at first, then use it to build
OS image with --initrd flag.

Thanks.

On Wed, Dec 6, 2023 at 8:02 PM Lennart Poettering 
wrote:

> On Mi, 06.12.23 18:28, Renjaya Raga Zenta (ragaze...@gmail.com) wrote:
>
> > Hi,
> >
> > I am exploring OS image building with mkosi. It works great until I add
> TPM
> > 2.0 in qemu.
> >
> > I found that the systemd-pcrphase-initrd.service failed. There are 3
> > pcrphase service:
> >
> > 1. systemd-pcrphase-initrd.service (failed)
> > 2. systemd-pcrphase.service (ok)
> > 3. systemd-pcrphase-sysinit.service (ok)
>
> So the latter two run from the host fs, the first one from the initrd fs.
>
> > Related journal log:
> > systemd[1]: Failed to start systemd-pcrphase-initrd.service - TPM2 PCR
> > Barrier (initrd).
> > ...
> > systemd-pcrphase[130]: Failed to load TPM2 libraries: Operation not
> > supported
> > ...
>
> It appears you are lacking the tpm2-tss libraries in your initrd image.
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>


-- 
Renjaya Raga Zenta
Mobile:
+62 811 572 4400


Re: [systemd-devel] How to debug systemd-pcrphase-initrd.service failure

2023-12-06 Thread Lennart Poettering
On Mi, 06.12.23 18:28, Renjaya Raga Zenta (ragaze...@gmail.com) wrote:

> Hi,
>
> I am exploring OS image building with mkosi. It works great until I add TPM
> 2.0 in qemu.
>
> I found that the systemd-pcrphase-initrd.service failed. There are 3
> pcrphase service:
>
> 1. systemd-pcrphase-initrd.service (failed)
> 2. systemd-pcrphase.service (ok)
> 3. systemd-pcrphase-sysinit.service (ok)

So the latter two run from the host fs, the first one from the initrd fs.

> Related journal log:
> systemd[1]: Failed to start systemd-pcrphase-initrd.service - TPM2 PCR
> Barrier (initrd).
> ...
> systemd-pcrphase[130]: Failed to load TPM2 libraries: Operation not
> supported
> ...

It appears you are lacking the tpm2-tss libraries in your initrd image.

Lennart

--
Lennart Poettering, Berlin


[systemd-devel] How to debug systemd-pcrphase-initrd.service failure

2023-12-06 Thread Renjaya Raga Zenta
Hi,

I am exploring OS image building with mkosi. It works great until I add TPM
2.0 in qemu.

I found that the systemd-pcrphase-initrd.service failed. There are 3
pcrphase service:

1. systemd-pcrphase-initrd.service (failed)
2. systemd-pcrphase.service (ok)
3. systemd-pcrphase-sysinit.service (ok)

Related journal log:
systemd[1]: Failed to start systemd-pcrphase-initrd.service - TPM2 PCR
Barrier (initrd).
...
systemd-pcrphase[130]: Failed to load TPM2 libraries: Operation not
supported
...

My mkosi.conf:

[Distribution]
Distribution=debian
Repositories=contrib,non-free,non-free-firmware
Release=bookworm

[Output]
Format=disk
ImageId=test
ImageVersion=0.1.0

[Content]
Bootable=yes
Locale=en_US.UTF-8
LocaleMessages=en_US.UTF-8
Keymap=us
Timezone=Asia/Jakarta
Hostname=test

KernelCommandLine=
console=ttyS0
console=tty1
loglevel=4

Packages=
amd64-microcode
apt
apt-transport-https
bash-completion
ca-certificates
coreutils
curl
dbus-broker
debian-archive-keyring
dosfstools
e2fsprogs
efibootmgr
file
gdisk
intel-microcode
jq
less
libtss2-dev
linux-image-amd64
locales
man-db
openssh-client
parted
systemd
systemd-boot
systemd-resolved
systemd-sysv
systemd-timesyncd
tzdata
udev
usbutils
zstd

[Validation]
SecureBoot=yes

Bookworm still uses systemd 252, is that related? Previously without the
libtss2-dev package installed, all 3 services above failed. So perhaps the
initrd doesn't have libtss2-dev installed. How to include it then?

Thanks


[systemd-devel] Can't get port mapping to work for https

2023-12-06 Thread Rob Ert
Hello all,

I'm running a systemd-nspawn container started with machinectl using the
following systemd.nspawn file in /etc/systemd/nspawn:

[Exec]
PrivateUsers=off
Timezone=off
[Network]
VirtualEthernet=yes
Port=tcp:23:22
Port=tcp:8080:80
Port=tcp:4433:443

The problem I'm having is that the port mapping for 443 fails, whereas the
other mappings work. The listed services are all active in the guest
system, and no firewall rules are active.

System: Debian

Host: # apt list systemd-container
Listing... Done
systemd-container/testing,now 254.5-1 amd64 [installed]

Guest: # apt list systemd-container
Listing... Done
systemd-container/stable,now 252.17-1~deb12u1 amd64 [installed]


Any help would be much appreciated.

Best regards,
Rob