Not bootable after update. Stuck at black screen. cachy-chroot error invalid option

Yea no, does not change and updating currently causes my boot to get stuck again.
I don’t understand, how an update that changes files can cause your system to fail and you manually have to change files too. Why?
Probably some privilege issues or something, but so fing annoying.
Other option, like with appamor, that thepackage changes and we have to manually remove one and install the other?!

I would hope someone with more experience would join in here, because I surely am out of my league. All I can say is I’m running Cachy since >8 months now and experienced such a behavior only once. But of course I don’t manually change resolve.conf etc.

@cscs ? @Steeledpick ?

Maybe there is something like initram or limine entries not being properly populated? In which case a sudo limine-mkinitcpio is needed after the upgrade .

Or maybe something about having bad hooks in mkinitcpio like here;

If you want to share your config you could do something like;

paste-cachyos /etc/mkinitcpio.conf

But it is difficult to guess without any info on how/what is failing.

Did we ever get system info or bugreport?

Probably nothing special:

I “reinstalled”/‘more like installed the new’ apparmor and it showed the “older” -git version is conflicting with the one trying to install. Now the new one is running compared to the old even so i already added “cache-loc /etc/apparmor/earlypolicy/” and could run pacman -Syu.
Maybe reboot might now work. For now i have a lot of updates. How should i go on to narrow down what might be going on in my system?
At least i now don’t have timeout set to 0 for boot menu and don’t need a live iso to change back to a snappshot that works.
Cachy or more like Arch is pretty nice, but it is still work. I should have kept everything to the basic wiki instructions with going in the direction of what i thought was a more modern way with limine.
One thing i realized, is that customizing and setting up my system can’t be recovered easily by me. Like audio settings are not 100% working but i got it to run ok. Or using a media server. I need to find a more robust system to set up my system, e.g. maybe have a set of config files possible user once that i just can copy into the correct needed paths and maybe add or uncomment them in the main config. So that i could reinstall the OS and run a set of commands (maybe via a bash script or something) without worrying about loosing my settings.
I think there where some bigger changes that could break the system and i’m not yet prepared to handle those.
Learning what and how Linux/Arch works is also not really working, when you are in a more stressed situation. I love to learn more about my system, but only part by part and i mainly also would like to “drive” it from time to time instead of learning about “its motor functions” only to fix a problem i overlooked during the hundreds of upgrades there could constantly be.

In my solution post, i will add, that trying to use a newer iso might fix some things, as this helped me solve the cachy-chroot error, but for fixing my current situation, that an update might cause my boot to get stuck again, i might first need to update part after part and filter out what causes this.
Another part to fixing my problems was first to check the bootloader, in my case limine, config and reset timeout to not be 0, as this prevented me seeing my bootmenu (obviously, but you can forget that you set it or more likely where you set it.)

The fact that we still see udev and no systemd in the mkinitcpio probably tells us that there are pacnews unhandled.

To print them all;

pacdiff -o

for a desktop/workstation focused system, make your changes as much as possible within your local user environment, the ~/.config/ or /home/ folder that way you can do an upgrade or reinstall of the system and all of your customization stay intact. Don’t modify /etc or system-wide settings unless absolutely necessary.

If you’re not doing dev work or want to do a lot of system-wide tweaks and customization, bazzite is great for just playing games, browsing internet, and word processing. It lacks a lot of the app to app intra-integration and tweaks though because uses flatpaks as the default.

I don’t know what you mean by audio settings are not working 100%

Perhaps, pick a solution comment to this thread and close it. Start a new post for the remaining outstanding issues you’ve got since this “stuck at black screen” issue is resolved. People who have knowledge and expertise in the specific outstanding issues you are having might not look in this thread since it’s titled “stuck at black screen”

Without knowing a bit more, i would be anxious that those would also get wiped hen i reinstall. I’m going to inform myself and learn more about linux path and maybe putting specific path on another hardware device (nvme). I always preferred to use my own structure for windows installs.

Not getting 5.1 sound when source is only 2.0 and overall not correctly understanding what options i have for the audio settings but nothing i will discuss further in this thread.

/etc/pacman.d/cachyos-v3-mirrorlist.pacnew
/etc/pacman.d/cachyos-v4-mirrorlist.pacnew
/etc/resolv.conf.pacnew
/etc/limine-snapper-sync.conf.pacnew
/etc/mkinitcpio.conf.pacnew
/etc/pacman.conf.pacnew
/etc/pacman.d/mirrorlist.pacnew
/etc/conf.d/wireless-regdom.pacnew

How should

be understood? I found some thread 1, a mention of arch update and another times from the same user about arch update. So i might just need to update mirrorlists and update again?

Pacnews are meant to be manually inspected and then incorporated or deleted as needed.

It would be a bit difficult to provide an overview of each of your pacnew files .. and it is dependent on the local system/needs/etc.

Though I could mention that the mirrorlist files are probably mostly unimportant due to ranking tools like rate-mirrors.

But I might guess that somewhere between mkinitcpio and limine and snapper that these unresolved pacnews might be related to your ‘i update and it breaks’ situation. Part of updates on Arch/Cachy is pacnews and local admin attention to them.

CachyOS should make this more clear in it’s documentation and getting started guides.

Part of the problem?

I don’t know if this is helpful for you. I don’t know your hardware specs (see fastfetch in terminal e. for some of them). If I understand the boot process you experience right, I had a problem with the BIOS screen displayng at all, the limine menu as well. It booted directly to cachyos logo (splash?) and then login screen. To explain it properly this might be a tldr, but I am going to anyway since this may work for you and/or others.

When I bought parts for my setup I got it all right except the cpu which is an Intel core 12900 KF which I think was at least part of my problems (I’m refering to “KF”). I have a ASUS TUF motherboard, a NVIDIA RTX 4070 GPU as well. I have a setup with three TV’s with different HDMI-cables (two of them with an adapter from HDMI to DP). The different cables refers to their version (1.x to 2.0). I don’t know which is which since they are old. However, I had to reset CMOS to be able to make changes in BIOS which was a lot of pain until I fond a solution:

  1. I swtched cables around in all posible combinations. What I do know is that the oldest tv is currently connected to the number three port from left to right.

  2. Made changes in BIOS rebar/advanced menu: BIOS/Boot configuration/Boot delay time 10 seconds) and fast boot off. Finally it worked which was a great relief!

The other problems you mentioned is beyond my knowledge since I am still a noob in the linux world. Hope this can help you and/or some poor soul struggeling with the same problem.

Its an intrinsic part of all Arch systems (EOS and even Manjaro too).

But sure Cachy could also mention it somewhere.

I thought there was at least a little blurb in the wiki but I could not find it.

Hey, had pretty much the same problem today and update broke my system, black screen, could only get in through the GRUB snapshot menu. I then spent way too long trying snapper rollback before figuring out it just doesn’t work on CachyOS.

There’s an official tutorial that describes the same procedure: How to restore a Snapper root snapshot on an unbootable system , but I only found that after I’d already figured it out the hard way.
(edit: put it up front, but below there is what I did)

The reason: fstab has subvol=/@ hardcoded. So on every normal boot, the kernel mounts whatever subvolume is literally named @ — and that’s still the broken one. snapper rollback only changes the btrfs default subvolume ID, which gets completely ignored when the name is specified in fstab. This is an openSUSE thing, doesn’t apply to Arch-based layouts.

What actually fixed it for me was replacing the broken @ with a writable copy of the working snapshot. Boot into your working snapshot via GRUB/Limine first, then:

# mount the top-level btrfs volume
sudo mkdir -p /tmp/btrfs-toplevel
sudo mount -o subvolid=5 /dev/YOUR_ROOT_PARTITION /tmp/btrfs-toplevel

# rename the broken @ so it stays as a backup
sudo mv /tmp/btrfs-toplevel/@ /tmp/btrfs-toplevel/@.broken

# create a writable copy of your working snapshot as the new @
sudo btrfs subvolume snapshot /tmp/btrfs-toplevel/@.broken/.snapshots/NUMBER/snapshot /tmp/btrfs-toplevel/@

# move .snapshots back into the new @ so snapper keeps working
sudo mv /tmp/btrfs-toplevel/@.broken/.snapshots /tmp/btrfs-toplevel/@/.snapshots

# rebuild bootloader — pick whichever you use
sudo grub-mkconfig -o /boot/grub/grub.cfg
# or: sudo limine-mkinitcpio

sudo umount /tmp/btrfs-toplevel
sudo reboot

After that the normal boot worked again. subvol=/@ now points to the restored system.

Few things that cost me extra time along the way:

  • Snapshots are read-only by default. If you need to write anything while booted into the snapshot (before doing the replacement), run sudo btrfs property set / ro false first. Without this the whole filesystem appears read-only even though mount shows rw.

  • Don’t test write access with touch /tmp/something/tmp is a tmpfs and always writable even when root is read-only. Test on /etc/ instead, wasted some time on that one.

  • NVMe device names can swap between reboots (nvme0n1 becomes nvme1n1 and vice versa). Use UUIDs to find your partition: blkid -U YOUR_UUID.

  • Don’t delete @.broken right away. It still has all your /etc/ configs from the broken system. Since the snapshot you’re restoring from is older, you’ll be missing any packages installed and configs changed after that date. You can diff against it:

sudo mount -o subvolid=5 /dev/YOUR_PARTITION /tmp/btrfs-toplevel
diff /etc/some/config /tmp/btrfs-toplevel/@.broken/etc/some/config
find /tmp/btrfs-toplevel/@.broken/etc/ -maxdepth 3 -type f -newer /tmp/btrfs-toplevel/@.broken/etc/os-release
  • Also /var/log sits on a separate @log subvolume, so it survives the whole rollback. You can grep through pacman.log to see what you installed between the snapshot date and the crash and reinstall from there:
grep "\[ALPM\] installed" /var/log/pacman.log | grep "2026-01"

So after 1. using a new iso to live boot into, i 2. edited limine config so boot menu would show up (timeout was set to 0 so i skip this bootmenu [bootmenu from uefi/bios wasn’t helpful]). From there i 3. loaded up a snap that was working (one before updates).
Than i 4. replaced old apparmor-git version with apparmor (so this was starting correctly again).
And 5. at last i also used @cscs help to resolve my pacnew files (marked this as the solution but it probably were multiple things).
Now my system is rebooting without errors and is fully updated again and i now know better to handle pacnew files and look out for them (update logs will inform one with a warning that new things are saved as pacnew).
Thanks for all your help.
Arch systems require some things to learn before sailing smoothly with them, but knowledge about the system is useful and enable one to do so much more.

Also while doing this i experienced a docker error because of my kernel updates and no restart yet. I got:

Error response from daemon: Cannot start container 4145d0fccd96b904e4ab4413735f1129b8765429bad5be71dc8d5f4c0760666d:
failed to create endpoint <networkNameOrSomethingSimilar> on network bridge:
failed to add the host (...) <=> sandbox (...) pair interfaces: operation not supported

This obviously resolved after restart as also seen in following posts: Docker: failed to add the pair interfaces (operation not supported), Docker produces veth-related error or docker: Error response from daemon: failed to create endpoint - failed to add host