Hello there everyone!
I’m not currently using CachyOS but I plan to move from my current installation into it in a near future. I, however, have some questions, that haven’t been answered in wiki, so decided to ask here
I wonder, why CachyOS defaults to systemd-boot instead of grub and uses the btrfs as default fs at the same time. systemd-boot doesn’t support loading from snapshots, so how do you handle it? Personally, that’s the only thing that holds me from trying out the systemd-boot. In my current installation, something is breaking every once in three months and I have to boot from snapshot, so it’s kinda essential IMO.
I would also like to switch from btrfs to bcachefs in the future, but again – lack of booting from snapshot in systmd-boot makes it unusable. Also, I don’t think there’s a software, that’s capable of automatic creation of snapshots for bcachefs partitions rn (at least timeshift doesnt support it yet), but that’s another topic.
Another question that I have is related to a completely different topic: CachyOS kernel. How does this perform in comparison with xanmod kernel? AFAIK both serve kinda same purpose to be used with high-end hardware, but I don’t really know the difference between them, except that CachyOS has custom schedulers enabled. I’ve been using xanmod kernel for years, so I wonder if I should switch to cachyos one and why…
Basically, what you are saying that the only viable bootloader with btrfs is grub?
Grub is pretty much outdated, badly maintained, no LUKS2 support and limited filesystem support. Also it is pretty slow.
There is a reason, why we do give users so many different bootloader, desktop environments and filesystems - they can choose on their own.
Just use whatever you want and what you like to use.
How does this perform in comparison with xanmod kernel?
I dont know, if there are exact benchmarks out, but looking on Xanmods 6.10 kernel contains:
BBR3 Patches
Xanmod specific patches
Some other net stuff
You can find here whats in our base patchset:
We are generally really much in contact with Developers and companies to provide some more pretesting for them, as soon patches has been settled.
Also, we are working together with the sched-ext Maintainers (META, Google, … ) as well as giving them a Development Platform.
Just test it, what fits to you. i really do not want a “X” is better then “Y”, People just use what they prefer.
Also, they are following different attempts, see above.
Thank you for your fast and descriptive response! Wanted to reach you out in phoronix thread about cachyos, but decided it’d be better to do on official forum
Grub is pretty much outdated, badly maintained, no LUKS2 support and limited filesystem support. Also it is pretty slow.
I completely agree with you in regards of grub’s problems, and I’m not saying in any means, that having the choice is bad. I just had some personal interest why systemd-boot was selected as default choice, since, as I said, it lacks essential feature to restore from bad situations. Let’s say some update broke something, I can’t get into my desktop manager and even tty doesnt work. How would user restore from snapshot in such cases? Only by booting from live cd flash drive?
I do agree, that systemd-boot is much more simplistic and performant tool, but I just don’t think it should be default for btrfs…
i really do not want a “X” is better then “Y”, People just use what they prefer.
That’s reasonable. I guess some benchmarking is needed indeed. I’m not saying that “X” kernel is better than “Y”, I’m interested in more detailed “X kernel is better than Y in Z kind of tasks” stuff
Let’s say some update broke something, I can’t get into my desktop manager and even tty doesnt work. How would user restore from snapshot in such cases? Only by booting from live cd flash drive?
There is a “cachy-chroot” on the ISO, which guides the user really easy through the mounting and chrooting process. Then someone does not get into tty anymore equal is generally pretty rare - this happens more often on grub tho.
I do agree, that systemd-boot is much more simplistic and performant tool, but I just don’t think it should be default for btrfs…
The user can select between 6 different filesystems. Its just the default selection. What would be the benefit of using xfs with systemd-boot? You still have no snapshots.
That’s reasonable. I guess some benchmarking is needed indeed. I’m not saying that “X” kernel is better than “Y”, I’m interested in more detailed “X kernel is better than Y in Z kind of tasks” stuff
That is mentioned above the differences. Cachy Kernel pulls in features from upstream, while xanmod is just the same over dozens of kernel versions already. It his “xanmod” patches, which does modifiy manually fair.c and rcu + BBR3 + a not working NTSync.
On the Cachy side you can see the used patches here, this are in branches.
Then someone does not get into tty anymore equal is generally pretty rare - this happens more often on grub tho.
Well, that I can agree with
The user can select between 6 different filesystems. Its just the default selection. What would be the benefit of using xfs with systemd-boot? You still have no snapshots.
Maybe at least adding a small note about it on a bootloaders wiki page is worth it? I mean, users migrating from grub and knowing nothing about systemd-boot would probably expect it to have support for snapshots of their favorite fs here too
My next linux goal is to understand btrfs, I installed it without knowing much about it. So grub is the only bootloader that can boot snapshots?
My explicit goal was to be able to boot snapshots, because it’s my work laptop and I don’t want to spend time repairing the system, when I urgently need the laptop. I had no idea that if I go with the default selection I won’t be able to use snapshots. This default selection implies that systemd-boot is compatible with one of the most important features of btrfs.
I just choose grub, because I didn’t know the others. But yeah one should look into stuff more. I just needed to choose quick what to use and I heard that you can boot snapshots and I didn’t do more research.
I understand. Just sometimes you can’t even get there then you have to go look up commands for the rescue shell or use chroot. Grub is just really convenient for situations where you quickly need the system(if itself is not the issue, only happened once for me the last 2 years). So there’s no other modern loader that can do this?
Grub is the only way to have snapshot on boot that is important in case of disaster with your pc unable to load OS.
At the moment and intersting test is made by OpenSUSE is an experimental stage using SDBOOTUTIL when user chose systemd-boot in installation, so I don’t know if it’s working 100%, you can see it here
There is an important reason to use grub not mentioned, is that if you have windows installed on the pc , its UEFI partition is only 300 MB, so if you want install linux in duaolbooting without format and reinstall windows, the only way is use Grub that can be installed on this small UEFI partition. System-boot store part of the kernel inside its partition so you need more than 1 GB UEFI partition (better 3 GB if you use several kernel as options)
Another option to get a boot from a btrfs snapshot is to use refind. It will take a lot of effort, but it is possible. Using GRUB it is much easier, but it doesn’t look as nice when booting.
Tbh the one of the reasons why i love cachyos its very flexible arch linux based distro with preformance optimizations i love how there is alot of options on here and many distros offer grub only (its annoying to work with especially with secure boot might plan to disable it once i completely wipe windows 10) and there is alot.of filesystem options as well currently using another arch based distro till the next 24.09 or 24.10 update due to a issue i have rn so yh
True but if you wanna install most distros, you need secure boot off. some cannot be signed, especially when half of the distros use grub, however cachy has a guide on it.
Refind with snapshots is problematic. I tried it and ran into issues quickly. Simple booting from snapshots is rather critical as updates can do wild things, I would not do a system update after months of not updates. Not having a simple way to restore from snapshots is surprising. Btrfs-assistant is GUI only, so it’s not straightforward to use when your system is broken.
I’ve been running btrfs as my root filesystem for about 9-10 years / Arch for about 8 years / Linux for 25 years.
If you want a super stable desktop that doesn’t break run XFCE (or XFCE + new super shiny desktop). I also usually remove the Display Manager (one less thing to go wrong) - & configure startx so I can always start a desktop from a terminal. More recently I’ve installed gdm because it plays nicely with gnome-secrets.
I’ve been running snapper & btrfs snapshots for about 4 years - & have so far booted from a snapshot zero times. When I have had a problem it was with grub needing to be reinstalled which would not be saved by a snapshot.
To improve the uptime of my system - a btrfs raid1 root with systemd-boot seems like a no brainer.
I’ve found generally snapshots are more useful for dev / testing & transferring data - & recovering accidentally deleted files. The usefulness of snapshots on root is limited (unless you are developing the system)
Snapshotting my btrfs root has just increased the wear on my Linux nvme - which does make raid1 on root attractive in my case (Linux nvme is 14% used / Windows vm nvme is 4% used)
I will be doing a bit more zfs testing (adding nvme SLOG & special device to the SSD pool + SATA stripe testing) - from what my testing has shown so far - I won’t lose much performance going from pci-passthrough => zvol with proper disk / blocksize alignment.
I was actually thinking about a full zfs system after reading a post here. zfs never leaves you with an unfixable full filesystem (btrfs has several times when used outside of root for data - it does not reserve enough free space)
Glad your experience was better than mine. I am currently running the system with btrfs partition for 6 straight years, and I had to boot from snapshots more than 10 times, that’s for sure. Shit happens, broken updates arrives, and you have no other options: it’s either quick rollback via booting by snapshot and downgrading, or chrooting with live cd, which is much more painful if you don’t have a usb flash prepared for such cases nearby and a second system to create such device.
Some problems are recoverable if you can at least reach into DM and start the tty, but sometimes DMs breaks (I had such issues with SDDM and some GTK based greeters due to gtk updates), and you can’t downgrade stuff through tty beacuse system fails to start in a loop.
[~]$ cat .xinitrc
#!/bin/bash
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
userresources=$HOME/.Xresources
usermodmap=$HOME/.Xmodmap
sysresources=/etc/X11/xinit/.Xresources
sysmodmap=/etc/X11/xinit/.Xmodmap
SESSION=${1:-xfce}
# merge in defaults and keymaps
if [ -f $sysresources ]; then
xrdb -merge $sysresources
fi
if [ -f $sysmodmap ]; then
xmodmap $sysmodmap
fi
if [ -f "$userresources" ]; then
xrdb -merge "$userresources"
fi
if [ -f "$usermodmap" ]; then
xmodmap "$usermodmap"
fi
# start some nice programs
if [ -d /etc/X11/xinit/xinitrc.d ] ; then
for f in /etc/X11/xinit/xinitrc.d/?*.sh ; do
[ -x "$f" ] && . "$f"
done
unset f
fi
get_session(){
case "$SESSION" in
awesome) exec awesome ;;
bspwm) exec bspwm-session ;;
budgie) exec budgie-desktop ;;
cinnamon) exec cinnamon-session ;;
deepin) exec startdde ;;
enlightenment) exec enlightenment_start ;;
fluxbox) exec startfluxbox ;;
gnome) exec gnome-session ;;
i3|i3wm) exec i3 --shmlog-size 0 ;;
jwm) exec jwm ;;
kde) exec startkde ;;
lxde) exec startlxde ;;
lxqt) exec lxqt-session ;;
mate) exec mate-session ;;
xfce) exec xfce4-session ;;
openbox) exec openbox-session ;;
*) exec "$SESSION" ;;
esac
}
exec $(get_session)
If gdm ever breaks I should be able to CTRL ALT F2 (or 3 / 4 / 5 / 6) - & login from another tty & startx.
I also use an AMD GPU for my Linux host (Rx 560 4GB - runs from a pcie x4 without a power connector) - although with nvidia open sourcing their drivers - this will be less needed in the future for stability.
