@agowa338 no, why would it? it's an in-memory file system, it does not persist across reboots or between systems. The btrfs on it is freshly formatted after the zram device is allocated.
@agowa338 btrfs device replacement is a btrfs native feature. It knows how to invalidate the old device to avoid identifier clashes. And the old device only existed in RAM anyway (i.e. backed by zram0), so once that device is destroyed there's no trace kept around that the backing device of the btrfs fs once upon a time wasn't the internal hard disk.
…to a target block device, without ever being unmounted. It uses the device replication feature of btrfs for this, so that this is reasonably robust.
How would one use that? The idea is that the USB live media carries an immutable /usr/ which when booted sets up a zram device for the rootfs, formats it as btrfs, where /usr/ is then mounted into. systemd-repart can then be used to duplicate /usr/ (and its verity + sig data) onto the target disk, and then sets up a root fs (+ encrypt it), and…
…to just boot up from your USB stick, and use it for a while in "live" mode. Then, after liking it you decide to actually want to install it on the built-in hard disk. So what if we could start the install process now, that just migrates the running OS without a reboot into the built-in hard disk. With v261 systemd will provide tooling for this: systemd-repart learned a new option BlockDeviceReplace=. If used it can "migrate" a running and mounted btrfs file system from a source block device…
…mode of operation it is typically used to stream in a /usr/ OS tree onto a suitable partition on the target disk, and then creating a new root fs on it too (either from the installer, or even better after rebooting into the freshly installed OS) That's very efficient and robust, hence seems like it's the ideal way to install an OS, no?
As it turns out one can do it even better: rebooting sucks of course. How about an installer where you do not even have to reboot? You might want…
1️⃣5️⃣ Here's the 15th post highlighting key new features of the upcoming v261 release of systemd. #systemd261 #systemd
In a previous episode of this series we already talked a lot about installing operating systems, and the new features systemd v261 brings for that. There's one more item in this area I'd like to talk about:
You know systemd-repart is that dynamic partitioner that can also be used for building disk images and as an installer for image-based operating systems. In the latter…
Sad to miss #devconf this year. If you are there do not miss to talk to my amazing co-workers @floriansnow and @annabonnie about the @fsfe and #softwarefreedom .
As someone who really likes RSS, I found this post (which I read via RSS) by @michal quite interesting:
> No more RSS :: Syntax at Amima
https://michal.sapka.pl/2026/no-more-rss/
I like the simplicity and uniformity of RSS: posts from people whose stuff I want to read, available to me automatically, without regard for whatever styling they might have applied to their site. Just text in a window.
I add and remove feeds quite regularly - as Michal says, sometimes someone's posts just don't gel enough for me so I find myself regularly skipping them.
One of the more interesting aspects of the consultation, is a question around a "duty to rescue".
The consultation says
> We have received evidence from several respondents in relation to cases in which people do not receive assistance during a medical emergency or in other dangerous circumstances: these often relate to failures to call for medical assistance or to
respond to indications of suicidal intention.
> ...
> We invite consultees’ views on the need and justifications for a bespoke offence in cases in which there has been a culpable failure to seek medical assistance or intervention and death results.
I wonder how this might apply to online posts, in which a person ideates suicide in some form. Would there be a general duty, on everyone who sees such a post, to take some form of action?
