mkosi VS btdu

I work with a free and open-source software community called Fedora Project. I had the opportunity to moderate the talk of one of the maintainers of the Systemd suite during the annual contributor conference, Flock To Fedora 2023 where he talked about a tool named Mkosi.

For testing i prefer systemd-nspawn containers with mkosi. A neat tool for running your other fav. distro in a terminal. Works like a charm and integrates nicely in your system. Eg. logs and systemd services or CI testing.

- https://github.com/systemd/mkosi

- man:systemd-nspawn(1)

- man:machinectl(1)

you're gonna have to build this on an x86 pc. sudo dnf install arch-install-scripts bubblewrap gdisk qemu-user-static rsync systemd-container python3 -m pip install --user git+https://github.com/systemd/mkosi.git git clone https://github.com/leifliddy/asahi-fedora-usb.git cd asahi-fedora-usb

There's also mkosi: https://github.com/systemd/mkosi. This one outputs an iso or similar image file and supports many base distributions.

[1] https://github.com/systemd/mkosi/issues/376

System's mkosi is worth checking out too: https://github.com/systemd/mkosi I don't think it generates docker/OCI images directly, but it definitely can generate a tarball of the final image contents and then crane of a similar tool could package it up into an appropriate image. For just docker usage it's probably overkill, the main advantage would be it can build other image types like adding a kernel and init to be a fully bootable iso of VM image.

Constellation ensures that all K8s nodes run on AMD-based Confidential VMs (CVMs). CVMs are strongly isolated from the host and remain encrypted in memory at runtime. Constellation also ensures that all nodes run the same minimal mkosi-based node image.

At first glance I thought your project is a frontend for mkosi but then I saw that you support non-systemd targets too. Mentioning it here because it may be relevant to other users/developers.

Hello. I have a 2 TB nvme mounted as a subvol that contains dockervols. I recently noticed this discrepancy df -h | grep nvme0n1p1 /dev/nvme0n1p1 1.9T 1.3T 569G 70% /data vs. sudo du -h -d 0 /data 1.1T /data I tried using the btdu tool but I am not sure if I had it installed correctly as it didn't show the output like the examples shown on the github (https://github.com/CyberShadow/btdu)

btdu fastest and easiest tool to analyze space usage in compressed btrfs with lots of snapshots (especially in expert mode)

It doesn't seem BTRFS's fault. You could run btdu on your subvolumes to understand what's going on.

However, honestly, the best way to get a quick overview of where all your space is being used is btdu.

If you want to diagnose where you think there may be space used up that you don't quite understand, then btrfs fi du and third party tools btdu and compsize are useful.

And btdu to get an overall impressions of where space is being used if the above isn't useful enough.