What hardware? And can you narrow down when during updates?
I had this problem on Arch on a 5 year old Lenovo laptop with an Nvidia 1660ti GPU. With judicious use of set -x I narrowed it down to systemd daemon-reload.
I actually changed my ext4 journal mode and added a pacman hook in that calls sync before any systemd hooks ran, after the second time half of the package updates got lost due to the freeze.
Because the problem only happened most times, and usually not soon after a reboot, I can’t prove it, but the problem hasn’t reoccurred since I switched the Nvidia driver to the open flavor.
It’s a 2021 Asus Zephyrus G15 with an AMD CPU and an Nvidia GPU. I got an aftermarket SSD off of Amazon so I could dual boot with Windows, but I haven’t booted back into Windows a single time since installing Linux. Though that might be a good test.
I can try set -x once I reinstall my distro and get it back up and running tomorrow, as it is currently borked. Since zypper does all the downloads then all of the installs, I was able to see that it always happened during the install phase, not the download phase.
I am definitely interested in the possibility of it being related to the proprietary Nvidia driver. When it happened yesterday, the proprietary Nvidia driver was being updated (not sure at that exact time. But it was in the list of packages to be updated). I’ll keep an eye on that for sure.
I had a similar problem with hard lockups especially when doing package updates (Arch). After seeing a report on Gaming on Linux about the Nvidia 550 driver (I think it was that one) causing freezes, I uninstalled it and just ran on the intel igpu. Never had a single freeze again. Waited for 555 driver, installed that, and immediately got lockups during package updates (and randomly sometimes) again. I’ve now installed the nvidia-open package to see if it fixes it, and so far so good.
Well, I reinstalled this morning and I’m keeping the nouveau driver this time instead of going with the proprietary. I don’t play play games on this laptop anymore since I set up sunshine/moonlight, so it shouldn’t be a problem.
Distrobox will resolve your issue with VSCode and then some. Run archlinux, debian or whatever you want as a container. Then, install VSCode/VSCodium (and any other apps that Chimera lacks) inside the container OS. This will keep your development environment containerized and safely away from your host OS.
Got a bit freaky with a friend once. I used the cucumber on her. We both ate it after. Don’t leave that shit for other people to eat. As long as they have common sense, you should be fine.
It started with GUI, but I switched to command line, and even did it in a separate TTY to make sure it wasn’t something weird going on with updating plasma from plasma. After switching to Arch-based distros, I have only use CLI.
Currently I’m on EndeavourOS, but after the most recent time this happened, it won’t boot, and I can’t even mount and chroot to it (I get an I/O error message)
No, I’m at about 1% capacity.
I ran this from a live USB, and it came back with no errors detected, but returned instantaneously, so I’m not sure if it ran the right thing. Doing more research on it now. Edit: I did it wrong. The test is running now. Edit 2: Smart says it passed. :/
Yeah, I just ordered a new SSD. I’ll give that a try when it arrives tomorrow. Smart says it passed, but suspect my SSD enough that I think it’s worth it to just try another SSD.
I don’t have any new communities to advertise, but just wanted to send out a reminder, that you should view your home page on scaled sort or new every now and then after subbing to these small communities. It helps them show up more when they don’t have as many up votes as the big ones.
Atom feeds are widely supported (it's how I found this post!) and there are many libraries/apps/plugins for aggregation. Robust old tech. And no need to limit feeds to Git activity if you don't want to :) Good luck!
Even with nvme drives which supposedly “don’t need” to use BFQ, I STILL always swap it since it maintains responsiveness across the system during heavy IO loads. I used to have similar full system freezes when downloading steam games which notoriously overload your IO in Linux. BFQ was the solution every single time.
The second answer that shows an actual rules.d file example has always worked for me. If using nvme or old school spinning rust you’ll need to change it up a bit. Instead of “noop” set it to “BFQ”.
For what it’s worth, I’ve never had to change my io scheduler in the nearly twenty years I’ve used Linux. You can check your current scheduler with the following command: cat /sys/block/sda/queue/scheduler (change the block device to whatever yours is…sda, nvme0n1, etc.).
In my case, it was already bfq: one mq-deadline kyber [bfq]
kbin.life
Newest