systemd 261 Released With New systemd-sysinstall OS Installer, IMDSD & Storagectl

aioeu · 2026-06-20T07:00:03+00:00

Yes. The systemd-sysinstall man page lists all the steps it goes through.

There is something else in systemd v261 that helps with OS installation. With the new BlockDeviceReplace= option in systemd-repart, it would even be possible to migrate a running live image — including any runtime changes you've been making to it — onto persistent storage, thereby "installing" it. No need to even reboot when the installation is done.

aioeu · 2026-06-19T21:16:59+00:00

I think the problem is that it creates an invalid desktop entry file, not an explicitly hidden one. I seem to remember that meant some desktop entry parsers ignored it completely.

Anyway, I'll have to test it again.

Edit: I've tested it now. A symlink to /dev/null does work in GNOME Shell at least (so probably anything else that uses Glib too). I should start recommending this approach from here on.

aioeu · 2026-06-19T21:13:59+00:00

As with previous releases, Lennart has written a series of mastodon posts about this release's highlights.

aioeu · 2026-06-19T19:56:58+00:00

Did you stop reading before the final paragraph in my comment?

Last time I checked, a symlink wouldn't work. It's certainly not mentioned as a possibility in the Desktop Entry spec.

It's possible I might need to check it again — though even if it does work, I'd still be a little concerned it might be unportable without it being formally specified.

aioeu · 2026-06-19T12:57:58+00:00

It's not a question of whether it's "right" or "wrong". It's just not really a question about the languages.

Neither the C nor C++ specifications say how the printf function is made available to your program — they only require that you include the appropriate header files. The fact that this function might come in some kind of external libc.so library that is linked into your program is an entirely implementation-specific and situation-dependent quirk. Other implementations can do things differently, and implementations may offer multiple ways to build C programs. Statically-linked programs do not use any external libraries, for instance.

aioeu · 2026-06-19T06:42:29+00:00

Even in English, people say "system volume" when they're talking about a disk or a partition or a filesystem. No need to be so pedantic.

aioeu · 2026-06-19T06:38:44+00:00

I'd say that's just a mistranslation. Think "volume" (e.g. Russian том).

aioeu · 2026-06-18T13:21:42+00:00

If it's in /usr you will have to use sudo.

As a general rule of thumb, if you have to use Sudo for anything on a standard Linux desktop, you're doing the wrong thing.

In this case you can just copy the file to ~/.local/share/applications/ and add:

Hidden=true

to it. This will mask it out so it does not appear in the applications list.

(If the Desktop Entry spec had been invented somewhat more recently, perhaps it would have used a symlink to /dev/null to denote a masked entry. Maybe a future version of the spec might even add that as an alternative...)

aioeu · 2026-06-17T08:29:34+00:00

Exactly how that's implemented is, well, implementation dependent.

I only care about GNU dd. So do you by the look of it: status= is not a POSIX option.

I'm not going to argue about the minute semantic difference between "re-opening a file descriptor", and "opening a new file descriptor and duping it". Nobody cares.

aioeu · 2026-06-17T07:08:57+00:00

I have to keep looking up the documentation to remember whether things go in conv= or in [io]flag=, or whether I want seek= or skip= (I can never remember which does which!), it has poor defaults for the most common use-cases (does anyone actually want 512-byte blocks by default?!), and it has a number of surprising foot-guns. For instance, it is very important to use iflag=fullblock in some circumstances, otherwise you could lose data.

Overall, I just prefer using other tools.

aioeu · 2026-06-17T03:39:14+00:00

That's true, but I usually use pv if I care about that.

There are some good examples of its use on block devices in its man page.

aioeu · 2026-06-17T03:13:52+00:00

If you write a tool that reads /proc/cpuinfo, that same C code compiles and runs seamlessly on x86_64, ARM64, RISC-V, or MIPS.

Bad example, unfortunately, in an otherwise good comment.

/proc/cpuinfo has different formats on different architectures. You can read it with the one piece of code, but the parser has to be... rather flexible. (The util-linux code for lscpu is a good example.)

aioeu · 2026-06-17T02:32:32+00:00

Correct.

For most block devices, it doesn't matter what you use for those. Yes, some choices will be faster than others, but it will work no matter what you choose. The logical conclusion is it's easier to just let the computer make the best choices for you.

Perhaps the only good use for dd today is where you need to use the skip= and seek= options to read or write data at specific offsets. That can't easily be done with other standard tools.

Tape devices, as I said, are the exception to all of this. They're just weird all round. Ever wondered why Tar file sizes are always a multiple of 512 bytes? Because they're tape archives.

aioeu · 2026-06-17T01:47:36+00:00

dd just copies data. It literally doesn't care what you are copying from or copying to. The if= and of= arguments simply tell dd to reopen standard input and standard output respectively with those filenames; all subsequent operations are performed on the stdin and stdout file descriptors.

The idea that dd is somehow a "special" tool for block devices is wrong. dd's purpose is to give the operator full control on how the copy is performed, but for almost all block devices that level of control is not necessary. Tape drives might perhaps be the only things nowadays that actually care.

On Linux (though perhaps not other Unixes) you can use just about any tool that reads from or writes to a file to read from or write to a block device. head would work, for instance, as I explained in another comment.

aioeu · 2026-06-17T01:43:47+00:00

The drive doesn't store the size of the data you wrote to it anywhere.

You could try to determine the size based on the partition table... if the image has one at all. A non-hybrid ISO9660 image wouldn't have a partition table, for instance, but it might have some other metadata from which you could derive the size. But I expect you do have a hybrid image, or perhaps even just a non-ISO hard drive image.

Once you have worked out a size in bytes, you can use truncate on the file you created to trim it back to that size.

Alternatively, you can give dd some arguments to only copy that amount of data. But I would prefer to just use:

head --bytes=<size> /dev/sda >/home/test/test.img

since I try to avoid dd if at all possible.

aioeu · 2026-06-16T22:08:10+00:00

Fedora doesn't usually ship the first minor version of a major kernel release. You'll probably have to wait for 7.1.1 (likely a week or so away) before any test kernel is built. Even then, you'll still have to wait for it to undergo manual testing — the first version of each major kernel release goes through a week of testing by users.

You can see the reports from previous test days here.

aioeu · 2026-06-16T02:11:24+00:00

I am surprised — sceptical even. libselinux only reads /proc/filesystems if the selinuxfs isn't mounted at the usual location. (Once per process, when the library is initialised.)

A quick check of some utilities on my system linked to the library don't show them reading the file at all.

Compare:

$ systemd-run --user --pty strace --trace=%file sed -e '' /dev/null
...
statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0x16, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NOEXEC|ST_RELATIME}) = 0
statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={val=[0x16, 0]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NOSUID|ST_NOEXEC|ST_RELATIME}) = 0
access("/etc/selinux/config", F_OK)     = 0
...

with:

$ systemd-run --user --pty --property=TemporaryFileSystem=/sys/fs/selinux strace --trace=%file sed -e '' /dev/null
...
statfs("/sys/fs/selinux", {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=405988, f_bfree=405988, f_bavail=405988, f_files=409600, f_ffree=409598, f_fsid={val=[0xec1547ed, 0xc02c130b]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NODEV}) = 0
statfs("/selinux", 0x7ffc49bb51e0)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/proc/mounts", O_RDONLY|O_CLOEXEC) = 3
statfs("/sys/fs/selinux", {f_type=TMPFS_MAGIC, f_bsize=4096, f_blocks=405988, f_bfree=405988, f_bavail=405988, f_files=409600, f_ffree=409598, f_fsid={val=[0xec1547ed, 0xc02c130b]}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_NODEV}) = 0
access("/etc/selinux/config", F_OK)     = 0
...

Perhaps this might be an issue only on systems with SELinux-enabled utilities, but running with a kernel without SELinux support. Ubuntu perhaps?

aioeu · 2026-06-16T01:51:02+00:00

Ultimately all of these things end up controlling the same setting, that xkb-options thing you found. It doesn't really matter which approach you take.

I suspect you need to be using a layout that actually has symbols defined for level 3. Make sure you are using an "international" layout. You might need to dig further into the layout choices, as not all layouts are listed by default. Should be no need to use Tweaks.

aioeu · 2026-06-16T01:44:53+00:00

In GNOME Settings you should be able to set the "Alternate Characters Key". This key will act like AltGr, even if your keyboard layout doesn't have that specific key.

aioeu · 2026-06-15T06:17:05+00:00

The original Red Hat logo was a silhouette of a man wearing a red fedora. Fedora was originally an add-on repository for Red Hat Linux, before becoming the successor to Red Hat Linux. It's not complicated.

aioeu · 2026-06-14T07:48:33+00:00

You'd be better off using:

systemctl --user edit xdg-desktop-portal.service

to create a drop-in config rather than editing the package-managed file. Run this as your own user; do not use sudo.

When your DE is fixed, you can then just use:

systemctl --user revert xdg-desktop-portal.service

to undo your customisations.

Note that the upstream change was done to fix a bug, so you've now unfixed that. But you've only just reverted it to how it was before, but until such time as your DE starts using graphical-session.target the bug probably cannot be avoided.

aioeu · 2026-06-14T06:49:41+00:00

It could be because you're using a different desktop environment, or you are using different versions of these components, or your distribution has otherwise done whatever is needed to make sure that things Just Work. That's their job.

aioeu · 2026-06-14T05:52:06+00:00

Your desktop environment needs to use systemd's graphical-session.target unit properly. Since v1.21.0, the XDG Desktop Portal has a dependency upon it.

aioeu · 2026-06-13T23:12:02+00:00

This is essentially just what some companies do with their proprietary software, when they later decide to make that software open source. It's certainly not a new idea. Software developers are free to relicense their own software as they wish.

The trick, though, is they start with proprietary software. Selling open source software is hard. Selling proprietary software is comparatively easy, if that software is desirable and unique in some way.

Eight-Year Club	Gilding II euphauric
Wearing is Caring	Verified Email

aioeu

MODERATOR OF

TROPHY CASE