Migrating to Cachy from Endeavour

Issues & Assistance
1

Hello. I’ve been using Arch-based EndeavourOS for 5 years now as an introduction to rolling-based distributions. I’m an IT professional and have used and installed various flavors of UNIX and Linux over the past 24 years. I’d consider myself an advanced Linux user.

For the past couple of years I’ve used the lqx and zen kernels for gaming and audio programs. While I value stability, I like to make incremental improvements that squeeze more performance from my hardware.

A year ago I came across CachyOS and have kept it in the back of my mind to try out. From what I read in the Discord and here in the forums it seems to be fairly stable and performant.

I used the ld-linux-x86-64.so.2 command confirming my hardware is compatible. I understand from the CachyOS wiki the simplest way to start is adding the repositories and using the custom kernels and schedulers.

But what about other packages? Is it safe to let the other packages be updated over time from the CachyOS repositories? Should I re-install or update my existing packages at once? Or worst case, do a clean install which I’d rather prefer not if possible because I have a good setup of dracut, f2fs, and systemd-boot working.

I know there will be left over EndeavourOS packages that may not be compatible or are for themes and conveniences. I’m willing to manually uninstall those as necessary. I don’t use a heavy Desktop Environment, just running BSPWM with X11 from startx.

I saw the warning about using a forked pacman. Could I keep using the version from ArchLinux for the time being, or are there significant changes required for a replacement?

I thought to ask before potentially creating a mess that would be non-trivial to revert.

2

Hi,

Actually, you need to first add the repository, see here in the wiki:

The script will automatically detect the supported cpu and will add then the correct repository to it.

But what about other packages? Is it safe to let the other packages be updated over time from the CachyOS repositories?

Mostly all packages are with a decimal higher pkgrel build. This means, that these packages get automatically updated as soon you add the repository.

Should I re-install or update my existing packages at once? Or worst case, do a clean install which I’d rather prefer not if possible because I have a good setup of dracut , f2fs , and systemd-boot working.

This should be not required

I know there will be left over EndeavourOS packages that may not be compatible or are for themes and conveniences. I’m willing to manually uninstall those as necessary. I don’t use a heavy Desktop Environment, just running BSPWM with X11 from startx.

You can keep the EOS packages, this is also not a problem. The only problematic thing I see, is that we are shipping nvidia configuration via the “cachyos-settings” package, but im not sure how EOS does configure it or equal.

I saw the warning about using a forked pacman . Could I keep using the version from ArchLinux for the time being, or are there significant changes required for a replacement?

Yes, we are using an own pacman, since a bunch of requests got rejected in upstream and we got forced to using this. The main important thing, is that we have an architecture check, for x86-64-v2, v3 and v4. This is required to use the cachyos repository.

I thought to ask before potentially creating a mess that would be non-trivial to revert.

All changes can be reverted, also.

3

Thank you for the reply. I have some responses and follow-up questions.

Thanks. I chose “Option 2: Manual Installation”. I make use of a lot of IgnorePkg to monitor updates of certain packages that I didn’t want to possibly loose.

Which of my questions were you answering? For package reinstalls or doing a clean install?

EndeavourOS has a driver installer, nvidia-inst script that checks and installs driver versions, lets you use the open versus closed drivers, and even offers to setup prime and other things.

Here are the NVIDIA packages I currently have on my system:

$ yay -Qs nvidia | grep -E '^local' | grep nvidia
local/lib32-nvidia-utils 550.78-2
local/nvidia-dkms 550.78-1
local/nvidia-hook 1.5-2
local/nvidia-inst 24-1
local/nvidia-prime 1.0-4
local/nvidia-prime-rtd3pm 1.1-1
local/nvidia-settings 550.78-1
local/nvidia-utils 550.78-1
local/opencl-nvidia 550.78-1

No issues with 6.9.3 kernels for my NUC11 with a RTX 2048.

After fixing repository order, packages that would be updated show up with a “yay -Syu”. Seems that ArchLinux pacman is able to see updates though from v2, v3, and v4 without issue.

I’ll tackle this more tomorrow.

4

Thanks. I chose “Option 2: Manual Installation”. I make use of a lot of IgnorePkg to monitor updates of certain packages that I didn’t want to possibly loose.

Yes, the IgnorePKG array is independent of the script. The script just checks, what is supported and then will install the correct pacman and mirrorlist

Which of my questions were you answering? For package reinstalls or doing a clean install?

That a reinstall is not required

EndeavourOS has a driver installer, nvidia-inst script that checks and installs driver versions, lets you use the open versus closed drivers, and even offers to setup prime and other things.

Yes, we are handling this via our hardware detection. I just mean, if it generates any configuration files for the module (e.g, enabling drm.modeset and fbdev, setup NVReg options and co)
You can find the configuration done by cachyos-settings here:

Be aware, that we are maintaining our own nvidia driver stack and we are currently already on the 555 BETA.

After fixing repository order, packages that would be updated show up with a “yay -Syu”. Seems that ArchLinux pacman is able to see updates though from v2, v3, and v4 without issue.
I’ll tackle this more tomorrow.

Yes, the updates will come automatically, as long our pacman is installed. Maybe you will face an issue, if youre installing a package with the CARCH=x86_64_v3/v4 set.
This is currently mainly only used by the cachyos-v3/cachyos-v4 repository, where the custom kernel and custom packages handled.

In the future, we will roll out to all packages this CARCH check, to make it more safe. We are experimenting currently with our implementation for this, for our new optimized repository.

1 Like