lldb reports my remote aarch64 paltform as x86_64 (AOSP) - android-source

I'm trying to remotely debug a process on my aarch64 hardware. Why does the triplet start with x86_64? I would expect aarch64
(lldb) platform select remote-android
Platform: remote-android
Connected: no
(lldb) platform connect connect://localhost:5039
Platform: remote-android
Triple: x86_64-unknown-linux-android
OS Version: 30 (5.4.47-07670-gd50c0c10c465)
Hostname: localhost
Connected: yes
WorkingDir: /
Kernel: #136 SMP PREEMPT Thu Nov 26 11:09:46 EST 2020
My Android hardware is aarch64. I pushed lldb-server to the target with
adb push prebuilts/clang/host/linux-x86/clang-r383902b/runtimes_ndk_cxx/aarch64/lldb-server /data/local/tmp/lldb-server
Ran it with:
adb shell /data/local/tmp/lldb-server platform --listen "*:5039" --server
And connected with lldb (from prebuilts/clang/host/linux-x86/clang-r383902b/bin/lldb)
I am able to attach to processes on the target, even list processes (which show x86_64 triplets again to my confusing) but I can't add any symbols files, or target create. Those commands yield arch errors which is what led me back to the triplet in the platform command. (side note, I do build with -Wl,--build-id=sha1 -g -glldb)
When I see tutorials online, they're triplets report arm.
Notes:
Everything is done from the shell (no IDE),
Not running in Docker,
My hardware is rooted and even in permissive mode right now
Everything here is based on AOSP 11
clang tag: clang-r383902b

The cause of this was the clang version I was using, clang-r383902b. Setting my local manifest to pull from master and using clang-r399163b everything worked.
Specifically:
Extend the clang prebuid project in a local manifest
<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<remote name="aosp" fetch="https://android.googlesource.com/" review="https://android-review.googlesource.com/" />
<extend-project path="prebuilts/clang/host/linux-x86" name="platform/prebuilts/clang/host/linux-x86" groups="trusty" revision="refs/heads/master" clone-depth="1" remote="aosp" />
</manifest>
Sync: repo sync -d prebuilts/clang/host/linux-x86
Re-push: CLANG_TAG=clang-r399163b adb push prebuilts/clang/host/linux-x86/${CLANG_TAG}/runtimes_ndk_cxx/aarch64/lldb-server /data/local/tmp/lldb-server (or whatever the newest tag is)
Re-run lldb-server
I experimented with using the newest lldb-server with the existing lldb and it still worked.

Related

CUDA_ERROR_COMPAT_NOT_SUPPORTED_ON_DEVICE when running guppy basecaller

I have tried to run the ONT basecaller guppy. I have run this code several times before without any issues. Now (following a reboot) it is producing the error message:
[guppy/error] main: CUDA error at /builds/ofan/ont_core_cpp/ont_core/common/cuda_common.cpp:203: CUDA_ERROR_COMPAT_NOT_SUPPORTED_ON_DEVICE [guppy/warning] main: An error occurred in the basecaller. Aborting.
Is this a compatibility problem, and if so what can I do to solve it?
I'm using Ubuntu 18.04.4 LTS (GNU/Linux 5.4.0-72-generic x86_64)
and Guppy Basecalling Software, (C) Oxford Nanopore Technologies, Limited. Version 4.0.14+8d3226e, client-server API version 2.1.0
Here is my guppy code:
guppy_basecaller -i fast5/pass -r --device cuda:0 -s hac_fastqs_demul -c /opt/ont/ont-guppy/data/dna_r9.4.1_450bps_hac.cfg --num_callers 4 --require_barcodes_both_ends --trim_barcodes --detect_mid_strand_barcodes --barcode_kits "EXP-PBC001"
This issue was fixed by rebooting.

bitbake error in do_rootfs: systemd depends on update-rc.d

I got a bit stuck debugging a yocto build problem. I encountered this while updating from yocto warrior (2.7) to yocto dunfell (3.1) The build fails during the building of the rootfs, all steps before seem to work:
ERROR: my-project-develop-1.0-r0 do_rootfs: Could not invoke dnf. Command '/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/recipe-sysroot-native/usr/bin/dnf -v --rpmverbosity=info -y -c /shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/rootfs/etc/dnf/dnf.conf --setopt=reposdir=/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/rootfs/etc/yum.repos.d --installroot=/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/rootfs --setopt=logdir=/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/temp --repofrompath=oe-repo,/shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/oe-rootfs-repo --nogpgcheck install base-version-develop bash cairo cantarell-fonts cellular-geolocation commit-hashes-develop crda curl disable-airplane-mode disable-power-saving-for-some-devices disconnect-wifi-without-connectivity dnsmasq dosfstools e2fsprogs e2fsprogs-resize2fs firmware-develop fit-conf gbs-overlay geofencing-db hostapd htop i2c-tools iw jq lateswap libgpiod libgpiod-tools linux-firmware-rtl8192cu matlab-develop modemmanager mosquitto mosquitto-clients nano network-configuration networkmanager openmoji-fonts os-release ostree ostree-devicetrees ostree-initramfs ostree-kernel packagegroup-base packagegroup-base-extended packagegroup-core-boot packagegroup-core-ssh-openssh parted psplash-raspberrypi pstree raspi-gpio rtwpriv run-postinsts set-modes-and-bands source-han-sans-jp-fonts special-shadow sqlite3tzdata u-boot-fw-utils userland weston weston-init wifi-configurator-frontend-develop wifilm811 wifilm843 wpa-supplicant locale-base-en-us' returned 1:
DNF version: 4.2.2
cachedir: /shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/rootfs/var/cache/dnf
Added oe-repo repo from /shared/build/tmp/work/raspberrypi_cm3-poky-linux-gnueabi/my-project-develop/1.0-r0/oe-rootfs-repo
repo: using cache for: oe-repo
not found other for:
not found modules for:
not found deltainfo for:
not found updateinfo for:
oe-repo: using metadata from Tue 16 Feb 2021 08:59:38 AM UTC.
No module defaults found
--> Starting dependency resolution
--> Finished dependency resolution
Error:
Problem 1: package packagegroup-core-boot-1.0-r17.raspberrypi_cm3 requires systemd, but none of the providers can be installed
- conflicting requests
- nothing provides update-rc.d needed by systemd-1:244.5-r0.cortexa7t2hf_neon_vfpv4
Problem 2: package packagegroup-distro-base-1.0-r83.raspberrypi_cm3 requires packagegroup-core-boot, but none of the providers can be installed
- package packagegroup-base-1.0-r83.raspberrypi_cm3 requires packagegroup-distro-base, but none of the providers can be installed
- package packagegroup-core-boot-1.0-r17.raspberrypi_cm3 requires systemd, but none of the providers can be installed
- conflicting requests
- nothing provides update-rc.d needed by systemd-1:244.5-r0.cortexa7t2hf_neon_vfpv4
Problem 3: package packagegroup-base-1.0-r83.raspberrypi_cm3 requires packagegroup-distro-base, but none of the providers can be installed
- package packagegroup-distro-base-1.0-r83.raspberrypi_cm3 requires packagegroup-core-boot, but none of the providers can be installed
- package packagegroup-base-extended-1.0-r83.raspberrypi_cm3 requires packagegroup-base, but none of the providers can be installed
- package packagegroup-core-boot-1.0-r17.raspberrypi_cm3 requires systemd, but none of the providers can be installed
- conflicting requests
- nothing provides update-rc.d needed by systemd-1:244.5-r0.cortexa7t2hf_neon_vfpv4
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
It seems that systemd-1:244.5 depends on update-rc.d. This doesn't make a lot sense to me, since I don't need those scripts anymore when using systemd - maybe there are for some compatibility reasons? Puzzled by this I checked the reference and it seems that I have the right settings to use systemd exclusively:
$ bitbake -e exos-develop | grep "^DISTRO_FEATURES"
DISTRO_FEATURES="acl alsa argp bluetooth ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat largefile opengl ptest multiarch wayland vulkan systemd weston wayland sota usrmerge systemd systemd pulseaudio gobject-introspection-data ldconfig"
DISTRO_FEATURES_BACKFILL="pulseaudio sysvinit gobject-introspection-data ldconfig"
DISTRO_FEATURES_BACKFILL_CONSIDERED="sysvinit sysvinit"
DISTRO_FEATURES_DEFAULT="acl alsa argp bluetooth ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat"
DISTRO_FEATURES_FILTER_NATIVE="api-documentation"
DISTRO_FEATURES_FILTER_NATIVESDK="api-documentation"
DISTRO_FEATURES_NATIVE="x11 ipv6 xattr sota"
DISTRO_FEATURES_NATIVESDK="x11"
During debugging I also saw that poky's systemd recipe uses the update-rc.d.bbclass. From what I can see it only gets active when the DISTRO_FEATURES contain sysvinit, which is apparently not the case here. Maybe some caching issue?
Any ideas how I can debug this further?
I found it out myself (interesting how asking questions helps you thinking...):
The issue was in the systemd recipe itself and related to the systemd-compat-units recipe. I was able to fix it with this in my layer's recipes-core/systemd/systemd_%.bbappend:
# Disable all relations to update-rc.d:
PACKAGECONFIG_remove = "sysvinit"
RRECOMMENDS_${PN}_remove = "systemd-compat-units"
I'm still wondering how this issue came to be at all, though.
Would be great if somebody could explain why this happened at all.

Stop SE Linux from Enforcing on Android AOSP

I need to stop SE Linux from enforcing, from the earliest possible time in the Android boot sequence.
I had read that a kernel parameter of "selinux=0" would stop this. It doesn't:
smarc_mx8mq:/ # cat /proc/cmdline
selinux=0 console=ttymxc2,115200 earlycon=imxuart,0x30880000,115200 init=/init video=HDMI-A-1:1080x1920-32#60 androidboot.console=ttymxc0 androidboot.hardware=freescale androidboot.fbTileSupport=enable cma=1280M androidboot.primary_display=imx-drm firmware_class.path=/vendor/firmware transparent_hugepage=never loop.max_part=7 buildvariant=eng ...
smarc_mx8mq:/ # getenforce
Enforcing
What can I do to absolutely stop SE Linux from enforcing from the start of the boot sequence? (I can have root shell access and I can change the kernel config or any other part of the AOSP build.)
What can I do to absolutely stop SE Linux from enforcing from the start of the boot sequence? (I can have root shell access and I can change the kernel config or any other part of the AOSP build.)
I turn off selinux in BoardConfig.mk by setting:
BOARD_KERNEL_CMDLINE += androidboot.selinux=permissive
Then after building and target flashingcat /proc/cmdline shows androidboot.selinux=permissive:
hikey960:/ # cat /proc/cmdline
androidboot.hardware=hikey960 firmware_class.path=/vendor/firmware loglevel=15 efi=noruntime
overlay_mgr.overlay_dt_entry=hardware_cfg_enable_android_fstab androidboot.selinux=permissive
The solution is to use androidboot.selinux=permissive instead of selinux=0.
I've read that androidboot.selinux=disabled will work too.

Fabric take long time with ssh

I am running fabric to automate deployment. It is painfully slow.
My local environment:
(somenv)bob#sh ~/code/somenv/somenv/fabfile $ > uname -a
Darwin sh.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
My fab file:
#!/usr/bin/env python
import logging
import paramiko as ssh
from fabric.api import env, run
env.hosts = [ 'examplesite']
env.use_ssh_config = True
#env.forward_agent = True
logging.basicConfig(level=logging.INFO)
ssh.util.log_to_file('/tmp/paramiko.log')
def uptime():
run('uptime')
Here is the portion of the debug logs:
(somenv)bob#sh ~/code/somenv/somenv/fabfile $ > date;fab -f /Users/bob/code/somenv/somenv/fabfile/pefabfile.py uptime
Sun Aug 11 22:25:03 EDT 2013
[examplesite] Executing task 'uptime'
[examplesite] run: uptime
DEB [20130811-22:25:23.610] thr=1 paramiko.transport: starting thread (client mode): 0x13e4650L
INF [20130811-22:25:23.630] thr=1 paramiko.transport: Connected (version 2.0, client OpenSSH_5.9p1)
DEB [20130811-22:25:23.641] thr=1 paramiko.transport: kex algos:['ecdh-sha2-nistp256', 'ecdh-sha2-nistp384', 'ecdh-sha2-nistp521', 'diffie-hellman-grou
It takes 20 seconds before paramiko is even starting the thread. Surely, Executing task 'uptime' does not take that long. I can manually log in through ssh, type in uptime, and exit in 5-6 seconds. I'd appreciate any help on how to extract mode debug information. I made the changes mentioned here, but no difference.
Try:
env.disable_known_hosts = True
See:
https://github.com/paramiko/paramiko/pull/192
&
Slow public key authentication with paramiko
Maybe it is a problem with DNS resolution and/or IPv6.
A few things you can try:
replacing the server name by its IP address in env.hosts
disabling IPv6
use another DNS server (e.g. OpenDNS)
For anyone looking at this post-2014, paramiko, which was the slow component when checking known hosts, introduced a fix in March 2014 (v1.13), which was allowed as requirement by Fabric in v1.9.0, and backported to v1.8.4 and v1.7.4.
So, upgrade !

NV-GLX missing extension in OS X Lion

I connect to a remote linux machine using "ssh -X machine", and then I run a graphical application, so its window is displayed on my local OS X Lion machine using X Window. I get the error
"Xlib: extension "NV-GLX" missing on display "localhost:11.0"."
The application moves very slow. Is it any way to use NV-GLX on OS X or to cimcurvent this problem?
I've encountered similar problem trying to connect from a laptop with AMD graphical card to a linux server with NVIDIA card and drivers installed.
If you have root access to your remote linux machine you could try to restart X server with default libglx.so, not the one from NVIDIA driver package. Appears that NVIDIA installer doesn't support partial installation (only driver, no GLX lib), so one needs to remove NVIDIA libglx.so from xorg modules path, but leave nvidia_drv.so. On Debian you could do
# update-alternatives --config glx # select mesa-diverted
# ln -s /usr/lib/nvidia/current/nvidia_drv.so /usr/lib/xorg/modules/drivers/
Be shure your remote /etc/Xorg.0.log has following parts
...
[ 1111.390] (II) LoadModule: "glx"
[ 1111.390] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 1111.390] (II) Module glx: vendor="X.Org Foundation"
...
[ 1111.391] (II) LoadModule: "nvidia"
[ 1111.391] (II) Loading /usr/lib/xorg/modules/drivers/nvidia_drv.so
[ 1111.392] (II) Module nvidia: vendor="NVIDIA Corporation"
...
After that Xlib: extension "NV-GLX" missing on display "localhost:11.0" message should go away