@kilo
How is that /opt/intel/oneapi/compiler/2023.0.0/linux/lib/libOpenCL.so installed?
Is there something referencing it under /etc/OpenCL/vendors/? libOpenCL.so(7) — Arch manual pages
edit: I mean, which package owns it, looks like it's one of the community/intel-oneapi-something.
And for instance I see Arch Linux - intel-oneapi-openmp 2023.0.0-1 (x86_64) - File List includes an /etc/ld.so.conf.d/intel-oneapi-openmp.conf (so it's done there, not /etc/OpenCL/vendors/ as I first thought).
The thing is, I think there must be some other way to hide it from Resolve.
Maybe something like LD_LIBRARY_PATH=/usr/lib:/usr/lib64 /opt/resolve/bin/resolve (and possibly other paths, I'm not sure).
No worries, your questions are all relating to scripting so they are perfectly fine here.
Just FYI, there are ways of making a script run with root credentials without prompting for a password. However, doing so is not particularly secure. You can do this by using the visudo command to edit your /etc/sudoers file. You can use the NOPASSWD option to allow running your script with root permissions (use with caution). I generally never do this myself as I'm very security conscious.
In the past I have used tmux to execute commands in the background using pkexec. This will not open a terminal window to run your script, it will simply open a password prompt box for you to input the root password and the script will be run in the background. Tmux is an awesome terminal multiplexer with many uses, and I highly recommend checking it out.
Please don't ask me to explain these methods in detail, as I haven't used either method in a long time and the details are somewhat fuzzy. If you do some research I'm sure you'll find some info on ways to accomplish what you are looking to do. The biggest reward is in finding the answers yourself when it comes to bash scripting. The more you investigate, the more cool things you'll find you can do with bash.
Those are what tells the dynamic linker how to find the libOpenCL.so in /opt/.../lib. They should be very short, can you post their contents here? nevermind, I dl the package.
Great thanks . Wasn’t sure if I was taking it off the rails here.
I did previously see about adding the file to sudoers, but that seemed odd to me. I didn’t really want to go that route.
tmux, however, is something I haven’t had a chance to look into yet. I’ve used screen, and I read shortly that it’s pretty similar. I will definitely take some time to research this soon.
No need to explain, pointing me in a direction is more than enough, and much appreciated. I found some work arounds, but I need to research a bit more. I feel like there’s no shortage of learning on Linux, and that’s entertaining for me. I only wish I started using it sooner.
No problem, here's the idea:
copy the /etc/OpenCL/vendors directory somewhere, remove intel-oneapi-compiler-shared-opencl-cpu.icd from the copy, run Resolve with the OPENCL_VENDOR_PATH environment variable set to the "sabotaged" copy, cross fingers.
Beware that future upgrades may touch the other .icd files, I don't know if the ones in the "sabotaged" copy can be replaced with symlinks, let's see if it works first.
edit: will likely need to sabotage the other one too with LD_LIBRARY_PATH.
Wait, LD_LIBRARY_PATH works differently, like PATH: a colon seaparated list of directories.
It’s normally unset, so you’ll have to find out what the search path actually is,
but first try with only the OPENCL_VENDOR_PATH, maybe it’s enough.
Thanks for taking the time here to help me out, appreciate it. I should be in bed though . Going to call it quits here for now. G'night, I check back in the mornin'. (Okay, probably past noon if I'm being realistic..)
not `/etc/ld.so.conf.d-sabotaged/:$LD_LIBRARY_PATH` (rm that directory, it will never work).
edit: and neither my way ever will. sorry for wasted time, it was worth a shot after all.
found time for explanation: the OPENCL_VENDOR_PATH thing had some hope but I was wrong thinking LD_LIBRARY_PATH would replace the default search path, it can only add to it.
Perhaps I’m onto something with ldconfig though.
No need to apologize, was worth a shot as you said. The thinking process here is interesting, I wouldn't have thought of something like that on my own. Fortunately the initial script posted solves my issue with Resolve, but still fun to explore other ways and learn a bit in the process.
There are much more advanced options already existing, but I wanted it the most KISS as possible.
It's also tolerably fast.
Only standard tools used: bash, date, uname, file, grep, sed, awk, paste, column, and /proc files.
No attempt at restarting services, not even mapping processes to service names.
Not well tested, likely to miss something and crap out in some cases, standard disclaimer applies.
Intended to run with sudo else only user processes are listed.
Can be called from command line or sourced for the functions.
Reports running and installed kernel versions, last update to /boot, running updated binaries.
reboot_test.sh
#!/bin/bash
last_chboot() { date -r /boot +%s; }
last_chboot_hr() { date -r /boot +'%F %T'; }
last_reboot() { date -r /proc +%s; }
last_reboot_hr() { date -r /proc +'%F %T'; }
upgraded_boot() (( $(last_chboot) > $(last_reboot) ))
upgraded_boot_hr() { upgraded_boot && echo yes || echo no; }
currently_booted_image() { grep -Po 'BOOT_IMAGE=/@\K\S+' /proc/cmdline; }
currently_running_kernel() { uname -r; }
currently_installed_kernel() { file $(currently_booted_image) |grep -Po 'version \K\S+'; }
currently_installed_kernels() { file /boot/vmlinuz* |grep -Po 'version \K\S+' |paste -sd' '; }
upgraded_running_kernel() { [ $(currently_running_kernel) != $(currently_installed_kernel) ]; }
upgraded_running_kernel_hr() { upgraded_running_kernel && echo yes || echo no; }
# NOTE: $1=pid $6=pathname $7="(deleted)"
awk_uniq_del_paths_simple() { # unused, no command / user name, only pathname and list of pids
awk '$6 && $7 {pathpids[$6]=(pathpids[$6] " " $1)} END { for (pp in pathpids) print pp " " pathpids[pp] }';
}
awk_uniq_del_paths() {
awk ' $6 && $7 {pathpids[$6][$1]=""}
END {
for (path in pathpids) for (pid in pathpids[path]) {
getline uid < ("/proc/" pid "/loginuid")
("id -nu " uid) | getline user
getline comm < ("/proc/" pid "/comm")
print pid " " comm " " uid " " user " " path
}
}
'
}
upgraded_mapped_executables() {
trap "$(shopt -p nullglob)" RETURN; shopt -s nullglob
local p
for p in /proc/{1..9}*; do
sed -En '/^\S+ +..x. .*[^]]$/ {s/^\S+/'"${p:6}"'/;p}' "$p/maps" 2>&-
done |awk_uniq_del_paths
}
upgraded_mapped_executables_hr() {
echo # just to simplify printing function names and results
upgraded_mapped_executables |column -t -N'pid,comm,uid,user,path' -R1,3
}
return 0 2>&- # exit if sourced
for fn in currently_{booted_image,running_kernel,installed_kernel{,s}} last_{ch,re}boot_hr upgraded_{boot,running_kernel,mapped_executables}_hr; do
printf '%-32s : ' "$fn"; $fn
done
example output
(I reinstalled mpg123 and rebuilt initramfs)
currently_booted_image : /boot/vmlinuz-linux-zen
currently_running_kernel : 6.2.10-zen1-1-zen
currently_installed_kernel : 6.2.10-zen1-1-zen
currently_installed_kernels : 6.2.10-zen1-1-zen
last_chboot_hr : 2023-04-13 16:41:59
last_reboot_hr : 2023-04-12 22:13:36
upgraded_boot_hr : yes
upgraded_running_kernel_hr : no
upgraded_mapped_executables_hr :
pid comm uid user path
907 waybar 1000 meanruse /usr/lib/libmpg123.so.0.47.0
27794 firedragon 1000 meanruse /usr/lib/libmpg123.so.0.47.0
________________________________________________________
Executed in 1.77 secs fish external
usr time 1.11 secs 0.75 millis 1.11 secs
sys time 0.69 secs 3.02 millis 0.69 secs
May do as a quick reminder, beware it's far from being dependable.
Does this actually do anything different from the 'reboot required' check my 'upls' script does? (looks through the updates to see if any are likely to recommend a reboot) It isn't all that reliable either! A certain tendency to over-suggest a reboot, I suspect....
Here is my updates-checker function I hide in .bashrc
upls
upls2() {
local updatesAUR=$(yay -Qua)
local updates=$(checkupdates)
# output RESULT
if [ -n "$updates" ] || [ -n "$updatesAUR" ]; then
echo "Repo packages"
echo "-------------"
{
echo "$updates"
} | column -t -N Name,Current,"->",New
echo " "
if [ -n "$updatesAUR" ]; then
echo " "
echo "AUR Packages"
echo "------------"
{
echo "$updatesAUR"
} | column -t -N Name,Current,"->",New
fi
#check for core system packages
RUN_KERNEL=$(cat /proc/version | sed 's|.*(\([^@]*\)@archlinux).*|\1|')
CHKLINE="amd-ucode\|intel-ucode\|btrfs-progs\|cryptsetup\|nvidia*\|mesa\|systemd*\|*wayland*\|xf86-video-*\|xorg-server*\|xorg-fonts*"
CHKLINE+="\|""${RUN_KERNEL}"
echo " "
echo $updates | grep -q ${CHKLINE} && echo "Reboot will be recommended due to the upgrade of core system package(s)." || echo "No reboot recommended after this update."
else
echo "No pending updates..."
fi
}
Edit: I swapped out the version I first posted for the faster (and more general) version here now. It uses checkupdates rather than checkupdatesext, which is an EndeavourOS enhancement, but runs slower... Oops!
It works fine, but if I am testing a batch of ISOs I do get tired of typing it over and over so I turned it into a simple Bash script.
#!/bin/bash
# Check for a valid number of arguments
if [ "$#" -lt 2 ] || [ "$#" -gt 3 ]; then
echo "Usage: $0 <file1> <file2> [shasum]"
exit 1
fi
file1="$1"
file2="$2"
shasum_type="${3:-sha256sum}"
# Calculate the checksum of file1 and save it to a temporary text file
"$shasum_type" "$file1" > shasumchecker_tempfile.txt
# Open Meld to compare the checksum file and file2
meld shasumchecker_tempfile.txt "$file2"
# Clean up the temporary file
rm shasumchecker_tempfile.txt
You run it like this:
./shasumchecker.sh [ISO file] [sha256 file]
It calculates the shasum of the ISO file, saves it as a temporary text file, then opens the text file and the sha256 file in Meld so you can see if they match or not.
After you close Meld, it deletes the temporary text file.
It defaults to using sha256sum because that’s what we use here with Garuda Linux, but the script will accept a third argument if you want to use a different kind of shasum. For example:
./shasumchecker isofile shafile sha512sum
This will run the script with sha512 instead of sha256.
Throw the script on your Ventoy so you have it handy next time you are ISO testing.
If you have the *.sha256 and the *.iso already in the same directory then doing
sha256sum -c filename-with-sha256extn.sha256
It will handle this for you. No need for piping it to meld. Eg;
ls
.rwxr-xr-x 2.7G siddharth 1 Oct 12:40 garuda-dr460nized-linux-zen-230501.iso
.rwxr-xr-x 105 siddharth 7 Oct 20:30 garuda-dr460nized-linux-zen-230501.iso.sha256
.rwxr-xr-x 2.6G siddharth 1 Oct 13:36 garuda-hyprland-linux-zen-230929.iso
.rwxr-xr-x 2.5G siddharth 1 Oct 14:53 garuda-sway-linux-zen-230501.iso
.rwxr-xr-x 99 siddharth 7 Oct 20:31 garuda-sway-linux-zen-230501.iso.sha256
and the .sha256 file contents
cat garuda-dr460nized-linux-zen-230501.iso.sha256
File: garuda-dr460nized-linux-zen-230501.iso.sha256
2f11596a236eb0a401f4c5045e325c01d54e94701a147dd8a8679f1754b94726 garuda-dr460nized-linux-zen-230501.iso
╭─siddharth@siddharth in /run/media/siddharth/Ventoy took 25ms
23%
╰─λ cat garuda-sway-linux-zen-230501.iso.sha256
File: garuda-sway-linux-zen-230501.iso.sha256
4c7db96607308af5ccfc8986f2cc9eb1d8f9eb0cb8f13dba81e199993e8917bc garuda-sway-linux-zen-230501.iso
no changes downloaded straight from garuda website.
Now, I run this command
sha256sum -c *.sha256
and it automatically both calculates the sha256 for required ISO and performs checking on it. I did not have the sha256 for the hyprland ISO so it didn’t bother checking it.
garuda-dr460nized-linux-zen-230501.iso: OK
garuda-sway-linux-zen-230501.iso: OK
Edit:
The .sha256 extension is not a mandate for this command to work. It can be any text file its the contents of the file that matter. The file should contain the sha256 followed by the name of the file it’s been calculated for like the example above. There can be several such sha256 sums in a single file as long as they follow the correct formatting this command will work.
PS: yes this works for other hashing commands as well like sha512sum, sha1sum, etc.
. Wasn’t sure if I was taking it off the rails here.
. Going to call it quits here for now. G'night, I check back in the mornin'. (Okay, probably past noon if I'm being realistic..)
Have a nice sleep. I’ll be away for a while.
A certain tendency to over-suggest a reboot, I suspect....
