Arch Linux

erickwill

Member

Registered: 2013-11-05

Posts: 145

[SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Hi all,

After performing a system update that included the latest kernel, my Arch Linux installation fails to boot. The failure happens immediately after the kernel update, and it appears to be a kernel panic related to bcachefs (instead of  a segmentation fault in systemd) triggered during early mounting of the bcachefs root filesystem.

---

System Info

Laptop: MSI GF75 Thin 9SC

CPU/GPU: Intel/NVIDIA hybrid

OS: Arch Linux (fully updated as of April 30, 2025)

Bootloader: systemd-boot

Kernel: linux 6.14.4 (stock1-2 and zen1-2)

Root FS: bcachefs

Init system: systemd

---

Issue Description

After selecting the updated kernel in systemd-boot, the boot process begins but crashes with the following symptoms:

bcachefs trace shows up first:

bch2_xattr_set
bch2_inode_unpack
...

Shortly after that, systemd[1] crashes with a segmentation fault:

systemd[1]: segfault at ...
systemd[1]: Main process exited, code=killed, status=11/SEGV
systemd[1]: Failed to start Load Kernel Modules.
systemd[1]: Failed to start Load/Save Random Seed.
A start job is running for Journal Service...

Boot process hangs or loops after that point.

---

[ 0.243437] <TASK>
[ 0.243505] ? bch2_xattr_set_cold+0x13/0x182 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243508] ? nemcg_list_lru_alloc+0x92/0x260
[ 0.243562] ? btree_path_alloc+0x18/0x190 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243613] ? __bch2_inode_peek+0xa1/0x1e0 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243683] ? bch2_inode_unpack_u3+0x7e7/0x980 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243750] ? __bch2_time_stats_update+0xf5/0x350 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243820] ? bch2_trans_begin+0x6d4/0x790 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.265321] ? bch2_xattr_set_handler+0x120/0x220 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.265324] ? __pfx_bch2_xattr_set_handler+0x10/0x10 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.266353] __ufs_setxattr+0x3a/0xd0
[ 0.266357] __ufs_setxattr_nopern+0x77/0x1f0
[ 0.266361] ufs_setxattr+0x9d/0x190
[ 0.266364] file_setxattr+0x59/0xb0
[ 0.266367] path_setxattr+0x188/0x1f0
[ 0.266371] __x64_sys_fsetxattr+0x29/0x40
[ 0.266374] do_syscall_64+0x7b/0x190
[ 0.266376] ? do_truncate+0x98/0xf0
[ 0.266380] ? do_truncate+0xac/0xf0
[ 0.266383] ? do_truncate+0x12c/0x1c0
[ 0.266386] ? syscall_exit_to_user_mode+0x37/0x1c0
[ 0.266389] ? do_syscall_64+0x87/0x190
[ 0.271692] ? irqentry_exit_to_user_mode+0x2c/0x1b0
[ 0.271695] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 0.272699] RIP: 0033:0x7f5675551f02e
[ 0.273021] Code: 48 8b 04 d5 6c 6d 06 e7 48 89 01 48 83 c1 18 ff c3 66 2e 0f 1f 84 00 00 00 00 f3 0f 1e fa 49 89 ca b8 be 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b2 6c 0d 00 f7 d8 64 89 01 48
[ 0.273022] RSP: 002b:00007fffef4473c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000be
[ 0.273024] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5675551f02e
[ 0.273025] RDX: 00005ef637db50cf RSI: 00005ef637db5091 RDI: 0000000000000065
[ 0.273025] RBP: 00007fffef447510 R08: 0000000000000000 R09: 0000000000000000
[ 0.273026] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[ 0.273027] R13: 0000000000000001 R14: 0000000000000001 R15: 00005ef6637c6b00
[ 0.273029] </TASK>
[ 0.273029] Modules linked in: pkcs8_key_parser loop dm_mod nfnetlink ip_tables x_tables bcachefs lz4_compress lz4hc_compress amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm serio_raw drm_exec atkbd gpu_sched drm_suballoc_helper libps2 uinput hid_generic usbhid
[ 0.273048] ---[ end trace 0000000000000000 ]---
[ 0.273049] RIP: 0010:_fortify_panic+0xd/0xf
[ 0.273051] Code: c9 01 00 00 e9 b7 b5 b4 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 40 0f b6 ff e8 03 c2 0d 00 <0f> 0b 48 8b 54 24 10 48 8b 74 24 08 4c 89 e1 48 c7 c7 25 bb 47 b2
[ 0.273052] RSP: 0018:ffffa943c10f3818 EFLAGS: 00010246
[ 0.273054] RAX: 0000000000000000 RBX: ffff889b8e10c000 RCX: 0000000000000027
[ 0.280361] RDX: ffff88aa7ee21908 RSI: 0000000000000001 RDI: 0000000000000027
[ 0.280362] RBP: ffffa943c10f3a70 R08: 0000000000000000 R09: ffff889b87c1da0b
[ 0.280363] R10: ffffffffb393d820 R11: ffffa943c10f36a8 R12: ffff889b8e10c000
[ 0.280364] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8889c887d40b
[ 0.280365] FS: 00007f56755a8180(0000) GS:ffff88aa7fdb0000(0000) knlGS:0000000000000000
[ 0.280366] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.280367] CR2: 0000558975c30f00 CR3: 0000000110cb6004 CR4: 00000000003706f0
[ 0.280368] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.280369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.283683] See 'systemctl status systemd-journal-flush.service' for details.
[ 0.287098] systemd[1]: systemd-random-seed.service: Main process exited, code=killed, status=11/SEGV
[ 0.287944] systemd[1]: systemd-random-seed.service: Failed with result 'signal'.
[ 0.287994] systemd[1]: Failed to start Load/Save OS Random Seed.
[FAILED] Failed to start Load/Save OS Random Seed.
See 'systemctl status systemd-random-seed.service' for details.
[ 0.290988] systemd[1]: systemd-random-seed.service: Scheduled restart job, restart counter is at 1.
[ 0.291452] systemd[1]: Starting Journal Service...
[ 8.316905] systemd[1]: Finished Coldplug All udev Devices.
[ OK ] Finished Coldplug All udev Devices.
Starting Journal Service...
[ --] (1 of 3) A start job is running for Journal Service (37s / 1min 30s)

Cause

This behavior started immediately after a kernel update, without any other significant system changes. All signs point to a compatibility or regression issue between:

The updated Linux kernel, and

The use of bcachefs as the root filesystem, possibly affecting systemd as it initializes services.

---

Actions Taken

Rebooted with fallback initramfs: same crash.

Unable to fully read journalctl logs due to early systemd failure.

Tried booting with previous kernel: works normally.

Issue seems reproducible and isolated to the updated kernel only.

---

Request for Help

Has anyone else experienced kernel panic when booting with bcachefs on the latest kernel?

Are there known regressions in bcachefs support or xattr handling in the current linux package?

Is it recommended to file this directly with the Arch kernel maintainers or upstream bcachefs?

---

Temporary Workaround

I’ve temporarily downgraded the kernel to regain access to my system. For now:

Avoid upgrading to the latest kernel if using bcachefs as root FS.

Test upgrades in a controlled environment or via a second boot entry if possible.

---

Thanks in advance for any insights.

--> Solved after the last testing kernel update. <--

Last edited by erickwill (2025-05-12 13:26:28)

Scimmia

Fellow

Registered: 2012-09-01

Posts: 12,664

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

That doesn't look like systemd segfaulting. What does it say it's segfaulting at?

erickwill

Member

Registered: 2013-11-05

Posts: 145

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

That doesn't look like systemd segfaulting. What does it say it's segfaulting at?

You're right to question that — let me clarify with more specifics from the trace.

The segfault is triggered during boot at PID 1 (systemd[1]), which strongly suggests it is systemd that's crashing. The logs include this line:

systemd[1]: segfault at ... code=killed, status=11/SEGV

And further above:

systemd[1]: Failed to start Load Kernel Modules.
systemd[1]: Failed to start Load/Save Random Seed.

These lines indicate it's crashing early in the boot process when system services are starting. PID 1 is always reserved for the init system — in Arch, that's systemd.

If you're asking "what exactly is segfaulting," the full register dump includes what looks like a bcachefs path through xattr and inode unpacking code right before the segfault occurs. That suggests a likely cause is:

A bug in the kernel-side bcachefs implementation (possibly in its extended attributes or inode handlers),

which corrupts memory or passes bad state to userspace, causing systemd to crash when it tries to mount or process those FS entries.

So the kernel module may be indirectly causing systemd to segfault — but the crash itself is definitely occurring within PID 1.

Happy to post the exact RIP and stack if needed.

Scimmia

Fellow

Registered: 2012-09-01

Posts: 12,664

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

No, this is systemd reporting that something else segfaulted. If systemd (pid1) segfaulted, that would result in a kernel panic, which isn't what you're seeing. Unfortunately, you're replacing the important stuff with '...', so we've got nothing.

erickwill

Member

Registered: 2013-11-05

Posts: 145

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

No, this is systemd reporting that something else segfaulted. If systemd (pid1) segfaulted, that would result in a kernel panic, which isn't what you're seeing. Unfortunately, you're replacing the important stuff with '...', so we've got nothing.

Thanks for the clarification — that's helpful.

You're right, I may have misinterpreted the output. It seems I focused too much on the systemd messages and mistakenly thought it was PID 1 that was crashing. I appreciate you pointing out that a true segfault in PID 1 would lead to a full kernel panic, which I’m not actually seeing.

I'll go back and extract the complete, unabridged kernel trace and relevant logs without replacing anything with ..., so the actual faulting component can be properly identified. Thanks again for your help!

[ 0.243437] <TASK>
[ 0.243505] ? bch2_xattr_set_cold+0x13/0x182 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243508] ? nemcg_list_lru_alloc+0x92/0x260
[ 0.243562] ? btree_path_alloc+0x18/0x190 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243613] ? __bch2_inode_peek+0xa1/0x1e0 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243683] ? bch2_inode_unpack_u3+0x7e7/0x980 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243750] ? __bch2_time_stats_update+0xf5/0x350 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.243820] ? bch2_trans_begin+0x6d4/0x790 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.265321] ? bch2_xattr_set_handler+0x120/0x220 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.265324] ? __pfx_bch2_xattr_set_handler+0x10/0x10 [bcachhefs c0363304960a9b04d949b928a6c69620e0c3e7a3]
[ 0.266353] __ufs_setxattr+0x3a/0xd0
[ 0.266357] __ufs_setxattr_nopern+0x77/0x1f0
[ 0.266361] ufs_setxattr+0x9d/0x190
[ 0.266364] file_setxattr+0x59/0xb0
[ 0.266367] path_setxattr+0x188/0x1f0
[ 0.266371] __x64_sys_fsetxattr+0x29/0x40
[ 0.266374] do_syscall_64+0x7b/0x190
[ 0.266376] ? do_truncate+0x98/0xf0
[ 0.266380] ? do_truncate+0xac/0xf0
[ 0.266383] ? do_truncate+0x12c/0x1c0
[ 0.266386] ? syscall_exit_to_user_mode+0x37/0x1c0
[ 0.266389] ? do_syscall_64+0x87/0x190
[ 0.271692] ? irqentry_exit_to_user_mode+0x2c/0x1b0
[ 0.271695] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 0.272699] RIP: 0033:0x7f5675551f02e
[ 0.273021] Code: 48 8b 04 d5 6c 6d 06 e7 48 89 01 48 83 c1 18 ff c3 66 2e 0f 1f 84 00 00 00 00 f3 0f 1e fa 49 89 ca b8 be 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b2 6c 0d 00 f7 d8 64 89 01 48
[ 0.273022] RSP: 002b:00007fffef4473c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000be
[ 0.273024] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5675551f02e
[ 0.273025] RDX: 00005ef637db50cf RSI: 00005ef637db5091 RDI: 0000000000000065
[ 0.273025] RBP: 00007fffef447510 R08: 0000000000000000 R09: 0000000000000000
[ 0.273026] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[ 0.273027] R13: 0000000000000001 R14: 0000000000000001 R15: 00005ef6637c6b00
[ 0.273029] </TASK>
[ 0.273029] Modules linked in: pkcs8_key_parser loop dm_mod nfnetlink ip_tables x_tables bcachefs lz4_compress lz4hc_compress amdgpu amdxcp i2c_algo_bit drm_ttm_helper ttm serio_raw drm_exec atkbd gpu_sched drm_suballoc_helper libps2 uinput hid_generic usbhid
[ 0.273048] ---[ end trace 0000000000000000 ]---
[ 0.273049] RIP: 0010:_fortify_panic+0xd/0xf
[ 0.273051] Code: c9 01 00 00 e9 b7 b5 b4 00 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 40 0f b6 ff e8 03 c2 0d 00 <0f> 0b 48 8b 54 24 10 48 8b 74 24 08 4c 89 e1 48 c7 c7 25 bb 47 b2
[ 0.273052] RSP: 0018:ffffa943c10f3818 EFLAGS: 00010246
[ 0.273054] RAX: 0000000000000000 RBX: ffff889b8e10c000 RCX: 0000000000000027
[ 0.280361] RDX: ffff88aa7ee21908 RSI: 0000000000000001 RDI: 0000000000000027
[ 0.280362] RBP: ffffa943c10f3a70 R08: 0000000000000000 R09: ffff889b87c1da0b
[ 0.280363] R10: ffffffffb393d820 R11: ffffa943c10f36a8 R12: ffff889b8e10c000
[ 0.280364] R13: 0000000000000000 R14: 0000000000000000 R15: ffff8889c887d40b
[ 0.280365] FS: 00007f56755a8180(0000) GS:ffff88aa7fdb0000(0000) knlGS:0000000000000000
[ 0.280366] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.280367] CR2: 0000558975c30f00 CR3: 0000000110cb6004 CR4: 00000000003706f0
[ 0.280368] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 0.280369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 0.283683] See 'systemctl status systemd-journal-flush.service' for details.
[ 0.287098] systemd[1]: systemd-random-seed.service: Main process exited, code=killed, status=11/SEGV
[ 0.287944] systemd[1]: systemd-random-seed.service: Failed with result 'signal'.
[ 0.287994] systemd[1]: Failed to start Load/Save OS Random Seed.
[FAILED] Failed to start Load/Save OS Random Seed.
See 'systemctl status systemd-random-seed.service' for details.
[ 0.290988] systemd[1]: systemd-random-seed.service: Scheduled restart job, restart counter is at 1.
[ 0.291452] systemd[1]: Starting Journal Service...
[ 8.316905] systemd[1]: Finished Coldplug All udev Devices.
[ OK ] Finished Coldplug All udev Devices.
Starting Journal Service...
[ --] (1 of 3) A start job is running for Journal Service (37s / 1min 30s)

Last edited by erickwill (2025-05-01 00:41:20)

sngn

Member

Registered: 2022-09-29

Posts: 9

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

I had the same problem when upgrading to 6.14.4.zen1-2. Downgrading to 6.14.4.zen1-1 helped. Fscking the filesystem did not.

erickwill

Member

Registered: 2013-11-05

Posts: 145

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

I had the same problem when upgrading to 6.14.4.zen1-2. Downgrading to 6.14.4.zen1-1 helped. Fscking the filesystem did not.

Yep, though it also happens with the stock kernel 6.14.4.1-2, not only zen. It looks like a kernel related issue, or maybe bcachefs-tools needs some care.

xerxes_

Member

Registered: 2018-04-29

Posts: 904

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Maybe you haven't boot partition mounted when you updated system and you have different kernel version installed and running?
Post output of commands:

uname -a
pacman -Qs linux | grep '/linux'

Scimmia

Fellow

Registered: 2012-09-01

Posts: 12,664

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

So that appears to be a kernel oops while trying to flush the journal to disk, then the process of systemd-random-seed.service segfaults. Two separate, but likely related, events. Will probably have to go upstream to the kernel bcachefs maintainer.

Last edited by Scimmia (2025-05-01 18:23:11)

gerald5

Member

Registered: 2024-10-17

Posts: 2

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Kernel 6.14.4 also broke bcachefs for me, I have bcachefs in a gaming drive, wine can't launch games from there and it crashes if I navigate to the drive with wine's explorer.exe
I also had a crash in Dolphin when deleting a folder in the bcachefs drive, downgrading to 6.14.3 fixed it for me

hawkinstw

Member

Registered: 2013-01-26

Posts: 9

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Kent Overstreet has posted a patch to the bcachefs bug.
https://github.com/koverstreet/bcachefs/issues/845
https://lore.kernel.org/linux-bcachefs/ … linux/T/#t

erickwill

Member

Registered: 2013-11-05

Posts: 145

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Hopefully this patch gonna hit us sooner. Thanks for sharing the news @hawkinstw

erickwill

Member

Registered: 2013-11-05

Posts: 145

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Does anyone tried the new extra-testing kernels if they've fixed bcachefs?

Ranguvar

Member

Registered: 2008-08-12

Posts: 2,572

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

The patch was picked up by stable but not in time for 6.14.5 and it wasn't manually added at least by Zen.

You can check fs/bcachefs/xattr_format.h for x_name[] __counted_by(x_name_len).

If present, still bugged.

loqs

Member

Registered: 2014-03-06

Posts: 18,436

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

The patch was picked up by stable

That is the commit from mainline https://git.kernel.org/pub/scm/linux/ke … 821d849e78 pulled in by https://git.kernel.org/pub/scm/linux/ke … 9dc5432f95. When stable pulled from mainline it picked up all the commits referenced in mainline. That does not mean such commits are queued for stable. At the time of writing all stable queues are empty https://git.kernel.org/pub/scm/linux/ke … queue.git/.

erickwill

Member

Registered: 2013-11-05

Posts: 145

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Hi all,

I'm revisiting the bcachefs issues previously discussed here (related to kernel 6.14.5.zen1-1) as the problems seem to be ongoing despite recent kernel updates, and are also impacting fresh installation attempts.
Previous Context:
Many of us experienced boot failures with bcachefs on kernel 6.14.4.zen1-2 and later, seemingly due to an xattr-related bug. A patch was identified ( https://git.kernel.org/pub/scm/linux/ke … 821d849e78 ) and was expected to resolve this.

Current Situation (Updated System):
After a subsequent system update, which I hoped would include the fix (stable 6.14.5.zen1-1) my existing Arch Linux installation with bcachefs as the root filesystem continues to fail during boot.
The symptoms are very similar to before:
Boot process starts.
Kernel traces related to bcachefs appear (e.g., involving bch2_inode_unpack, bch2_xattr_set, or other bch* functions). The same log as before.
This is often followed by a kernel panic or messages indicating a segfault, sometimes implicating _fortify_panic or systemd services failing as a secondary effect.
The system hangs or enters a boot loop.
Downgrading to 6.14.4.zen1-1 still allows the system to boot.

Current Situation (Fresh Installation Attempt):
Given the ongoing issues, I also attempted a completely fresh Arch Linux installation using the latest (May 2025) ISO.
During the pacstrap phase (while writing to the newly bcachefs-formatted target partition), the installation fails with a kernel oops/panic.
The error messages from this installation attempt sometimes include a call trace involving sg_write (as I noted in a separate context earlier), or other block layer/filesystem-level errors.
The system becomes unstable, and pacstrap cannot complete.

System Info (Reminder):

Laptop: MSI GF75 Thin 9SC
Bootloader: systemd-boot
Root FS: bcachefs
Init system: systemd

Observations & Questions:
Patch Ineffective/Not Included? Is it possible the known xattr patch wasn't correctly incorporated into the recent kernel versions I've tried, or is there a different way to verify its presence beyond the x_name[] __counted_by(x_name_len) check in xattr_format.h (if that check now passes)?
New Regression? Could this be a new, different regression in bcachefs or its interaction with the block layer/kernel in versions subsequent to 6.14.4?

Installation ISO Kernel: The failure on a fresh install using a recent ISO suggests the issue is present in the kernel shipped on that ISO itself.
Could this be a bcachefs-tools problem along with the kernel? Could this be a factor if there's a mismatch or bug in the tools?

Is anyone else still experiencing bcachefs instability or boot failures on kernels newer than 6.14.4-1.1 or 6.14.4.zen1-1 (e.g., 6.14.5+)?
Has anyone successfully performed a fresh Arch install with bcachefs as root using a very recent ISO and kernel? If so, what kernel and bcachefs-tools versions were used?
Are there any new recommended debugging steps or kernel parameters to try for bcachefs with these newer kernels?
What's the best channel to report this if it seems to be an unaddressed or new upstream bcachefs/kernel bug?
I'm still able to boot by falling back to kernel 6.14.4.zen1-1, but the inability to update or perform a clean install is concerning. Any insights or shared experiences would be greatly appreciated.

Thanks

loqs

Member

Registered: 2014-03-06

Posts: 18,436

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Please see https://gitlab.archlinux.org/archlinux/ … ote_268293 and the previous two comments to your own.

hawkinstw

Member

Registered: 2013-01-26

Posts: 9

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

I was struggling with the linux-git version that didnt work with my nvidia, but eventually switched to a self compiled (after I figured out to 9import the gpg keys)  linux-testing 6.14.6 and its working nice.

erickwill

Member

Registered: 2013-11-05

Posts: 145

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Solved after the last testing kernel update.

lemel

Member

Registered: 2015-09-13

Posts: 4

Re: [SOLVED]Failed to Boot with Bcachefs After Kernel Update-Kernel Panic

Can confirm, working `6.14.6`