I also recommend dd on a live USB, but with some advice.
First off - and I'm really surprised nobody's warned you - be EXTREMELY CAREFUL with dd; it is a very powerful tool, but with great potential for data loss. Check your command over and over again to make sure it's doing what you want before running it, and make sure you have a backup beforehand; it will happily mow over any disk you tell it. Also, do it when you're fully awake, not at 1 AM or something.
I would call myself an experienced dd user, and even I messed up once recently; I was trying to create a bootable USB when I was really tired. Instead, I overwrote a drive. Luckily, it wasn't my root drive, and I had a full backup of its contents, so I was able to reformat the drive and restore from backup.
Also, don't run a bare minumum dd command like dd if=/dev/whateverdevice1 of=/dev/whateverdevice2; it's going to be an absolute pain in the rear.
bs=1M: The size of block it tries to copy at a time. Play with this a bit, as different drives have different optimal block sizes.
oflag=sync: Basically, most operating systems don't actually write data to the drive right away, but store it in a buffer in RAM to be written later. This is usually fine, but sometimes, you want to be certain that data has actually been written to a drive; this flag turns off that buffering so that when dd is done, the data will for sure actually be on the drive. In lieu of this, you could also just run the sync command afterwards, which forces it to write the current buffer to disk, but I prefer the dd way. It should also do it automatically during shutdown, but I have had cases where a system hangs during shutdown and I'm not certain if syncing is done or not.
status=progress: Gives the command a progress bar. It's just really darn convenient and allows you to see how much time is left, how fast the drive is going, etcetera. I don't know how anyone uses dd without this. Otherwise, it just shows nothing, and you're left anxiously wondering when it will be done.
if is input drive, of is output drive. I prefer lsblk for looking at the list of drivers.
You'll usually need to run dd with sudo.
Once you do a successful copy, you'll need to extend your BTRFS partition using GParted or similar. If you have a partition after your main one, like swap, you'll need to delete the swap partition before extending, then recreate the swap partition and update fstab accordingly.
It's nice that they still put out Trek physical media.
It's just really weird that SNW stuff seem to be the franchise's only 4K Blu-Ray releases (besides film remasters and Kelvin timeline, of course) - everything else with a decent resolution has only been released in 1080p. Like, objectively, I can hardly complain about 1080p, and any more than that for LD and PRO is probably pointless, but it's really weird that PIC and DIS don't have it for the seasons that were filmed for 4K.
Also, if they're not going to renew PRO, can they at least give it the dignity of a complete series set, or at the very least a season 1 Blu-Ray so I don't have to buy episodes 1-10 and 11-20 separately?!
Also, depending on the time of year, some E series models can drop to pretty low prices on clearance. E series used to suck, but they've upped the build quality and they're pretty good budget Thinkpads now. Most things should be swappable (check Hardware Maintenance Manual to be sure), so back in 2024, I was able to snap an E16 gen 1 with 8 GB RAM 256 GB and upgrade it to 24 GB RAM, 2 TB storage for not too expensive.
The really nifty thing about the E16s is they have dual NVME drive slots; I just kept the OEM 256 GB drive in it and eventually threw a Windows 11 LTSC install on it, as I unfortunately have to use Windows to do a few assignments, which luckily only come up every couple weeks, usually.
I'm agreeing with other people; there's probably a drive issue that the shop didn't catch.
On my machine, those two services that take 30 seconds for you do not take nearly that long for me. dev-mapper-DebianVolume\x2dDebianMain.device (which is equivalent to dev-mapper-data\x2droot.device; our drives are just called different things) only takes 1.074 seconds for me, while lvm2-monitor.service only takes 357 milliseconds.
I've only ever seen Linux boots take this long when either a drive failed or I accidentally formatted a drive that's in my fstab, causing it to fail to mount and eventually landing me in a recovery shell. At that point, I'd either use the recovery shell or a USB to edit the fstab.
Next time you boot in, check to see if all your drives are showing up, check disk health, etcetera. Also, although this likely won't solve the problem, check that your drive connections are well-seated.
Actually, I think Sam Eagle would be a better Worf; he has a more serious demeanor, and it’d be funny to watch him have to correct himself to say “the Klingon way.”
Of any main character in the whole franchise, Animal would probably make a better Shaxs, but we’re focused on TNG.
This is a relatively new CPU. You might struggle on Ubuntu as well. As much as I love Debian, something like Fedora might be better.
It may be possible to get Debian running, though - either run Debian Testing or install a Backports kernel and Mesa. Were you failing to boot Debian, or did you just struggle after getting it installed?
A suggestion: if you can't find anything else for them, keep them around as parts machines.
There should still be useful components in them. For instance, a lot of the Wi-Fi modems may still be perfectly good for other things as long as they're mini-PCIE (I don't know if they use those in desktops). They may not be the absolute newest standard, but should still do the trick; it certainly came in handy when my sister's laptop's Wi-Fi modem decided to be a brat - I just swapped in an Intel modem from a laptop from 2016.
I might not fully trust the SSDs or the HDDs, but they can still have their uses. There's one SSD from an old desktop that I currently have hooked up to my Wii U.
From what I can tell, people have supposedly run LLMs on it with not great, but not necessarily horrible results; Certainly has to be better than those clickbait posts about people running llama on Windows 98.
A lot of budget desktops from the past decade can at least match, if not significantly outclass a Raspberry Pi 5. Heck, that barely beats my i5 from 2009, and the performance of CPUs has increased significantly since then.
Then again, I'm not particular interested in gen ML, self-hosted or not, so I don't really care.
Although seem to have solved your main issue, I have a few comments on your Steam Run command.
For one, I think VK_DRIVER_FILES=/usr/share/vulkan/icd.d/nvidia_icd.x86_64.json and your prime-run command are redundant - both of those will do the same thing. Personally, I use neither of those and instead do something like DRI_PRIME=1 %command% (obviously not this exactly always, as there might be other flags, but roughly the idea).
In general, I’d just recommend seeing which of these command flags you really need, because I see people in ProtonDB getting away with much simpler launch commands.
For the record, I rationally hate AI*, and this title already raises suspicion for me.
"AI" is a buzzword, and seeing it in the title or slogan for project or product reeks of some business major jumping on a bandwagon that they don't truly understand, and where there's business majors, there's probably encrapification.
*: Of course, one of the big problems is "AI" is a misnomer - there's no "Intelligence" to it. "ML" is closer to capturing the nature of the technology without ascribing to it some magic power that it doesn't have.
I also recommend dd on a live USB, but with some advice.
First off - and I'm really surprised nobody's warned you - be EXTREMELY CAREFUL with dd; it is a very powerful tool, but with great potential for data loss. Check your command over and over again to make sure it's doing what you want before running it, and make sure you have a backup beforehand; it will happily mow over any disk you tell it. Also, do it when you're fully awake, not at 1 AM or something.
I would call myself an experienced dd user, and even I messed up once recently; I was trying to create a bootable USB when I was really tired. Instead, I overwrote a drive. Luckily, it wasn't my root drive, and I had a full backup of its contents, so I was able to reformat the drive and restore from backup.
Also, don't run a bare minumum dd command like
dd if=/dev/whateverdevice1 of=/dev/whateverdevice2; it's going to be an absolute pain in the rear.dd bs=1M oflag=sync status=progress if=/dev/whateverdevice1 of=/dev/whateverdevice2bs=1M: The size of block it tries to copy at a time. Play with this a bit, as different drives have different optimal block sizes.oflag=sync: Basically, most operating systems don't actually write data to the drive right away, but store it in a buffer in RAM to be written later. This is usually fine, but sometimes, you want to be certain that data has actually been written to a drive; this flag turns off that buffering so that when dd is done, the data will for sure actually be on the drive. In lieu of this, you could also just run thesynccommand afterwards, which forces it to write the current buffer to disk, but I prefer the dd way. It should also do it automatically during shutdown, but I have had cases where a system hangs during shutdown and I'm not certain if syncing is done or not.status=progress: Gives the command a progress bar. It's just really darn convenient and allows you to see how much time is left, how fast the drive is going, etcetera. I don't know how anyone uses dd without this. Otherwise, it just shows nothing, and you're left anxiously wondering when it will be done.ifis input drive,ofis output drive. I preferlsblkfor looking at the list of drivers.You'll usually need to run
ddwithsudo.Once you do a successful copy, you'll need to extend your BTRFS partition using GParted or similar. If you have a partition after your main one, like swap, you'll need to delete the swap partition before extending, then recreate the swap partition and update fstab accordingly.