I wanted to get my feet wet with AOSP on my MacOS M1 (ARM64) with Big Sur, but it looks like there is no configuration build for this host.
When I look under build/soong/cc/config I only see one Darwin related file, namely x86_darwin_host.go.
With the latest aosp release, namely android-11.0.0_r35 I'm able to build a generic arm64 target, but the resulting emulator does not boot. Configuration shows that the HOST is detected as x86_64, in fact binaries generated are in x86_64 format.
total 0
drwxr-xr-x 3 salvatorebenedetto staff 102 Apr 10 15:21 common
drwxr-xr-x 9 salvatorebenedetto staff 374 Apr 10 15:21 darwin-x86
➜ aosp file out/host/darwin-x86/lib64/libc++.dylib
out/host/darwin-x86/lib64/libc++.dylib: Mach-O 64-bit dynamically linked shared library x86_64
➜ aosp
This is what I get when booting the emulator from the kernel
RAMDISK: lz4 image found at block 0
RAMDISK: lz4 decompressor not configured!
Invalid ramdisk decompression routine. Select appropriate config option.
Kernel panic - not syncing: Could not decompress initial ramdisk image.
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.18.94+ #1
Hardware name: ranchu (DT)
Call trace:
[<ffffffc00008a590>] dump_backtrace+0x0/0x128
[<ffffffc00008a6cc>] show_stack+0x14/0x1c
[<ffffffc0005ca064>] dump_stack+0x80/0xa4
[<ffffffc0005c95a0>] panic+0xe8/0x228
[<ffffffc00074ba34>] rd_load_image+0x2fc/0x5e0
[<ffffffc00074be30>] initrd_load+0x50/0x2cc
[<ffffffc00074b47c>] prepare_namespace+0xd8/0x1ac
[<ffffffc00074ad04>] kernel_init_freeable+0x1bc/0x1dc
[<ffffffc0005c8150>] kernel_init+0x10/0xf4
Rebooting in 5 seconds..Reboot failed -- System halted
Any idea how I can debug what is wrong with the initrd image?
I think this should help, it has a peace specific for setup the missing sdk 10.15.
Good luck, let us know if it works to you!
Related
I have an old Solaris SPARC application that I'm trying to get running.
I learned from this question that x86 Solaris won't cut it. I recently learned that VM virtualbox can't emulate SPARC architecture. Therefore, I am currently trying to emulate Solaris 10 SPARC using QEMU.
I have acquired a Solaris 10 SPARC iso (sol-10-u11-ga-sparc-dvd.iso) from here.
I have Qemu 3.1.50 installed.
However, when I try to run, it gives me:
C:\Users\xxxx\Documents\CMARPS>"C:\Program Files\qemu\qemu-system-sparc64" -m 512 -cdrom "sol-10-u11-ga-sparc-dvd.iso" -boot d -nographic
OpenBIOS for Sparc64
Configuration device id QEMU version 1 machine id 0
kernel cmdline
CPUs: 1 x SUNW,UltraSPARC-IIi
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.1 built on Feb 15 2019 10:05
Type 'help' for detailed information
Trying cdrom:f...
Not a bootable ELF image
Not a bootable a.out image
Loading FCode image...
Loaded 7420 bytes
entry point is 0x4000
Evaluating FCode...
Evaluating FCode...
Ignoring failed claim for va 1000000 memsz af6d6!
Ignoring failed claim for va 1402000 memsz 4dcc8!
Ignoring failed claim for va 1800000 memsz 510c8!
SunOS Release 5.10 Version Generic_147147-26 64-bit
Copyright (c) 1983, 2013, Oracle and/or its affiliates. All rights reserved.
could not find debugger-vocabulary-hook>threads:interpret: exception -13 caught
interpret \ Copyright (c) 1995-1999 by Sun Microsystems, Inc.
\ All rights reserved.
\
\ ident "#(#)data64.fth 1.3 00/07/17 SMI"
hex
only forth also definitions
vocabulary kdbg-words
also kdbg-words definitions
defer p#
defer p!
['] x# is p#
['] x! is p!
8 constant ptrsize
d# 32 constant nbitsminor
h# ffffffff constant maxmin
\
\ Copyright 2008 Sun Microsystems, Inc. All rights reserved.
\ Use is subject to license terms.
\
\ #pragma ident "#(#)kdbg.fth 1.20 08/06/06 SMI"
h# 7ff constant v9bias
h# panic - kernel: no nucleus hblk8 to allocate
EXIT
Trying to boot gives me:
0 > boot
boot Not a Linux kernel image
Not a bootable ELF image
Not a bootable a.out image
Loading FCode image...
Unhandled Exception 0x00000000ffeb6080
PC = 0x00000000ffd27954 NPC = 0x00000000ffd27958
Stopping execution
Either there is something causing a kernel panic or my iso isn't actually booting correctly(?)
I thought that maybe the iso was actually a 32 bit SPARC iso so I tried that:
C:\Users\xxxx\Documents\CMARPS>"C:\Program Files\qemu\qemu-system-sparc" -m 256 -cdrom "sol-10-u11-ga-sparc-dvd.iso" -boot d -nographic
Configuration device id QEMU version 1 machine id 32
Probing SBus slot 0 offset 0
Probing SBus slot 1 offset 0
Probing SBus slot 2 offset 0
Probing SBus slot 3 offset 0
Probing SBus slot 4 offset 0
Probing SBus slot 5 offset 0
Invalid FCode start byte
CPUs: 1 x FMI,MB86904
UUID: 00000000-0000-0000-0000-000000000000
Welcome to OpenBIOS v1.1 built on Feb 15 2019 10:04
Type 'help' for detailed information
Trying cdrom:d...
Not a bootable ELF image
Not a bootable a.out image
No valid state has been set by load or init-program
0 > boot
boot Trying cdrom:d...
Not a bootable ELF image
Not a bootable a.out image
No valid state has been set by load or init-program
ok
0 >
What am I doing wrong here?
You're trying to run with only 512 mb of RAM:
...qemu-system-sparc64" -m 512 ...
Per the Oracle Solaris 10 1/13 Installation Guide: Planning for Installation and Upgrade page on System Requirements and Recommendations:
For UFS or ZFS root file systems, 1.5 GB is the minimum memory required for installation. However, note that some optional installation features are enabled only when sufficient memory is present. For example, if your system has insufficient memory and you install from a DVD, you install through the Oracle Solaris installation program's text installer, not through the GUI.
The current version of QEMU (I last tested with 4.1) does not support SPARC64 systems well yet. While the instruction set is supported, to run OpenSolaris the rest of the hardware needs to be emulated too. The system emulation code is not finished yet, but I have seen some slow progress on Git.
Running a 1 node ceph cluster, and using the ceph-client from another node. Qemu is working fine with the RBD mounting. When I try to mount a RBD block device on the ceph-client I get an indefinite hang with no output. How to diagnose whats wrong?
System is ubuntu 16.04 server, and Ceph Luminous.
sudo ceph tell osd.* version
{
"version": "ceph version 12.2.2 (cf0baeeeeba3b47f9427c6c97e2144b094b7e5ba) luminous (stable)"
}
ceph -s
cluster:
id: 4bfcc109-e432-4ac0-ba9d-bf81243aea
health: HEALTH_OK
services:
mon: 1 daemons, quorum gcmaster
mgr: gcmaster(active)
osd: 1 osds: 1 up, 1 in
data:
pools: 1 pools, 128 pgs
objects: 1512 objects, 5879 MB
usage: 7356 MB used, 216 GB / 223 GB avail
pgs: 128 active+clean
rbd info gcbase
rbd image 'gcbase':
size 512 MB in 128 objects
order 22 (4096 kB objects)
block_name_prefix: rbd_data.376974b0dc51
format: 2
features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
flags:
create_timestamp: Fri Dec 29 17:58:02 2017
This hangs forever
rbd map gcbase --pool rbd
As does this
rbd map typo_gcbase --pool rbd
dmesg shows
Dec 29 13:27:32 cephclient1 kernel: [85798.195468] libceph: mon0 192.168.1.55:6789 feature set mismatch, my 106b84a842a42 < server's 40106b84a842a42, missing 400000000000000
Dec 29 13:27:32 cephclient1 kernel: [85798.222070] libceph: mon0 192.168.1.55:6789 missing required protocol features
The dmesg output tells what's going on: The cluster requires a feature bit that is not supported by the libceph kernel module.
The feature bit in question is either CEPH_FEATURE_CRUSH_TUNABLES5, CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING or CEPH_FEATURE_FS_FILE_LAYOUT_V2 (they are overlapping because they were introduced at the same time) which only became available on kernel 4.5, whereas Ubuntu 16.04 uses a 4.4 kernel.
A similar question (although related to CephFS) came up on the mailing list with a possible solution:
Yes, you should be able to set your CRUSH tunables profile to hammer
with "ceph osd crush tunables hammer".
This will disable some features, but should make the older kernel compatible with the cluster.
Alternatively you could upgrade to a mainline kernel or to a newer OS release.
I am using Ubuntu 16.0.4 LTS running linux kernel 4.4.0 series.
I made some changes to the i2c-ocores code and eeprom driver and built the whole kernel afresh. Then I installed the newly built kernel.
I used the following steps to build the kernel:
1. sudo apt-get source linux-image-$(uname -r)
2. Applied my changes to i2c-ocores and eeprom driver
3. sudo chmod a+x debian/scripts/*
4. sudo chmod a+x debian/scripts/misc/*
5. sudo fakeroot debian/rules clean
6. sudo fakeroot debian/rules editconfigs
a. Checked all the options for i2c driver
7. sudo fakeroot debian/rules binary-headers binary-generic skipabi=true skipmodule=true
8. Installed all the .deb packages created by the build.
After installing new kernel, I rebooted the machine and inserted i2c-ocores and eeprom drivers and they worked fine. But after like four or five reboots, my insertion for these drivers fails. I am using modprobe to insert the modules.
Like for i2c-ocores, I get the following errors:
Aug 18 11:08:14 manik kernel: [ 214.831678] i2c_ocores: disagrees about version of symbol i2c_new_device
Aug 18 11:08:14 manik kernel: [ 214.831682] i2c_ocores: Unknown symbol i2c_new_device (err -22)
Aug 18 11:08:14 manik kernel: [ 214.831700] i2c_ocores: disagrees about version of symbol i2c_del_adapter
Aug 18 11:08:14 manik kernel: [ 214.831701] i2c_ocores: Unknown symbol i2c_del_adapter (err -22)
Aug 18 11:08:14 manik kernel: [ 214.831708] i2c_ocores: disagrees about version of symbol i2c_add_adapter
Aug 18 11:08:14 manik kernel: [ 214.831709] i2c_ocores: Unknown symbol i2c_add_adapter (err -22)
does anyone have any idea what is happening here ? Am I doing something wrong ?
There really isn't enough information in the question to give a definite answer, but I believe I might know the problem.
You are rebuilding an Ubuntu kernel, but not changing the version number. As a result, you are, effectively, overwriting the kernel that came with the system. Somewhere in the process, it is possible that you are getting a mismatch between the kernel you are using and the modules you are trying to load (i.e. - you are getting the vanilla kernel and your custom modules or vice-versa). When that happens, the errors you are seeing might come up.
My best advice for you is to change the appended revision of the kernel to something that contains your name before building. At the very least, that will allow you to see which versions are involved by simply running uname -r.
A few asides:
People offered you to build just the modules. That won't work for two reasons. First, you are replacing existing modules, which means you run the risk that exactly what I think happened would happen. More to the point, however, you say you change the kernel's config. You cannot do that when you build just the modules out of tree.
You are running sudo fakeroot. sudo is a tool that makes your commands run as root. fakeroot is a command that fakes the root environment when the real one isn't available. It makes no sense to run both. As far as I can tell, your best bet is to build with fakeroot and install with sudo.
I have built the very latest u-boot release and placed the image on a Raspberry PI. After boot, I get this error message:
U-Boot 2013.10 (Oct 24 2013 - 09:35:44)
DRAM: 448 MiB
WARNING: Caches not enabled
MMC: bcm2835_sdhci: 0
Using default environment
In: serial
Out: lcd
Err: lcd
Hit any key to stop autoboot: 0
mmc0 is current device
** No partition table - mmc 0 **
U-Boot>
Obviously, u-boot failed to mount the file system.
Can this be related to some mmc related setting as access speed?
Thanks in advance
I'm trying the use the Tanuki Java Service Wrapper.
The hardware I'm using is a Raspberry Pi with the Raspbian wheezy distribution.
(see http://www.raspberrypi.org/downloads)
I've tried the Wrapper 32-bit armel release, but get problems with reading the libwrapper.so.
INFO | jvm 1 | 2013/04/24 20:15:34 | WrapperManager: Initializing...
INFO | jvm 1 | 2013/04/24 20:15:42 | WrapperManager Debug: Attempt to load native library with name: libwrapper.so Result: /usr/iHome/lib/libwrapper.so: /usr/iHome/lib/libwrapper.so: cannot open shared object file: No such file or directory
I've also tried the armhf release, since it seems that "apt-get java-7-openjdk", installed the jdk-armhf version, but there I did get "Segmentation fault" when starting the Wrapper.
Some extra info:
pi#raspberrypi /usr/lib/jvm $ java -version
java version "1.7.0_07" OpenJDK Runtime Environment (IcedTea7 2.3.2)
(7u7-2.3.2a-1+rpi1)OpenJDK Zero VM (build 22.0-b10, mixed mode)
pi#raspberrypi /usr/lib/jvm $ ls -altr
total 28
-rw-r--r-- 1 root root 2437 Sep 26 2012 .java-1.7.0-openjdk-armhf.jinfo
lrwxrwxrwx 1 root root 20 Sep 26 2012 java-1.7.0-openjdk-armhf -> java-7-> openjdk-armhf
drwxr-xr-x 3 root root 4096 Jan 17 20:59 java-7-openjdk-common
drwxr-xr-x 5 root root 4096 Jan 17 21:00 java-7-openjdk-armhf
drwxr-xr-x 4 root root 4096 Jan 17 21:00 .
drwxr-xr-x 74 root root 12288 Apr 24 20:32 ..
pi#raspberrypi /usr/lib/jvm $ uname -a
Linux raspberrypi 3.2.27+ #250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux
Thanks in advance,
BR, Rob
This issue has already been discussed on the Java Service Wrapper user mailing list in this thread, but here is the summary of the resolution.
The armhf version of the Wrapper is being built on an armv7 platform and apparently this is not compatible for armv6 hard float architectures. When using the armel version of the Wrapper with an armhf jvm then loading the native library fails due to the target mismatch.
The suggested solutions were to either use an armel jvm with the armel version of the Wrapper (since armv6 boards should support both) or to create the armhf binary for his board himself.
For the second suggestion, the pre-release (from the sourceforge project site of the Wrapper) package has to get downloaded, extracted and the following shell script executed:
./build32.sh release
With the created binary the Wrapper was able to launch successfully. (the build process requires a JDK and Apache-Ant installed)
Cheers,