I appreciate the writeup and that you’ve taken the time to post about it here, however I am 100% leery of managing remote access or credentials using closed source software. I’ll definitely keep an eye on the project, but it’s a hard pass for me until the app is fully open source.
I’m relatively new to Mint, but I thought that sudo apt update just checked for updates and sudo apt upgrade -y was for actually installing the updates. I don’t see why that would break it though.
Dang, similar stuff happened to me on nixos. Had to instruct one of the relatives on how to reboot the machine and choose a previous generation in the boitloader 🤣
Ok, update. I removed some improper repos that the amdgpu-install had installed and I got things mostly working. Only problem is that rendering in Blender on GPU crashes it and I can’t seem to get good logs for the problem. I will try to get some logs and post them here.
Thanks for putting this out for public benefit! I haven’t messed around with MacOS much but the things you’ve mentioned are nice to know.
I believe that’s a shell/bash standard variable, but I need to learn where it came from and how it works
You may know this already, but I’ve found the man (as in manual) utility to be one of the most useful things in GNU/Linux user space. I don’t have much insight into ‘${file##*/}’ off the cuff, but I can tell you there’s manual entries for file, sh, and bash that may help you track it down.
<span style="font-style:italic;color:#969896;"># simply type man [some-command]
</span><span style="color:#323232;">man file
</span><span style="color:#323232;">man sh
</span><span style="color:#323232;">man bash
</span><span style="color:#323232;">man man </span><span style="font-style:italic;color:#969896;"># very useful for getting started!
</span>
Manpages are local to your system so they’re extremely fast to pull up and searchable!
Here’s some online info on man if you’re interested:
Yes, thank you! The man pages have been a huge help as I’m working through things. Sometimes I don’t know enough to understand what the man pages are telling me, and then I usually end up on stack exchange looking at a command example that someone has helpfully broken down.
It’s definitely a skill that I haven’t mastered either! That being said I think it’s one of the pillars of being a bonafide “super user” and I’d like to set there one day :)
Maybe I’ll take inspiration from this post and write something up about what I learn in the future about manpages.
You’re welcome! I stumbled across Multipass when I was looking for virtual machine options for the m1 mac mini I’m working on. I specifically was trying to get away from using the mac coreutils for a consistent syntax experience, and Multipass has been working perfectly for that.
It was only after I’d been using Multipass already that I stumbled across that script, and planned to take a look at it to possibly implement on my machine. I didn’t realize that Homebrew allowed for replacing the coreutils with the GNU versions. Another thing learned!
I had rEFInd and GRUB installed entirely by accident, and a botched update for Arch hosed my entire EFI setup making it impossible to boot Linux or Windows w/o a LiveCD. Thankfully it self repaired once I nuked rEFInd. I ended up going back to Ubuntu, but I hate snaps. I still would recommend Arch for most Linux users who want the power windows.
Also, if I basically remove everything, I will get this error:
`[aapo@aapo-fedora ~]$ amdgpu-install [sudo] password for aapo: ROCm 5.4 repository 154 kB/s | 208 kB 00:01
AMDGPU 5.4 repository 699 B/s | 548 B 00:00
Errors during downloading metadata for repository ‘amdgpu’:
Status code: 404 for repo.radeon.com/amdgpu/5.4/rhel//…/repomd.xml (IP: 13.82.220.49) Error: Failed to download metadata for repo ‘amdgpu’: Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried Ignoring repositories: amdgpu Last metadata expiration check: 0:00:01 ago on Tue 23 Jan 2024 03:47:14 PM EET. Package amdgpu-lib-1:5.4.50400-1510348.el8.x86_64 is already installed. Package amdgpu-dkms-1:5.18.13.50400-1510348.el8.noarch is already installed. Error: Problem: package rocm-hip-runtime-5.4.0.50400-72.el8.x86_64 from rocm requires rocminfo = 1.0.0.50400-72.el8, but none of the providers can be installed
conflicting requests
nothing provides /usr/libexec/platform-python needed by rocminfo-1.0.0.50400-72.el8.x86_64 from rocm (try to add ‘–skip-broken’ to skip uninstallable packages) [aapo@aapo-fedora ~]$ `
I once did an apt-get upgrade in the middle of when debian testing was recompiling all packages and moving to a new gcc version. I get it, using testing invites stuff like this. But come on, there should at least be a way to warn people beforehand.
Car: Hey, your car is going at 60 mph now. Do you want to change your tire now?
Me: Is it not possible?
Car: It’s your car, anything is possible with enough effort. As per Google one guy managed to change a tire of a bullock cart while it was moving at 2 mph.
In my personal experience, these sort of things happen rarely, unless you are using some sort of rolling-release distribution. For all my mission-critical docker apps, I wait for at least a week after a major update has been pushed and check the dev website.
linux
Newest
This magazine is from a federated server and may be incomplete. Browse more on the original instance.