Eyy we’re doing the best we can out here

never click this button, keep the ai sloppy

Mainly tmuxor screen keep sessions alive on the remote server, so processes don’t get killed when I disconnect.

run photorec on it after trashing the luks header if you want to be sure

Time to switch back to screen :P

Because sometimes (or always) you’re using the terminal multiplexer on a remote machine over ssh with no graphical session

I used to do this as well, and tell Linux to never overcommit, but for a desktop system normal programs are not built for this scenario. Firefox will crash with 15% system ram usage because it requests a ton of virtual memory for each process on startup.

Swap can also be important if you want to get the most out of your ram because without swap, pages that are holding unimportant parts of the system can’t move out of the way for a large number of data pages that need processing. My latest memory revelation is zswap, which seems to be better than actual compressed memory. So far it’s served me well running ML loads on old hardware.

Alternatively, the chickens are pets, eggs are 100% profit 😅

Thoughts and prayers go out to the innocent shell processes killed in the crossfire

Don’t forget the poor shell process reaped along with it );

Afaik, those by-* paths are symlinks created by udev during boot (before switching to the real root fs) The kernel creates the actual device files directly in /dev. My guess is that Windows left an NTFS volume in an unmountable state or something and udev got stuck processing this disk before processing rules for your boot disk. This probably requires you to have a fstab entry for mounting your windows disk, but I’m not sure.

When you boot into a live distro again (I know you’re done, but maybe someone else has this problem) check if the disk has a block device file directly in /dev. Maybe check the other disk, see if you can mount it or remove references to it in fstab or unplug the device entirely.

That frog is about to have its bones drank

Totally unrelated, but I just want to say that my 14 TB sas drive (exos?) was brought back to life in a 12 TB configuration after failure by using openseachest to deactivate one side of one of the platters (the failing one, it was the only one with errors) after I told it to start it took 4 days to reformat, most of that time reporting no progress, but finally finished and now it works great!

Definitely has a chatbot amount of enthusiasm :l I’m 50/50 on AI writing this

The easy thing is to just format them ext4 and use them as extra data storage.

Edit 2: don’t delete the efi partition!!! Move that just like your system partition. Unless you want to learn how to rebuild it :) unless you’re using Windows boot manager you can remove the Microsoft folder from the efi partition as well

The good news is your system partition is small so you can delete the first two partitions. Make a small boot partition if you want, make a new system partition second ( bigger than your current one), copy the existing system partition into the new one (without deleting the old one), boot into the new system partition, test that it works, then expand the fs to fill the partition. Then you can move your home partition if you want or just make your system partition huge to fill the space up to your existing home partition, then delete the last partitions an grow your home partition to fill the disk

Edit: once you know the new system partition works you delete the old one.

There are some ideas here:

https://bbs.archlinux.org/viewtopic.php?id=283906&p=2

I think the key line is SATA link down (SStatus 4 SControl 300)

Can you post your dmesg output from booting a live USB? Maybe there will be a clue in there.

How is this ssd connected? Nvme? Sata?

I’m a btrfs noob, so I’m skipping any tools that may fix the disk, try those first.

If the media isn’t dying, try a file carving tool like photorec. Idk if testdisk supports btrfs but it’s worth a try, it’s my go-to for undelete and finding lost partitions.

Edit: missed most of your post. First you need to check the kernel logs using the dmesg command. Look for errors that may explain why the disk doesn’t show up, especially if it lists scsi or sata in the message.

Edit again: you may want to check the disk’s self reported heath using “smart” data. Many bios menus show this info, and there are programs to get it on Linux. If there are too many read or write errors, you need to decide how important the data is. Professional recovery can probably get all of your data if you stop using the drive now and send it in. DIY recovery using a file carving tool would work best if you have another disk to make an image of the failing one with. ddrescue would be the tool for the job to create the image. If you don’t have another disk large enough, and the files aren’t super important, you can run file carving on the failing disk directly, but the more you use it the greater chance the disk will corrupt more data.

A what?

It freaks me out, but these days with nvme disks this is actually true