i am trying to run hashcat on my Zen Archlinux i am on the 4.15.4-1-zen kernel version. I have an NVIDIA geforce 920MX and an intel i6189DU.
i installed the latest nvidia-dkms drivers and as well as the opencl-nvidia package.
I also installed the latest Hashcat version.
When i run the hashcat command i get this error :clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR.
I used a tool to determin the openCL platforms available clinfo and the output only shows my CPU platform not my GPU yet the hashcat command still outputs the same erro.
Any help ?
Fellow Archer here, I found a way to fix the broken hashcat as you can see:
$ hashcat -b
hashcat (...) starting in benchmark mode...
clGetPlatformIDs(): CL_PLATFORM_NOT_FOUND_KHR
ATTENTION! No OpenCL-compatible or CUDA-compatible platform found.
You are probably missing the OpenCL or CUDA runtime installation.
$ pacman -S clinfo
$ clinfo
Number of platforms 0
One way to fix it is to install pocl (Portable OpenCL is an open-source implementation of OpenCL):
$ pacman -S pocl
$ clinfo
Number of platforms 1
Platform Name Portable Computing Language
Platform Vendor The pocl project
...
$ hashcat -b
hashcat (...) starting in benchmark mode...
OpenCL API (...) - Platform #1 [The pocl project]
=========================================================================================================================
* Device #1: pthread-Intel(R) ...
Benchmark relevant options:
===========================
* --optimized-kernel-enable
Hashmode: 0 - MD5
Speed.#1.........: ...
...
Happy cracking! ( ͡° ͜ʖ ͡°)
Linuxmint 22.1:
sudo apt-get install pocl-opencl-icd
Related
Trying to install openvpn3-client on my amazon Linux followed this documentation, facing below error
Packages skipped because of dependency problems:
openvpn3-13-0.beta1.el7.x86_64 from copr:copr.fedorainfracloud.org:dsommers:openvpn3
openvpn3-client-13-0.beta1.el7.x86_64 from copr:copr.fedorainfracloud.org:dsommers:openvpn3
openvpn3-selinux-13-0.beta1.el7.noarch from copr:copr.fedorainfracloud.org:dsommers:openvpn3
python36-dbus-1.2.4-4.el7.x86_64 from epel
python36-gobject-base-3.22.0-6.el7.x86_64 from epel
I have already installed epel following this
Amazon linux install openvpn3-client & dependencies as per
https://github.com/OpenVPN/openvpn3-linux
See the instructions on
https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux how to
install pre-built OpenVPN 3 Linux packages on Debian, Ubuntu, Fedora,
Red Hat Enterprise Linux, CentOS and Scientific Linux.
1 solution was to switch from AWS Linux (lack of dependencies & updates) to Fedora on AWS. No longer have to build from source / add dependancices,
older versions had to add the repo as per the above.
When I did an upgrade to Fedora 36 the latest openvpn3-linux v18 client was built in. Did not have to manually upgrade / install it:
openvpn3-admin version --services
e.g: previous v17 suddenly stopped working spend 10 hours trying to debug
"Trying to install openvpn3-client" and reinstall:
openvpn3 config-import --config profile.udp.ovpn --persistent
openvpn3 config-manage --config profile.udp.ovpn --enable-legacy-algorithms true --show
openvpn3 session-start --config profile.udp.ovpn
openvpn3 sessions-list
openvpn3 session-manage --config profile.udp.ovpn --disconnect
Actually thinking it was a cipher AES-256-CBC legacy issue that others were having. It was not for some reason, permissions on install of the OpenVPN3 Linux client? as it was NOT creating a TUN.
So I made one myself (that was the actual issue) and it connected after asking for VPN Username & Password, no need to install again / reinstall afterall:
sudo ip tuntap add name tun0 mode tun
sudo ip link show
Other Amazon linux install openvpn3-client issues help is here: https://github.com/OpenVPN/openvpn3-linux/issues?q=cipher
On Ubuntu 20.04, I installed the xv6 project using the page Tools Used in 6.828
$ sudo apt-get install git build-essential gdb-multiarch qemu-system-misc gcc-riscv64-linux-gnu binutils-riscv64-linux-gnu
The file version that they checked on the web page are
$ riscv64-unknown-elf-gcc --version
riscv64-unknown-elf-gcc () 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ qemu-system-riscv64 --version
QEMU emulator version 5.2.50 (v5.2.0-2349-g51db2d7cf2)
Copyright (c) 2003-2020 Fabrice Bellard and the QEMU Project developers
On xv6-riscv
$ make qemu
# ... lots of output ...
qemu-system-riscv64 -machine virt -bios none -kernel kernel/kernel -m 128M -smp 3 -nographic -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk-device,drive=x0,bus=virtio-mmio-bus.0
The program get stuck there. The vm is not booted and no prompt is shown.
Any ideas on how to fix this are welcomed.
This has been mentioned in Tools Used in 6.S081
At this moment in time, it seems that the package qemu-system-misc has received an
update that breaks its compatibility with our kernel. If you run make qemu and the
script appears to hang after
qemu-system-riscv64 -machine virt -bios none -kernel kernel/kernel -m 128M -smp 3
nographic -drive file=fs.img,if=none,format=raw,id=x0 -device virtio-blk
device,drive=x0,bus=virtio-mmio-bus.0
you'll need to uninstall that package and install an older version:
$ sudo apt-get remove qemu-system-misc
$ sudo apt-get install qemu-system-misc=1:4.2-3ubuntu6
So I have tmux installed via arm64 homebrew.
I initially compiled alacritty (my favorite terminal emulator) for arm64 manually, so that's running in arm64 mode. uname -a confirms we're in arm64.
Darwin ndo-mbp.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:10 PDT 2020; root:xnu-7195.50.7~2/RELEASE_ARM64_T8101 arm64
Then I installed homebrew which slowly but surely getting arm64 bottles for most popular applications, including tmux (https://github.com/Homebrew/brew/issues/7857). So I installed that from the arm64 shell, it compiled successfully.
If I run file $(which tmux) I get:
/opt/homebrew/bin/tmux: Mach-O 64-bit executable arm64
However, if I launch that tmux binary in my arm64 alacritty, I seem to land in x86_64 mode. Running uname -a from inside that tmux window I get:
Darwin ndo-mbp.local 20.1.0 Darwin Kernel Version 20.1.0: Sat Oct 31 00:07:10 PDT 2020; root:xnu-7195.50.7~2/RELEASE_ARM64_T8101 x86_64
Any idea what's going on here? I'm relatively new to Mac OS, so maybe I'm missing something obvious.
I had the same problem.
In the end the solution was in the ~/.tmux.conf, add:
set-option -g default-shell /path/to/arm64/zsh
Then kill and restart tmux:
sudo kill -9 [PID of tmux]
tmux
uname -a then returns arm64.
Now that the M1 CPUs have been around for a while and the community has had time to figure things out, I manually cross compiled Alacritty for arm64 as they don't have official binaries yet (Github Actions apparenlty won't build them yet).
But from there, I was in alacritty in arm64 mode (uname -m == arm64 :thumbsup:) and was then able to remove and reinstall brew and tmux the recommended way from their websites.
Followed all instructions and was good to go. I think just having been a bit early and messing around making manual changes here and there threw the whole thing off.
I do have one unrelated problem now however - and that's that tmux won't start as a non-root user. It just immediately crashes haha. When started with sudo, it opens with my expected config and uname -m confirms it is the arm64 version, however I can't get it to start with my normal user. Anyway, problem for another day!
For research purposes, I am trying to run the sqlite3 full test suite.
I am running under Linux for this test.
I believe I have installed the correct libraries
sudo apt-get install tcl-dev tk-dev
And when I run the configure command, it finds tcl
checking whether to use an in-ram database for temporary tables... no
checking if executables have the .exe suffix... unknown
checking for Tcl configuration... found /usr/lib/tclConfig.sh
checking for existence of /usr/lib/tclConfig.sh... loading
checking for library containing readline... no
checking for library containing tgetent... no
checking for readline in -lreadline... no
checking readline.h usability... no
Then when I run make test it ends with:
Time: orderby8.test 5080 ms
Time: orderby9.test 291 ms
Makefile:1201: recipe for target 'tcltest' failed
make: *** [tcltest] Killed
It is hard to tell because your question misses important details:
What *nix exactly?
More importantly, which Tcl versions are installed by apt?
How do you obtain the sqlite3 sources incl. test harnesses?
I just tested fine the following:
Ubuntu Xenial
apt-get install tcl tcl-dev (turns out to be 8.6.7)
wget https://www.sqlite.org/2018/sqlite-src-3250200.zip
unzip sqlite-src-3250200.zip
cd sqlite-src-3250200
./configure && make test
... and it succeeds to complete the make test run:
...
Time: orderby7.test 6 ms
Time: orderby8.test 115 ms
Time: orderby9.test 6 ms
Time: oserror.test 49 ms
...
Time: zipfile2.test 10 ms
SQLite 2018-09-25 19:08:10 fb90e7189ae6d62e77ba3a308ca5d683f90bbe633cf681865365b8e92792d1c7
0 errors out of 147094 tests on builda Linux 64-bit little-endian
All memory allocations freed - no leaks
Maximum memory usage: 9278848 bytes
Current memory usage: 0 bytes
Number of malloc() : -1 calls
It seems that oserror.test crashes whatever Tcl in your case.
what is the command to know the L2 cache size of CPU on Solaris operating system running on Sparc and x86 processors.
I don't have access to a Solaris box to test this out, but you might be able to achieve this using prtpicl.
prtpicl -v -c cpu | grep l2-cache-size
For a more portable option, check out the lstopo command from the hwloc project.
On sparc just run fpversion (/product/SUNWspro/bin/fpversion) and it will print the xcache code-generation options that show the L1 and L2 cache sizes. Then read http://docs.oracle.com/cd/E19205-01/819-5267/bkazt/index.html to understand it.