Mis-adventures is more like it 
TLDR at the end…
So yesterday I finally had the chance to start installing software that is NOT in the repos and I ran across a couple issues that completely derailed me for several hours - and I just have to share them.
Program 1 was kakoune - a terminal text editor I’m starting to play around with. Download the code, compile, awesome. Works great. Run it as “sudo” to edit fstab and I get “command not found”. Huh, that’s weird. Alright, obviously it’s a permissions issue or something stupid like that so I’ll deal with it later. Move on.
Program 2 (and a much more critical one for me) is mergerfs. Now mergerfs has both the code AND a static linked binary that you can just copy over and run (sorta like an appimage). So I try that one first. Extract the tarball and run it. It complains that it’s not running as root but that’s ok. It runs 
So to fully test it “sudo mergerfs blah blah blah” and command not found. This again. 
Fine. Where’s the file? /usr/local/bin
“sudo /usr/local/binmergerfs blah blah blah”
works flawlessly
Shut down the computer because I’ve got to go to a client.
Finally sit back at my desk at 10pm. Boot up, black tty screen after grub. Something about root, maintenance mode, journalctrl and retry. Well, retry. Same - black tty screen after grub.
OK. Log into root at the tty and run “journalctrl -xb”. Wall of text. Obviously this is not going to work.
Now remember, in my mind I have done nothing that should have caused this. So I’m thinking hardware failure at this point - and this is my final round of testing on hardware with OM - on my daily driver system (in a separate partition). 
Reboot the machine. Can I get into Mint? Yup. No issues. Whew! I’ve already got the OM partition loaded in my Mint fstab so I can go in there and I can see everything. But what do I know? everything looks fine.
Reboot into the OM tty as root and this time run “journalctrl -xb > journal.txt” Just to be sure run “dmesg > dmesg.txt”
Back to Mint, open the files and search. USB drives didn’t load. Not the end of the world but still not good. Easy to test. Next I find this (and a bunch more like it):
A start job for unit dev-zram0.swap has finished with a failure.
So now I’ve got Xed with the journal.txt on the main monitor and Nemo (the Mint File manager) open to the OM Root dir on the other and I’m hoping to catch a break cause I’m lost. I start randomly clicking into directories in OM and notice that sbin only has 1 file in it - mergerfs.
A candle is lit.
I look in the tarball for mergerfs. It dumps a file in sbin. I open my OM virtual machine and I see that sbin is a symlink (to /usr/bin). 
Ladies and gentlemen I think I found the problem. I reset the link and Voilà! System boots up and runs normally (meaning I can seemingly run various programs). Even mergerfs!
Except I keep getting that “command not found” error. It’s 1 am and I’m annoyed.
kak fred.txt works
sudo kak fred.txt fails
sudo /usr/local/bin/kak fred.txt works
mergerfs runs
sudo mergerfs fails
sudo /usr/local/bin/mergerfs works
add a “hello world” bash script to /usr/local/bin and get the exact same results
. . .1 hour later. . .
check the $PATH (that’s all that’s left): echo $PATH
= = = = = = = = = = = = = = = = = = = = = = = = = = =
Path for me as user
PATH=/usr/local/bin:/usr/bin:/usr/games:/usr/local/games:/usr/lib/jvm/java-21-openjdk/bin:/home/dude/.local/bin:/home/dude/bin:/usr/lib/jvm/java-21-openjdk/bin
Path for me as root
PATH=/usr/bin:/usr/local/bin:/usr/local/sbin:/usr/lib/jvm/java-21-openjdk/bin
finally in desperation (and because I can’t think of anything else) “sudo echo $PATH” - and I get:
the same thing as my normal path.
My last thought before I just reinstall and hope for better results (while annoying I already know I’ll be doing this - it is a test install after all)
printenv > userenv.txt
sudo printenv > sudoenv.txt
su to root & printenv > rootenv.txt
meld userenv.txt sudoenv.txt
meld rootenv.txt sudoenv.txt
The PATH for me as a user and as root are exactly as you see above. HOWEVER the PATH for “sudo” is:
PATH=/usr/sbin:/usr/bin:/sbin:/bin
This is called a “secure path”.
sudo nano /etc/sudoers
add /usr/local/bin to path <== now a “less secure path”
Everything runs perfectly.
Good night boys and girls.
TLDR:
- Always keep another bootable distro handy (usb, another partition, etc) as a debugging tool
- Sudo and Root are NOT the same thing
- Before extracting a tarball make sure it’s not going to overwrite something important
Now to see if I can get snapraid working…