Have you looked through the kernel logs? dmesg will usually show something relevant when wakeup from sleep is malfunctioning, and may show something about the USB charging as well.

So the patch is just copying the existing warning to a standard location?

~/src

If it runs Linux, definitely

Basically all of them

That’s crazy, I would never have expected that. Good to know!

Makes me wonder if Linux is playing nice with Microsoft or there is a mechanism to block device access.

This script? https://github.com/WeirdTreeThing/chromebook-linux-audio

I’m not familiar with bootc based systems but it looks like you could hack up the container spec here: https://codeberg.org/HeliumOS/bootc to build heliumOS with those changes. You would then use something like bootc switch ... to use it.

(Add a line in the docker file to install newer python and run the audio script. I’m not sure if the script requires changes for this.)

I could be way off base with this idea, I’m not sure how heliumOS expects users to install packages.

You may also be able to run the latest python docker image to run the script, but the way this script modifies system files shouldn’t work on an immutable system.

Really just a guess but since others have pointed to bios raid stuff this may be relevant:

https://wiki.debian.org/DebianInstaller/SataRaid

But also you probably want to disable raid in bios if it’s enabled.

Probably something in the bios

Locks as far as windows will not be happy that you changed them. If you’re getting rid of windows don’t worry about shutting down safely.

Do you not have root access or are you worried about using root access? Sudo will do the trick, you don’t need to login as root directly.

Copying the whole image onto the device file will rewrite the partition table, boot flags and all.

But yes, usually this requires root equivalent capabilities.

🤣 damn I would’ve been looking for a new image to flash at that point.

I’m glad chatGPT didn’t brick your system.

Where’d you get the audio setup script?

I think the key to this idea is that as long as the VPN only apps are running in docker containers, container networking can be used to restrict their traffic to the vpn.

Apps like qBittorrent support proxy connection options for this scenario without containers.

https://github.com/qbittorrent/qBittorrent/wiki/Explanation-of-Options-in-qBittorrent#proxy-server

Idk if this is actually a good idea, but I would try using a media server like mediatomb to index the files and serve them to Kodi. It’s been a while so I don’t remember if it was mediatomb that did the organization or not.

Considering how much faster my CPU is than my ram, even though they are both 12 years old, I should do this 😹

Great post!

I would definitely try using photorec if you have specific files you hope to find. It may not handle btrfs well but any files stored as a contiguous chunk should be recoverable.

I would also try partition recovery with testdisk but chances are it won’t do much for btrfs.

You can try the steps in this article: https://www.suse.com/support/kb/doc/?id=000018769

Don’t forget to copy your volume if there’s anything super important in there. only a very small part of the volume was zeroed, if tools don’t exist to recover the data now, they will eventually 😅

Imho it will be much easier to replace blobs with verifiably correct blobs or add the source to build them than to retroactively find the original builds from whence they came.

Searching for some of those binaries looks like it would require comparing the hash against a large set of candidates which would need to first be unpacked from releases (fedora mostly???) and hashed unless the hashes already exist somewhere.

ancient aliens

It’s deja vu all over again 😹

So can grub. Actually ventoy is built on grub