You are not logged in.
When I try to start my system, it doesnt work. I get thrown into a terminal enviroment (afaik the initramfs shell). It show the following:
Starting systemd-udevd version 261.2-1-arch
running hook [udev]
Triggering uevents..
running hook [keymар]
Loading keymap...done.
performing fsck on 'UUID=57a1f979-5589-4650-ac3b-2c787041c24d mounting UUID=57811979-5589-1650-ac3b-2c767041c24d' on real root
7.7988101 BTRFS error (device nvme1n1p2) parent transid verify failed on logical 2510879145984 mirror 1 wanted 224258 found 223912
7.7993641 BTRFS error (device nvme1n1p2): parent transid verify failed on logical 2510879145984 mirror 2 wanted 224258 found 223912
7.7994201 BTRFS error (device nvme1n1p2 state AO): Transaction aborted (error -5)
7.7994291 BTRFS: error (device nvme1n1p2 state AO) do_abort_log_replay: 191: errno=-5 IO failure
BTRFS critical (device nvme1n1p2 state EAO): log tree (for root 257) leaf currently being processed (slot 38 key
7.7994353 BTRFS crritical (device nvme1n1p2 state EAO)log replay failed in replay_one_extent:998 for root 257, stage 3 with error -5: failed to delete csums for range [1982292787200, 1982292791296) inode 6694527 root 257
BTRFS error (device nvme1n1p2 state EAO): in btrfs_recover_log_trees:7784: errno=-5 IO failure
BTRFS error (device nvme1n1p2 state EAO): failed to recover log trees with error: -
BTRFS error (device nvme1n1p2 state EAO): open_ctree failed: -5
mount: /new_root: cant read superblock on /dev/nvme1n1p2
dmesg may have more information...
ERROR: Failes to mount 'UUID=...‘ on real root
ergency shell. You are now being dropped into an shell
sh: can't access tty: job control turned off
[rootfs ~]#(Since I cant copy from my computer I had to manually type it so it may contain some small typing errors)
I dindt really do anything since i last started my pc (when it worked).
And I tried to boot into a live usb stick but even when spamming DEL (my motherboard key for bios) it goes too fast into arch linux as that i could get into the bios.
Im would appreciate any help.
Last edited by E2Z1 (2026-08-10 17:52:07)
Offline
After std-disclaimer.h - 'It is strongly advised to have a backup of data before attempting repairs.' - we can take a moment to admire the linux toolbox, and hopefully, also btrfs integrity.
A dry run basic filesystem check of the partition may be informative.
btrfs check --readonly /dev/nvme1n1p2If in doubt, check drive S.M.A.R.T. status for hardware failure.
smartctl -a /dev/nvme1n1Consider a basic check with repairs.
btrfs check --repair /dev/nvme1n1p2A more 'nuclear' option seems relevant here: btrfs rescue zero-log /dev/nvme1n1p2 .. From 'man btrfs rescue':
zero-log <device>
Clear the filesystem log tree.
This command will clear the filesystem log tree. This may fix a specific set of problem when the filesystem mount fails
during log replay. See below for sample stack traces that may show up in system log.
Note:
Clearing the log may lead to loss of changes that were made since the last transaction commit. This may be up to 30 sec‐
onds (default commit period) or less if the commit was implied by other filesystem activity.
One can determine whether zero-log is needed according to the kernel backtrace:
? replay_one_dir_item+0xb5/0xb5 [btrfs]
? walk_log_tree+0x9c/0x19d [btrfs]
? btrfs_read_fs_root_no_radix+0x169/0x1a1 [btrfs]
? btrfs_recover_log_trees+0x195/0x29c [btrfs]
? replay_one_dir_item+0xb5/0xb5 [btrfs]
? btree_read_extent_buffer_pages+0x76/0xbc [btrfs]
? open_ctree+0xff6/0x132c [btrfs]
If the errors are like above, then zero-log should be used to clear the log and the filesystem may be mounted normally
again. The keywords to look for are 'open_ctree' which says that it's during mount and function names that contain replay,
recover or log_tree.Edit: What, if anything, is lost depends on the state at the time of incident. Log files seem more frequent victims and usually non-critical. But if this happened during a pacman/system update, I would probably reinstall some packages at end of pacman.log, just to be sure.
Last edited by espresso (2026-08-09 19:12:56)
‘There is no other definition of socialism valid for us than that of the abolition of the exploitation of man by man!’ - Che Guevara
Offline
This kind of error usually indicates misbehaving hardware. Doesn't look like bitflips/RAM issue. Most likely the disk does not have working write barriers/lies about sync/flush, which is a firwmare bug, and is common. Assuming the disk is not failing, and zero-log succeeds in mounting the disk (I think it might), consider 1. disabling the write cache, 2. mounting with flushoncommit, which should work around these issues.
Offline
https://wiki.archlinux.org/title/Solid_ … NVMe#SMART
If it's not the disk see https://bbs.archlinux.org/viewtopic.php … 8#p2248608 - same symptoms
Nb. that backups aren't optional w/ --repair, https://wiki.archlinux.org/title/Btrfs#btrfs_check
In doubt clone the disk/partition
Offline
First, I'd like to thank all of you.
So after check repair and zerolog the drive is mountable again but the transid verify failed errors still show up and force the mount into readonly.
Smartctl shows no critical warning or Media and Data Integrity Errors. I also tried flushoncommit and disabling the write cache (although im not sure whether the latter worked tbh). The transid error still persists.
Is there a better option than recreating my root fs?
Offline
A more 'nuclear' option seems relevant here: btrfs rescue zero-log /dev/nvme1n1p2
You can also first try "btrfs rescue super-recover /dev/nvme1n1p2"
Offline
I already did recue zero-log and super-recover but the transid errors persist and force the drive into readonly. Sorry for forgetting to tell that I did super-recover. It says all supers would be valid
Offline
mkfs time. Hopefully you will be able to get the data off the drive.
Offline
Thank you
Offline
The #btrfs IRC channel on Libera has a couple of devs and some experts. It might help to lurk there and pick up tips if you're using it regularly. In the meantime, consider my recommendations, and be glad that btrfs caught an issue. This kind of thing just silently corrupts ext4 (which I still use and love, but it has some limitations).
Offline