I have windows installed, gentoo installed.
I had previously installed Kinoite and then windows and gentoo, due to which I didn’t face any issue… Kinoite fully monopolized on the SSD and later repartitioning was done for other OSes.
Later I deleted Kinoite as I needed space for an experimental install of gentoo with a alternate libc, init, login-daemon, etc… (namely musl, 66, turnstile, acpid, seatd and much more…)
Now I want Kinoite (OR the new COSMIC-atomic) back, but I can’t delete windows or Gentoo. I can back /efi and /boot up, but not the OS installations.
Does Anaconda support this? Can I install Kinoite/COSMIC-atomic alongside my other distros?
As I have already said, I can back up /efi/boot and all.
Some footnotes:
I will use systemd-boot from gentoo, leaving GRUB as stub. BLS permits that; I’m fine with it.
I will be bootc to the extent possible, over rpm-ostree
However, I do want nvme-cli, distrobox, btrfs-assistant, and iwd installed. I’m fine with a toolbx for the former three, but the latter…
Is there a way with bootc? sysext won’t work because this Wi-Fi daemon needs to start earlier than the sysext setup daemon.
I also don’t want to maintain my own sub-distro for such trivial changes.
Personally, I would suggest installing Windows and Fedora Kinoite (or any other Fedora Atomic Desktop system) on separate physical drives and choosing which one to boot from from the computer’s BIOS.
The systemd system extensions can be used with both Fedora Bootable Container (bootc) systems and classic ostree/rpm-ostree systems. Personally, I haven’t tested this particular sysext, but I can if necessary. Although it’s still experimental, I think it’s worth a try. For instructions on how to test it, see iwd | extensions.fcos.fr.
You don’t need to maintain your own (sub)distribution to use Fedora Atomic Desktop Bootable Containers. With a relatively simple Containerfile, you can locally build a derived container image. Then, if a change is needed, you can edit the Containerfile, rebuild the image, and update the system.
I need fedora on the SSD, and windows is unusably slow on the HDD…
My /home is on the HDD, via a bcache device…
So I don’t have a choice here…
AND I can’t frequently go to BIOS, it is complicated key combination; I’d rather use systemd-boot.
I know that a transition from the latter to the former is in progress, but already there is a distinction between them in usage?
“Classic” rpm-ostree will soon be phased out I know, else it’s layering capabilities was sufficient…
But aren’t sysexts started much later than required?
AND do they update automatically like regular packages?
If I build the locally derived image, will it automatically update to upstream versions of the base image? As if I haven’t done any change at all? Like how rpm-ostree handles this?
I really feel that rpm-ostree was great, just use container-native images underneath it… Rather than reinventing it with bootc which feels omplicated… This is just my opinion…
If you’ve done the necessary research and are confident that you can overcome any issues you might encounter, it’s probably worth a try.
I’m not sure I fully understand this question, but in terms of using sysexts, there should be no difference between Fedora Bootable Container (bootc) systems and classic ostree/rpm-ostree systems.
At least as far as I am aware, rpm-ostree is not going away anytime soon and will continue to coexist with bootc for the foreseeable future.
As I mentioned before, since it’s available and documented, it’s probably worth at least trying. If it doesn’t work as expected, file an issue so we can try to reproduce it. You can find the link to instructions on how to install and update syxexts in my previous post.
Actually, if you don’t want to make any changes to the base image, you won’t need to build a derived container image to rebase/switch to a Fedora Atomic bootable container. Upgrades should then be performed using the bootc upgrade command.
rpm-ostreeIS great and as you may already know, it has container native capabilities. Currently, bootc is a rather simple tool which shares a lot of the same underlying code from the ostree project.
$(bootctl -x)/grub2/grub.cfg only concerns GRUB itself, the boot entries as per the UAPI BLS. systemd-boot supports BLS layout, infact even before GRUB.
$(bootctl -p)/loader/loader.conf is it’s config file, which is well-documented, and declarative. Unlike using $(bootctl -x)/grub2/user.cfg.
[PS $(bootctl -p) is /efi or /boot/efi depending on when system was installed]
So infact systemd-boot is the better bootloader than GRUB. More suited for immutable distros.
As for testing,
Since I installed gentoo alongside until I deleted Kinoite, the last time I previously used it, that’s exactly how I used it. No issues.
What is the difference between “bootc” systems and “classic” rpm-ostree systems? Aren’t both present in any given system right now?
Oh! Great… I’ll just use rpm-ostree install then and avoid bothering with bootc and Containerfiles and all…
Problem solved (almost)…
The post is highly informative, thanks.
BUT, I need automatic updates… I could help with it except that IDK SELinux…
But what’s it’s purpose when RPMs already exist? bootc I guess…
I don’t want any changes… JUST I want iwd package to be installed… AND maybe NetworkManager config snippets if supported in /usr/lib/wherever/else to use iwd.
AND distrobox installed.
Why bootc then?
What is it trying to solve over rpm-ostree+ostree?
What’s it purpose?
I really think that ostree supports everything needed for container-native desktop booting, etc.. etc.. and rpm-ostree on it is really great. sysext could be used when needed, it has it’s own great uses…
I don’t understand the need for reinventing half of ostree and rpm-ostree, and using ostree anyways for the remaining half… or even reimplementing the same concept over and over again…
What was it’s issue? RPMs only? rpm-ostree usroverlay solved that already.
Container-native needed? ostree already supports that.
What else? Rust rewrite? IDK