How I was able to fix boot kernel issue on luks-encrypted BTRFS Manjaro

[Praxis]

I’m new to arch-based systems but have been using mostly Debian and to a lesser extent *buntu for 20 years, the last 10+ using luks-encrypted file systems. I’ve been kind of intimidated by arch because I’ve gathered that it is, shall we say, user-perhaps-less-than-friendly, being a rolling release that moves fast and breaks things. This impression was buttressed by my frequently encountering arch pages while looking for answers to technical issues, and perhaps, by seeing how good a lot of the arch-related documentation is. I figured both of these things were evidence of a bit of breakage.

Anywho, I wanted to play around with BTRFS and arch and installed Manjaro on a spare 120 GB SSD I had lying around.

Everything looked fine, but that computer lay in a corner for about 7 months, so when I finally booted Manjaro, there were gobs of updates, that is to be expected. At some point during the update the KDE interface froze pretty hard, but I was able to drop to a shell using Ctrl+Alt+Fx and restart the GUI using ‘systemctl stop sddm’ and starting it again. I did a “sudo pacman -Syu” but it seemed like the program finished normally and there wasn’t anything to do.

But when I rebooted grub wouldn’t load the kernel. I could boot an older snapshot, but didn’t want to upgrade again, fearing I would just get the same result (plus it took a big download and a fair dollop of time). So I tried to chroot into the system from the Debian install on the system, but things didn’t go smoothly. I decrypted the Manjaro partition with:

sudo cryptsetup luksOpen UUID=WhAtEver luks-WhAtEver

And mounted what I figured the partition was with:

mount /dev/mapper/luks-WhAtEver /mountpoint

But I was confronted by several @ sub-volumes at /mountpoint. So I mounted the efi partition at /mountpoint/@/boot/efi and did a:

for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do mount -B $i /mountpoint/@/$i; done

When I chrooted to the system I did a sudo pacman -Syu but was informed that the system was fully updated. But looking around for people who had similar issues I decided to update/reinstall the kernel, but since the system was BTRFS I had issues.

# pacman -Syu linux
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 multilib is up to date
warning: linux66-6.6.103-3 is up to date -- reinstalling
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (1) linux66-6.6.103-3

Total Download Size:   129.86 MiB
Total Installed Size:  134.95 MiB
Net Upgrade Size:        0.00 MiB

:: Proceed with installation? [Y/n] y
error: could not determine cachedir mount point /var/cache/pacman/pkg/download-ufPZIf
error: failed to commit transaction

I continued nosing through the net and found some pages that sort of pointed me in the right direction, but didn’t quite work for me. (The forum won’t allow me to include links for some reason).

Here is what did:

I booted from a Manjaro live image thinking I could use a special script I’d read about called arch-chroot but it didn’t seem to be on the image.

I persevered. I decrypted the partition.

sudo cryptsetup luksOpen UUID=WhAtEver luks-WhAtEver

Then I mounted the decrypted partition and subvolumes.

mount /dev/mapper/luks-WhAtEver /mnt/

I issued the following command to list the btrfs subvolumes:

btrfs subvolume list /mnt -t

ID      gen     top level       path
--      ---     ---------       ----
256     934     5               @
257     931     5               @home
258     925     5               @cache
259     925     5               @log
260     801     5               @swap
270     923     5               timeshift-btrfs/snapshots/2025-09-12_14-01-23/@
271     862     5               timeshift-btrfs/snapshots/2025-09-12_14-10-10/@
272     864     5               timeshift-btrfs/snapshots/2025-09-12_14-11-12/@

I made a subdirectory in the /mnt directory to mount the root partition and the subvolumes.

mkdir /mnt/mountpoint

Then I mounted the necessary subvolumes thusly:

mount -t btrfs -o subvolid=256 /dev/mapper/luks-WhAtVer /mnt/mountpoint/
mount -t btrfs -o subvolid=258 /dev/mapper/luks-WhAtVer /mnt/mountpoint/var/cache/pacman/pkg
mount -t btrfs -o subvolid=259 /dev/mapper/luks-WhAtVer /mnt/mountpoint/var/log
mount -t btrfs -o subvolid=257 /dev/mapper/luks-WhAtVer /mnt/mountpoint/home

Then I mounted the UFI partition.

mount UUID=SomeUuIdNumber /mnt/mountpoint/boot/efi

I prepped the mountpoints for chroot:

for i in /dev /dev/pts /proc /sys /sys/firmware/efi/efivars /run; do mount -B $i /mnt/mountpoint/$i; done

Did the chroot:

chroot /mnt/mountpoint

From there I was able to issue the necessary command, and when I rebooted I was able to boot my Manjaro system, Victory over the forces of evil!

[manjaro /]# sudo pacman -Syu linux

:: Synchronizing package databases...
 core is up to date
 extra is up to date
 multilib is up to date
warning: linux66-6.6.103-3 is up to date -- reinstalling
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...

Packages (1) linux66-6.6.103-3

Total Download Size:   129.86 MiB
Total Installed Size:  134.95 MiB
Net Upgrade Size:        0.00 MiB

:: Proceed with installation? [Y/n] y
:: Retrieving packages...
 linux66-6.6.103-3-x86_64              129.9 MiB   108 MiB/s 00:01 [####################################] 100%
(1/1) checking keys in keyring                                     [####################################] 100%
(1/1) checking package integrity                                   [####################################] 100%
(1/1) loading package files                                        [####################################] 100%
(1/1) checking for file conflicts                                  [####################################] 100%
(1/1) checking available disk space                                [####################################] 100%
:: Running pre-transaction hooks...
(1/1) Creating Timeshift snapshot before upgrade...
First run mode (config file not found)
Selected default snapshot type: BTRFS
Using system disk as snapshot device for creating snapshots in BTRFS mode
Mounted '/dev/dm-2 (sdb2)' (subvolid=0) at '/run/timeshift/8065/backup'
btrfs: Quotas are not enabled
Creating new backup...(BTRFS)
Saving to device: /dev/dm-2, mounted at path: /run/timeshift/8065/backup
Created directory: /run/timeshift/8065/backup/timeshift-btrfs/snapshots/2025-09-14_13-27-05
Created subvolume snapshot: /run/timeshift/8065/backup/timeshift-btrfs/snapshots/2025-09-14_13-27-05/@
Created control file: /run/timeshift/8065/backup/timeshift-btrfs/snapshots/2025-09-14_13-27-05/info.json
BTRFS Snapshot saved successfully (0s)
Tagged snapshot '2025-09-14_13-27-05': ondemand
------------------------------------------------------------------------------
First run mode (config file not found)
Selected default snapshot type: BTRFS
Mounted '/dev/dm-2 (sdb2)' (subvolid=0) at '/run/timeshift/8192/backup'
btrfs: Quotas are not enabled
Selected default snapshot device: /dev/dm-2
------------------------------------------------------------------------------
Removing snapshot: 2025-09-12_14-10-10
Deleting subvolume: @ (Id:271)
Deleted subvolume: @ (Id:271)

Deleted directory: /run/timeshift/8192/backup/timeshift-btrfs/snapshots/2025-09-12_14-10-10
Deleted directory: /run/timeshift/8192/backup/timeshift-btrfs/snapshots/2025-09-12_14-10-10
Removed snapshot: 2025-09-12_14-10-10

Kind of a pain in the posterior but it worked, maybe someone else will find my experience useful

[linux-aarhus]

With a default Manjaro installation it may create hair-pulling issues as boot is on btrfs and btrfs uses compression which may cause non booting systems.

A very informative topic on btrfs Btrfs Best Practice

The Manjaro wiki page Btrfs - Manjaro

This is one of the reasons I wrote this guide - btrfs filesystem does indeed need special attention - both with troubleshooting and with maintenance Basic Manjaro rescue and Recovery

[soundofthunder]

@Praxis

The forum won’t allow me to include links for some reason)

A workaround until your forum privileges increase (which they do as a matter of course after a certain amount of interaction), is to place the full URL between “backticks” - It won’t be a clickable live link, but others will be able to easily select/copy/paste the URL if they wish.

Example: `https://forum.manjaro.org`

Regards.

---

Welcome to the Manjaro community

As a new or infrequent forum user, please take some time to familiarise yourself with Forum requirements, and the many ways to use the forum to your benefit.

To that end, links are provided (below) - Please use them.

---

Be prepared to provide outputs from various commands when asked. It’s equally important to provide as much actionable information as possible in your first post, rather than simply indicating there is a problem.

Waiting for someone to blindly ask questions is also counter-productive – typically, nobody has a at their disposal – Instead, please help others to make informed suggestions, based on information you provide.

---

Update Announcements

The Update Announcements contain important information and a Known Issues and Solutions section that should generally be checked before posting a request for support.

System Information

While information from *-fetch type apps might be fine for someone wishing to buy your computer, for Support purposes it’s better to ask your system directly;

Output of the inxi command (with appropriate parameters, and formatted according to forum guidelines) will generate information useful for those wishing to help:

inxi --filter --verbosity=8

or the short form (preferred):

inxi -zv8

• inxi man pages (Arch Manual)

@Running `inxi` in `chroot`

If you need to run inxi from within a chroot environment, and find the output is laced with unexpected 12’s, please try again with:

• Add to the long form command: --color=0
• or, change the short form to: inxi -zv8c0

@Your privacy is respected

When inxi is run using the --filter or -z parameters, any personally identifiable information is filtered from the resulting output.

Highly Recommended

• How to Post
• How to Request Support
• How to Post Command Output as Preformatted Text

Technical Resources

• Manjaro Update Announcements
• Manjaro Wiki
• Arch Wiki
• Tutorials

Required Reading

• Forum Rules
• Strict Forum Rules and Guidelines

---

@Notice

The above content is partially pre-prepared as an introduction for new or returning forum Users. Please take the time to follow any links given and discover how to use the Manjaro forum features effectively.

[andreas85]

@Praxis

But when I rebooted grub wouldn’t load the kernel.

After the update, it’s possible to check for kernel and initramfs presence.
You can look yourself into /boot with:

sudo ls -lA /boot

and look for kernels and initramdisks or use maxi
I use maxi after every update because I’ve had a non-booting system more than once because the kernel was missing.