Re: [systemd-devel] systemd prerelease 256-rc1
On Thu, Apr 25, 2024 at 6:15 PM systemd tag bot
wrote:
>
> A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
> tarball here:
>
> https://github.com/systemd/systemd/archive/v256-rc1.tar.gz
>
> NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
> systems, but please test this and report any issues you find to GitHub:
>
> https://github.com/systemd/systemd/issues/new?template=Bug_report.md
>
> Changes since the previous release:
>
> Announcements of Future Feature Removals and Incompatible Changes:
>
> * Support for automatic flushing of the nscd user/group database
> caches
> will be dropped in a future release.
>
> * Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is now
> considered obsolete and systemd by default will refuse to boot under
> it. To forcibly reenable cgroup v1 support,
> SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must be set on kernel command
> line. The meson option 'default-hierarchy=' is also deprecated, i.e.
> only cgroup v2 ('unified' hierarchy) can be selected as build-time
> default.
>
> * Previously, systemd-networkd did not explicitly remove any bridge
> VLAN IDs assigned on bridge master and ports. Since version 256, if
> a
> .network file for an interface has at least one valid setting in the
> [BridgeVLAN] section, then all assigned VLAN IDs on the interface
> that are not configured in the .network file are removed.
>
> * systemd-gpt-auto-generator will stop generating units for ESP or
> XBOOTLDR partitions if it finds mount entries for or below the
> /boot/
> or /efi/ hierarchies in /etc/fstab. This is to prevent the generator
> from interfering with systems where the ESP is explicitly configured
> to be mounted at some path, for example /boot/efi/ (this type of
> setup is obsolete, but still commonly found).
>
This is not obsolete. Please do not say it is when it is not true.
--
真実はいつも一つ！/ Always, there's only one truth!
[systemd-devel] systemd prerelease 256-rc1
A new systemd ☠️ pre-release ☠️ has just been tagged. Please download the
tarball here:
https://github.com/systemd/systemd/archive/v256-rc1.tar.gz
NOTE: This is ☠️ pre-release ☠️ software. Do not run this on production
systems, but please test this and report any issues you find to GitHub:
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Changes since the previous release:
Announcements of Future Feature Removals and Incompatible Changes:
* Support for automatic flushing of the nscd user/group database caches
will be dropped in a future release.
* Support for cgroup v1 ('legacy' and 'hybrid' hierarchies) is now
considered obsolete and systemd by default will refuse to boot under
it. To forcibly reenable cgroup v1 support,
SYSTEMD_CGROUP_ENABLE_LEGACY_FORCE=1 must be set on kernel command
line. The meson option 'default-hierarchy=' is also deprecated, i.e.
only cgroup v2 ('unified' hierarchy) can be selected as build-time
default.
* Previously, systemd-networkd did not explicitly remove any bridge
VLAN IDs assigned on bridge master and ports. Since version 256, if a
.network file for an interface has at least one valid setting in the
[BridgeVLAN] section, then all assigned VLAN IDs on the interface
that are not configured in the .network file are removed.
* systemd-gpt-auto-generator will stop generating units for ESP or
XBOOTLDR partitions if it finds mount entries for or below the /boot/
or /efi/ hierarchies in /etc/fstab. This is to prevent the generator
from interfering with systems where the ESP is explicitly configured
to be mounted at some path, for example /boot/efi/ (this type of
setup is obsolete, but still commonly found).
* The behavior of systemd-sleep and systemd-homed has been updated to
freeze user sessions when entering the various sleep modes or when
locking a homed-managed home area. This is known to cause issues with
the proprietary NVIDIA drivers. Packagers of the NVIDIA proprietary
drivers may want to add drop-in configuration files that set
SYSTEMD_SLEEP_FREEZE_USER_SESSION=false for systemd-suspend.service
and related services, and SYSTEMD_HOME_LOCK_FREEZE_SESSION=false for
systemd-homed.service.
* systemd-tmpfiles and systemd-sysusers, when given a relative
configuration file path (with at least one directory separator '/'),
will open the file directly, instead of searching for the given
partial path in the standard locations. The old mode wasn't useful
because tmpfiles.d/ and sysusers.d/ configuration has a flat
structure with no subdirectories under the standard locations and
this change makes it easier to work with local files with those
tools.
* systemd-tmpfiles now properly applies nested configuration to 'R' and
'D' stanzas. For example, with the combination of 'R /foo' and 'x
/foo/bar', /foo/bar will now be excluded from removal.
General Changes and New Features:
* Various programs will now attempt to load the main configuration file
from locations below /usr/lib/, /usr/local/lib/, and /run/, not just
below /etc/. For example, systemd-logind will look for
/etc/systemd/logind.conf, /run/systemd/logind.conf,
/usr/local/lib/systemd/logind.conf, and /usr/lib/systemd/logind.conf,
and use the first file that is found. This means that the search
logic for the main config file and for drop-ins is now the same.
Similarly, kernel-install will look for the config files in
/usr/lib/kernel/ and the other search locations, and now also
supports drop-ins.
systemd-udevd now supports drop-ins for udev.conf.
* A new 'systemd-vpick' binary has been added. It implements the new
vpick protocol, where a "*.v/" directory may contain multiple files
which have versions (following the UAPI version format specification)
embedded in the file name. The files are ordered by version and
the newest one is selected.
systemd-nspawn --image=/--directory=, systemd-dissect,
systemd-portabled, and the RootDirectory=, RootImage=,
ExtensionImages=, and ExtensionDirectories= settings for units now
support the vpick protocol and allow the latest version to be
selected automatically if a "*.v/" directory is specified as the
source.
* Encrypted service credentials can now be made accessible to
unprivileged users. systemd-creds gained new options --user/--uid=
for encrypting/decrypting a credential for a specific user.
* New
Re: [systemd-devel] Fastest way to dump last X Mo of logs from the journal ?
Le jeu. 25 avr. 2024 à 08:38, Lennart Poettering a écrit : > > On Do, 25.04.24 12:49, Andy Pieters (syst...@andypieters.me.uk) wrote: > > > On Thu, 25 Apr 2024 at 12:48, Lennart Poettering > > wrote: > > > > > On Mi, 24.04.24 14:48, Etienne Champetier (champetier.etie...@gmail.com) > > > wrote: > > > > > > > > > what is "last X Mo" supposed to mean? is "mo" supposed to mean months? > > > thus: show logs from a given number of most recent months? if so, just > > > use: > > > > > > megabytes (mega octets in French) > > oh, wow. weird. My bad, yes I meant MB/megabytes > > megabytes of what though? of formatted text? or of a journal file on disk? > > such a weird request... that would be formatted text, even if not the most efficient this is what is in an sos report today. 'sos report' generates an archive with as much information as possible to give to your support team / dev team, you want as much log as possible but by default you need a reasonable size limit so that you don't fill up your ticketing system. The size limit doesn't need to be extremely precise. Etienne > Lennart > > -- > Lennart Poettering, Berlin
Re: [systemd-devel] Prerequisites for systemd.volatile=yes
Hi All, Any inputs on this? -- Shedi On Mon, Apr 15, 2024 at 7:15 PM Shreenidhi Shedi < shreenidhi.sh...@broadcom.com> wrote: > Hi All, > > I'm trying to use volatile root feature for the first time. > > This is my /etc/fstab: > ``` > #system mnt-pt type options dump fsck > PARTUUID=ad7ab716-2c0a-4dbe-9a28-06dc8bd0383b / ext4 > defaults,barrier,noatime,data=ordered 1 1 > ``` > > And systemd grub configs are: > systemd_cmdline=net.ifnames=0 plymouth.enable=0 > systemd.unified_cgroup_hierarchy=yes systemd.volatile=yes > > Finally, kernel command is: > BOOT_IMAGE=/vmlinuz-6.1.83-1.ph5 > root=PARTUUID=ad7ab716-2c0a-4dbe-9a28-06dc8bd0383b init=/lib/systemd/systemd > ro loglevel=3 quiet net.ifnames=0 plymouth.enable=0 > systemd.unified_cgroup_hierarchy=yes systemd.volatile=yes > > And I regenerated initrd using `mkinitrd` > > But when I rebooted my vm, it is going to emergency shell and shows > /run/initramfs/rdsosreport.txt and I'm not able to get into emergency shell > either, it just keeps looping in press Ctrl-D or enter root password prompt > and entering root password or pressing Ctrl-D just prompts the same thing > again. > > Can someone assist me on what are the prerequisites for enabling volatile > root? > > - Kernel configs to be enabled > - File system types supported > - Kernel command line args needed > > If someone can provide a step by step procedure on how to see this feature > in action, it would really help. > > -- > Shedi >
Re: [systemd-devel] Fastest way to dump last X Mo of logs from the journal ?
On Do, 25.04.24 12:49, Andy Pieters (syst...@andypieters.me.uk) wrote: > On Thu, 25 Apr 2024 at 12:48, Lennart Poettering > wrote: > > > On Mi, 24.04.24 14:48, Etienne Champetier (champetier.etie...@gmail.com) > > wrote: > > > > > > what is "last X Mo" supposed to mean? is "mo" supposed to mean months? > > thus: show logs from a given number of most recent months? if so, just > > use: > > > > megabytes (mega octets in French) oh, wow. weird. megabytes of what though? of formatted text? or of a journal file on disk? such a weird request... Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Fastest way to dump last X Mo of logs from the journal ?
On Thu, 25 Apr 2024 at 12:48, Lennart Poettering wrote: > On Mi, 24.04.24 14:48, Etienne Champetier (champetier.etie...@gmail.com) > wrote: > > > what is "last X Mo" supposed to mean? is "mo" supposed to mean months? > thus: show logs from a given number of most recent months? if so, just > use: > > megabytes (mega octets in French)
Re: [systemd-devel] Fastest way to dump last X Mo of logs from the journal ?
On Mi, 24.04.24 14:48, Etienne Champetier (champetier.etie...@gmail.com) wrote: > Hi all, > > sos report includes the last X Mo of logs, sometimes filtered, > sometimes not what is "last X Mo" supposed to mean? is "mo" supposed to mean months? thus: show logs from a given number of most recent months? if so, just use: journalctl --since=-3month Lennart -- Lennart Poettering, Berlin
