Hello,i’m new to the forum,if the methods used aren’t compliant to the rules.feel free to instruct me more on the issue .
I’d like to report a couple of things(questions and suggestions),not bugs,
about Leap 16.1 RC Immutable installation:
Default installation with a separate /var
I don’t know if it’s a “not correct use” of btrfs or how opensuse views it but i think an option to remove the separate /var should be there for desktop users.
i didn’t look into the partitioning much, the first time i installed it, i found an home that was too small to transfer files(25GB on my 512GB rated nvme),i reinstalled it with the separate /var removed and i think it’s not a bad default for desktop users.
The installation process with a workstation laptop and hybrid graphics had issues but not if i used the “check installation media” option,that worked perfectly and started the installer without issues.
I don’t know if there’s an issue with docs or they need to be updated,i’m talking about the nvidia driver section:
does leap 16.1 RC immutable work as the leap micro section or leap section?,is the provided openSUSE-repos-Leap-NVIDIA package the same as leap 16.1/16.0 not immutable?
Leap 16.1 in Immutable mode is replacing Leap Micro. There won’t be a Leap Micro 6.3 or 7.0; Leap Immutable is the way forward for container and virtual machine hosts, edge devices and anyone who prefers atomic updates with easy rollback.
An immutable setup requires a separate /var, likewise best make /boot/efi 1GB-2GB as well at some point it will move to systemd-boot. The other option is a XLDRBOOT partition to extend.
Make sure you only run the likes of flatpaks and/or distrobox for applications.
Thanks,yes,i used to run micro os/micro os dekstop/aeon/leap micro aside my main Leap installation and having a stable immutable desktop is perfect for my usage.
About the packages i’ll use the same approach as the other times but i have a question: i installed the drivers the standard leap way but using transactional-update,everything works but the official docs,which has leap micro use the micro os repo instead of the current built in we have https://en.opensuse.org/SDB:NVIDIA_drivers
I thought systemdboot was a tumbleweed only option,i read the article about XLDRBOOT and systemdboot when it came out but i thought leap would stay on grub for some time.
Exactly, installing a package does not necessarily require a reboot, just using the transactional-update apply option is enough to move to the new snapshot if installing leaf packages… transactional-update run zypper ps -s should show(?).
AFAIK the transactional update is built around Btrfs snapshots and snapper (or its infrastructure that comes with libsnapper): A new snapshot is created, updates are installed into that snapshot instead of the currently running one, and if everything worked, it needs to reboot into that new snapshot which then becomes the current one.
At first glance, this sounds like it could be hammered into shape to work with Myrlyn. But when you think about it some more, some questions and weird situations come to mind:
The workflow would be about this:
Start Myrlyn
Select updates / packages to install / packages to remove
Hit “Accept”
Create a new snapshot
Tell libzypp to install into this new snapshot
Let libzypp execute the transaction
In the last step, show the summary
Commit the new snapshot: Mark it as the current one
Reboot
What if anything goes wrong between “Accept” and “Commit”?
I guess the reboot would be mandatory (forced). If not, what would happen if the user chooses to do it all again and install / update more packages? Would a not-yet-committed snapshot need to be automatically picked up by a new Myrlyn run to continue in that one? That sounds nightmarish both in terms of the UI and the implementation.
I never used transactional update. I seem to recall reading about it (or was it just something similar?) where you could issue a command to “unlock” the system, i.e. toggle the root filesystem from read-only to read-write, and then use zypper or rpm commands to modify things, and finally change it back to read-only.
In that case, you could of course also use Myrlyn instead of zypper or rpm commands. But it’s not really an atomic transaction anymore.
But with an added step with a new snapshot that would be used in the modification phase, it might be.
/var contains - among other things - all kinds of system logs, and also caches. You really don’t want them CoW (copy on write) because that would mean every new line in the logs would implicitly create new copy of that disk block due to CoW. This is the main reason for a separate subvolume for /var, and why it’s set to noCoW.
@shundhammer No, there are many cases where a reboot is not needed, say for example I install fastfetch or inxi, once installed, transactional-update apply will suffice, no reboot necessary…
There is shell, but that use is heavily discouraged and only for debug, use transactional-update run zypper.... or any other command.
if the space it’s split in half for both of them and that’s the case why half of the space available on the default install?,does the /var as explained by @shundhammer requires half the available space for it?
Btrfs used and free space accounting is a big mess.
With CoW (copy on write) as the foundation for snapshots, it doesn’t fit into the pattern of traditional Linux filesystems: When a file is modified, and CoW needs to store the old version and the new version, both need to be stored somewhere. Btrfs does this very efficiently by only storing the blocks that are different. But you can imagine that this can account for a lot if a file is written lots of times. Multiply this with the number of files, and disk space can fill up quickly.
So, if you have the same files in different versions (at least their block diffs), how much disk space is used, and how much is still free? This is not easy to answer; it depends on what you are interested in. But syscalls such as statfs() can only return one set of numbers; and file utilities such as free or du use those syscalls.
This is why Btrfs comes with its own set of utilities that return several different numbers, and it reports bogus numbers to statfs(); and this is what you see with df and du.
I wrote this up some years ago here:
Bottom line: You need to use the dedicated Btrfs utilities to get the real information, and you need to make sure that old snapshots are cleaned up before they fill your disk completely, and you might also want to use btrfs balance to reclaim disk space.
.
