Your chroot looks fine, actually. It looks like the GUI tool is working for you, no need to use the manual steps.
Don’t use sudo inside the chroot–you are already elevated to root so it is not needed. See here:
It looks like every time you invoke sudo it fails with Bus error (core dumped)–it should not be doing that, that is bad…but you shouldn’t be doing it anyway.
The two times you correctly ran pacman -S linux-lts linux-lts-headers (without sudo), you got two different results. Maybe try a few more times, just in case?
My instinct would be you have run into a problem with your filesystem or RAM, since the behavior from your system seems rather bizarre and crashy.
I'm reading up more for a second attempt at chroot. Will post an update after that. For now this is almost a full read on what happens when I try to recovery mode:
Triggering uevents...
:: :: running hook [keymap]
::Loading keymap...done.
:: running hook (consolefont] ::Loading console font...done.
:: running hook [plymouth]
running hook [resume]
ERROR: resume: no device specified for hibernation :: mounting/dev/sda2' on real root
:: running late hook [plymouth] :: running late hook [grub-btrfs-overlayfs]
::running cleanup hook [udev]
4.865688] BTRFS error (device sda2): bdev /dev/sda2 errs: ur 8, rd 8, flush 8, corrupt 82, gen 8
4.8787711 BTRFS error (device sda2): bdev /dev/sda2 errs: ur 8. rd 8, flush 8, corrupt 83, gen 8 4.8793691 BTRFS error (device sda2): bdev /dev/sda2 errs: ur 8. rd 8, flush 8, corrupt 84, gen 8
4.8794261 Kernel panic - not syncing: Attempted to kill init! exitcode=8x88888887 4.8794651 CPU: 3 PID: 1 Comm: init Tainted: P DE 6.1.7-zen1-1-zen #1 251eee86d1e3487eafb15439b5bcc81efef5caf9
4.879518] Hardware name: To Be Filled By O.E.M. A528M Phantom Gaming 4/A520M Phantom Gaming 4. BIOS P1.68 82/24/2822
4.879564) Call Trace:
4.8795771 TASK
4.879588) dump_stack_lvl+8x48/8x68 4.879688) panic+8x11c/8x29b
4.8796251 do_exit.cold+8x15/8x15
4.879642] do_group_exit+8x31/8x88 4.879668) get_signal+8x96e/8x978
4.8796781 arch_do_signal_or_restart+8x48/8x768 4.8797811 ? send signal locked+8x375/8x588
4.8797241 exit_to_user_mode_prepare+8xfb/8x1d8 4.8797471 irgentry_exit_to_user_mode+8x9/8x38
4.8797691 ass exc_page_fault+8x26/8x38 4.8797891 RIP: 8833:8x7f3c7c34f6e8
4.879889) Code: Unable to access opcode bytes at 8x7f3c7c34f6b6.
4.8798361 RSP: 882b:88887ffefe179c28 EFLAGS: 88818246 4.8798681 RAX: 88887f3c7c34f6e8 RBX: 88887f3c7c316318 RCX: 88887f3c7d177a28
4.8798911 RDX: 88887f3c7c38b988 RSI: 8888888888888888 RD1: 8888888888888888
4.8799221 RBP: 88887ffefe179d38 R88: 8888888888722fc8 R89: 8888888888888888 4.8799521 R18: 8888713c7c38b988 R11: 8888713c7c389888 R12: 8888713c7d177a28
4.8799831 R13: 88887f3c7c316548 R14: 88887f3c7c3efef8 R15: 88887f3c7c389888 4.888815) </TASK>
4.8881641 Kernel Offset: 8x19c88888 from 8x1111111181888888 (relocation range: Bxffffffff88888888-8xffffffffbfffffff) 4.888215) end Kernel panic not syncing: Attempted to kill initi exitcode=8x88888887 1---
That output looks more distinctly like filesystem corruption.
A good next step will be to boot to the live environment again, get the disk mounted with the chroot tool, and run a scrub on the partition.
btrfs scrub start -Bd /dev/sda2
The B flag stops the process from being run in the background (running in the background is the default), and the d flag prints separate statistics for each device of the filesystem at the end of the process. Paste all the input/output you get into the thread so we can take a look.
If you still can't get any further with the disk, a last-resort operation will be btrfs-check. It has an in-built repair feature which is powerful, but considered risky. It should only be used if all other options fail.
Nvidia has ceased game ready driver support on all keplers and the Linux kernel 6.0 and up has issues with the 470xx drivers and causes problems when generating system initramfs images that cause boot failures after updating.
anyone running kepler gpu's are currently relegated to the LTS kernel until the kernel issue is fixed.
also beware that the LTS kernel v6 may also have these issues, as far as i'm aware the initramfs problem may persist in that version as well, so be prepared.
Opening filesystem to check ... Checking filesystem on /dev/sda2
UUID: 85473a04-9749-493e-8136-19ff432cc3f1
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[4/7] checking fs roots [5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS) found 520480440320 bytes used, no error found
total csum bytes: 506954996
total tree bytes: 1182908416
total fs tree bytes: 512638976 total extent tree bytes: 74022912
btree space waste bytes: 185193159
file data blocks allocated: 2162544762880 referenced 550508195840
garuda@garuda in ~ as took 17s
At this point, I want to thank everyone for help thus far. Thank you.
I'm bent on fixing vs reinstalling because at this point I don't feel like I learn anything by reinstalling. I want to try to fix it because pulling out the 'ol reinstall stick feels like a mechanic loading up a parts cannon. I am getting close to giving up. Clearly it's beyond my skill level. Maybe learning what caused this so that I can avoid it later would be better.
fsck does not work the same in Btrfs as it does in other filesystems. btrfs check is the equivalent command. btrfs check does have more intensive commands you can do, but if you read the documentation they basically tell you not to run them unless an expert tells you to because they are unstable/in development.
Do you have an external hard drive that is big enough to hold your entire system partition?
If you have an external hard drive with enough free space to hold the entire Btrfs filesystem on your system partition, you could use btrfs replace to move your stuff onto the hard drive, then reformat the Btrfs partition to address any filesystem corruption. Then you can move your stuff back with btrfs replace again when you are done.
The truth is, I don’t know if that would solve the issue or not. It might be worth a shot, but it is hard to say if a corrupted filesystem can be reliably moved in the first place. If you are prepared to backup your data and reinstall, that may be a cleaner solution.
The most common cause of filesystem corruption is improperly unmounting the drive, such as during a power loss or a forced shutdown. Has anything like that happened recently?
The drive could also be failing, if it is old or has gone through too many write cycles.
Also try mounting the drive in recovery mode, apparently this can deal with some issues: mount -t btrfs -o recovery,ro /dev/<device_name> /<mount_point>
