Ramdisk changes not reflected on Android filesystem - Android Q&A, Help & Troubleshooting

Hey all,
I am learning how Android works and am trying to figure out how I can update the Android filesystem by extracting a ramdisk from normal boot.img, adding some files, then flashing it back. So far, I have been unsuccessful in doing this and am hoping to figure out why. Here's the steps below I have taken:
Using a Google Pixel 4a, Android 11, kernel v 4.14 (i.e. not GKI)
High level:
Extract ramdisk.cpio from boot.img using magiskboot via adb on device, modify extract contents, sent back up to magiskboot, repackaged, then flashed via fastboot.
Detailed steps:
Grab ramdisk.cpio
Code:
$ # obtain the ramdisk.cpio from magiskboot
$ adb -d shell "cd ${BOOT_IMG_PATH}; ./magiskboot unpack boot.img"
$ adb -d pull /${BOOT_IMG_PATH}/ramdisk.cpio /tmp/
$ # attempt to modify the filesystem
$ mkdir /tmp/rd && cd rd
$ cpio -i < /tmp/ramdisk.cpio
$ touch yolo
$ echo "why doest this work" > system/wtf.txt
$ echo "why doest this work" > sys/wtf.txt
$ echo "why doest this work" > vendor/wtf.txt
#patch this directory back up and send to magiskboot
$ find . | cpio -oH new > /tmp/new.ramdisk.cpio
$ adb -d push /tmp/new.ramdisk.cpio ${BOOT_IMG_PATH}/ramdisk.cpio
$ adb -d shell "cd ${BOOT_IMG_PATH}; ./magiskboot repack boot.img
$ adb -d pull /${BOOT_IMG_PATH}/new-boot.img /tmp/
# apply this modifyied boot.img
$ adb reboot bootloader
fastboot flash boot /tmp/new-boot.img
fastboot reboot
After doing this, I'll adb back in to verify:
Code:
adb -d shell "find / -name "wtf.txt" 2>/dev/null
# silence.... always silence... no file change
* I am aware that Wu modifies the extracted dtb file from boot.img with a "magiskboot dtb dtb patch" command but that doesn't seem to apply to my particular boot.img as the fstab doesn't seem to be around
* I am aware that vbmeta and codesigning, I have disabled vbmeta via fastboot
* I am aware that there's A/B slots for flashing. I have tried flashing both slots to make sure the updated ramdisk is seen
* I am aware of magiskboot's kernel patch from skip_initramfs -> want_initramfs. I could use some clarification on this if it pertains to my problem
* My Android device uses "mount method C" from Wu's great writeup https://github.com/topjohnwu/Magisk/blob/master/docs/boot.md. That is, it's init's job to mount everything on my device. I guess I feel confused as to why init wouldn't mount the additional files that I've added to the ramdisk
Extremely grateful for help or guidance on what I've overlooked. Thanks y'all

You should probably examine your modified boot file to see if the new stuff is in there.
I don't use your tools or even deal with cpio as a file type.
Code:
C:\>echo Hello > sbin\bogus
C:\>imgutil /i boot.img sbin/bogus
C:\>imgutil /l boot.img
...
sbin/bogus
...

Related

[Q] tf201 android/ubuntu duel boot?

i like my android for home use ,but as a IT maneger it will be nice to have linux on my prime as well. thar is any toturial that expline how to make my prime duel boot this 2 OS?
Overview
Follow this thread: Ubuntu | How-to install it on the Prime . NOTICE: developer-thread
Mainly there are 2 methods:
Flash-boot:
The thread starts with LilStevies work from Androidroot. There you have to flash the correspondent boot-kernel to start either android or linux. So far I don't know of an existing LilStevie rom with the kexec/kexecboot method (kexec: Linux as bootloader).
SDCard-existence-driven-init
Running linux with root_chooser_v1/2/3 form tux_mind which starts around thead-page 35 uses a modified init. Dualboot: with SDCard in slot -> linux | without SDCard in slot -> Android
See: Gentoo Wiki and hack-job if you are on Asus stock rom.
You can also use chroot method - but it's not dualboot.
I had method 1 running. But for me it is not working for daily useage. (reflashing s*c*s :angel
Now i will use the SDCard-existence-driven-init
I can't use the posted boot-blob because I'm not on the Asus stock kernel so Android starts but many processes crash so that it is not useable. I use the Energy-Rom with the Clemsyn-kernel. (Prime is unlocked, nvflash-activated and rooted)
Be warned: You could damage/ brick your device following the instructions. Backup all!! A whole nvflash backup is reccomended. Be carful. Use your brain. I'm not responsible for any damages.
Up to now I tested my own 'unchanged' fastboot boot-blob:
Enter APX-Mode: put in USB cable + hold [Vol up]+[Power] (until vibrating, screen stays black)
Code:
$ sudo wheelie -r --blob blob.bin
$ sudo nvflash -r --read 6 blobNv.LNX
$ sudo nvflash -r --go
Unpack blob:
Code:
$ abootimg -x blobNv.LNX
repack blob (be sure you have blobpack for TF201 i.e. from CM10 repo):
Code:
$ abootimg --create testNv.LNX -k zImage -r initrd.gz -f bootimg.cfg
$ blobpackTF201 testFb.blob LNX testNv.LNX
start into fastboot-mode: put in USB cable [Vol down]+[Power] (until you can choose fastboot/USB symbol)
Code:
$ fastboot -i 0x0b05 flash boot testFb.blob
$ fastboot -i 0x0b05 reboot
The blob flashes well - I can see the blue progerss-bar. By the way: this produces a backup blob of the bootpartition which you can reflash via fastboot to start android if sth went wrong.
Now I need to insert the root_chooser init into the ramdisk to get linux from SDCard started...
I got a half working root_chooser. It starts android but not linux.
Here is what I did to modify the boot-loader with Clemsyn kernel and the modified init from tux_mind:
At first I read the LNX patition from the TF201 (unlocked, nvflash-able/wheelie, rooted):
Boot into APX-mode:
Code:
$ sudo bin/wheelie -r --blob bin/blob.bin
$ sudo bin/nvflash -r --read 6 blobNv.LNX
$ sudo bin/nvflash -r --go
Unpack the blob:
Code:
$ abootimg -x blobNv.LNX
You will get bootimg.cfg, initrd.img and zImage.
Now unpack the initial ramdisk:
Code:
$ mkdir ramdisk
$ cd ramdisk
$ gzip -dc ../initrd.img | cpio -i
Clone tux_minds data and copy your extracted custom rom ramdisk to newroot:
Code:
$ cd ..
$ git clone https://github.com/tux-mind/tf201-dev.git
$ rm -r tf201-dev/initramfs/newroot/*
$ cp -r ramdisk/* tf201-dev/initramfs/newroot/
[I][SIZE="2"]#edit 22 feb 2013[/SIZE][/I]
$ cd tf201-dev/initramfs
$ mkdir data && mkdir dev && mkdir sys
$ cd ../../..
[I][SIZE="2"]#edit end[/SIZE][/I]
OPTIONAL start compile root_chooser/init via crosscompile
Change the compiler in Makefile. I use Ubuntu with arm-linux-gnueabi-gcc (maybe it would be better to use arm-linux-gnueabihf-gcc) from the repo for crosscompiling:
Edit Makefile in tf201-dev/root_chooser:
Code:
#--Head-------------------- snip
CC=arm-linux-gnueabi-gcc
LD=arm-linux-gnueabi-ld
#CC=arm-unknown-linux-gnueabi-gcc
#LD=arm-unknown-linux-gnueabi-ld
#-------------------------- snap
Now compile and copy it to the initramfs:
Code:
$ make v2
$ cp root_chooser ../initramfs/init
OPTIONAL end
Now pack the initrd, make a blob and flash it to the TP
Code:
$ cd tf201-dev/initramfs
$ find . | cpio --create --format='newc' > ../../myinitrd
$ cd ../..
$ gzip myinitrd
$ chmod 777 myinitrd.gz
$ abootimg --create testNv.LNX -k zImage -r myinitrd.gz
$ bin/blobpackTF201 testFb.blob LNX testNv.LNX
Start into fastbootmode:
Code:
$ fastboot -i 0x0b05 flash boot testFb.blob
$ fastboot -i 0x0b05 reboot
Start into andorid open Terminal Emulator and type:
Code:
$ su
# vi /data/.boot
/dev/mmcblk1p1:/:/sbin/init
[esc] :wq
I followed this guide to set up my sdCard. That's it. Insert sdCard, reboot.
Android starts but not Linux from the sdCard. I got the following message back in android:
Code:
[I][B]FIXED[/B][SIZE="2"] see edit 22 feb 2013[/SIZE][/I]
[COLOR="Silver"]$ cat /boot_chooser.log
unable to mount /sys - No such file or directory[/COLOR]
New error message (inserted sdCard occurs boot-loops, remove sdCard to start android):
Code:
$ cat /boot_chooser.log
unable to mount /dev/mmcblk1p1 on /newroot - No such file or directory
I'm feeling so close to fire up Linux on my Transformer. Who can give me hint?
gophix said:
New error message (inserted sdCard occurs boot-loops, remove sdCard to start android):
Code:
$ cat /boot_chooser.log
unable to mount /dev/mmcblk1p1 on /newroot - No such file or directory
Click to expand...
Click to collapse
got it yeah! linux and android starting up! BUT VERY INSTABILE !!!
I had to use another sdCard and recompiled the kernel with some flags activated:
My hama 16GB class 10 doesn't seem to work well with the TP. I copied some data to the sdcard in android, there the I/O stream had several stops while copying data. Some forum members reported I/O errors in the system log (dmesg). I didn't have that errors but a variing throughput while copyint to sdCard.
The kernel I prepared this way:
Code:
downloading Clemsyn-kernel source:
$ wget https://www.dropbox.com/s/pjqd2b1edn6fiwu/tfcombofinal.zip
$ unzip tfcombofinal.zip
Get the actual kernel .config form the TP via adb and compile the kernel (I didn't patch, because I got error while compiling the kernel). I diffed my config to tux_minds and aktivated some flags.
Code:
$ adb pull /proc/config.gz
$ gzip -d config.gz
$ cp config tfcombofinal/.config
$ cd tfcombofinal
// patching should be like this:
// $ wget https://github.com/tux-mind/tf201-dev/raw/master/v2/kernel/JB15.patch
// $ patch -p1 < ../JB15.patch(v1/v2?) !!! do not patch !!!
$ make menuconfig
$ make -j4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
I didn't compile the modules.
After that I packed my kernel from tfcombo/arch/arm/boot/zImage into the blob ($ abootimg --create testNv.LNX -k zImage -r myinitrd.gz)
VERY INSTABILE !!! means: the linux starting kernel was compiled with hardfloat (arm-linux-gnueabihf-).Linux starts up and responds "a littel bit"; android starts up; work 5 mins and reboots.
So both are working the developer way
I will test an own armSF kernel next time (the way described in this post, up to now I run instable on armHF) and report if this makes android stable and additionally starts up linux.
The dual-boot works fine.
Look at lifeinarootshell.
The actual version root_chooser v6 starts linux (from SDcard, microSDcard, USB, loop-device, internal folder) and android with different kernels
It has a cofigurable bootloader via kexec.
Linux distributions (gentoo, ubuntu, arch linux, ...) are also available and are growing more and more in stability and performance.
gophix said:
The dual-boot works fine.
Look at lifeinarootshell.
The actual version root_chooser v6 starts linux (from SDcard, microSDcard, USB, loop-device, internal folder) and android with different kernels
It has a cofigurable bootloader via kexec.
Linux distributions (gentoo, ubuntu, arch linux, ...) are also available and are growing more and more in stability and performance.
Click to expand...
Click to collapse
Getting xorg to work on archlinux is somewhat messy at the moment. The tegra3 driver is built for an old xorg-server, and is not compatible with the new one in the archlinux repositories. I was able to make it work by recompiling xorg-server, though. I guess it would be easier if someone made an aur package with the old xorg-server.
Thank you very much gophix for your nice guide in the second post :fingers-crossed:
However, since the first attempts to get linux based distributions working on the TF201 like ubuntu or arch linux, there was not much progress anymore I feel this is somehow pitty due to the fact that the Prime is still a good and reasonable tablet. And it could be much more if there would be not these horrible restrictions set by Asus like encrypted bootloader.
But I don't want to criticise mainly in my post. Instead, I would like to promote a constructive discussion so that the TF201 receives new life
How about creating a new ubuntu image based on 14.04 since it receives long term support? Unfortunately, my knowledge is still rather limitted so far to do this by myself.
And what is your opinion, to go alternatively another way by using the xubuntu installation (13.04) developed for the TF300tg as shown here:
http://forum.xda-developers.com/showthread.php?t=2190847
As far as I know, both devices are quite similar. Or are there any good arguments to deny this idea?

Installing SuperSU root on Mi 5c

Here's a guide + script for installing SuperSU root on the Mi 5c.
I haven't yet managed to build a TWRP recovery image for it (I haven't really tried) - so this can be used to get root in the mean-time. (I also saw a Chinese TWRP ROM on the MIUI forums, but I haven't tried it myself)
Obviously modifying the phone system is risky, you may void the warranty, break it etc. I take no responsibility for that, and you use the instructions below at your own risk.
The script, and a few other tools I'm using for the Mi 5c can be found in my git repo: github.com/usedbytes/meri_tools
To use the script, you'll need a linux (or Mac, probably) computer with gcc and git installed, as well as a new-ish version of adb and fastboot. I'm running it on Arch Linux fine.
First get the phone into developer mode (tap on the MIUI version in About Phone 7 times), and enable adb debugging, and approve your computer to access debugging.
Then you need to download and extract the SuperSU "Installable Recovery" zip, and the Xiaomi stock ROM, which we will use for the install files.
Then, run the script below (meri_root.sh in the git repo).
The script installs all the bits needed, then reboots the phone with a rooted boot image. To make the root persistent, you need to flash the boot.supersu.img to the boot partition with fastboot (it just boots it by default).
Code:
#!/bin/bash
#
# Script to root the Xiaomi Mi 5c, by manually installing SuperSU
#
# Copyright 2017 Brian Starkey
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included in
# all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
# AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
#
# -- Disclaimer
#
# Obviously modifying your phone can be dangerous, void the warranty etc. etc.
# Use this script and the instructions within it at your own risk.
#
# -- Description
#
# The SuperSU installer seems to assume you already have root, and is intended
# to be run from a custom recovery (like TWRP). We don't have that, so we'll do
# some funny dances to do a systemless root without having root to begin with.
#
# The crux of the matter is using SuperSU's tools to patch the ramdisk and
# sepolciy (in /data/local/tmp, without root), then building a ramdisk with
# those components
#
# -- Usage
#
# Plug in the phone, make sure you have (persistent) adb debugging permissions
# and run this script like so:
# meri_root.sh SUPERSU_DIR ROM_DIR
# Where SUPERSU_DIR is a directory where you have downloaded and extracted the
# SuperSU "Recovery Flashable" zip file: http://www.supersu.com/download
# and ROM_DIR is a directory where you have downloaded and extracted the ROM
# from Xiaomi's download page: http://en.miui.com/download-322.html
#
# The script will make and boot a boot.img which enacts a systemless root.
# To make it persisent, you must flash it instead:
# fastboot flash boot.supersu.img
#
# By default, SuperSU removes dm-verity from /system and encryption from /data
# To prevent this, set PRESERVE_VERITY=1 before running the script:
# PRESERVE_VERITY=1 ./meri_root.sh ...
if [ $# -ne 2 ];
then
cat >&2 <<EOM
Usage: $(basename $0) SUPERSU_DIR ROM_DIR
Extract SuperSU zip file into SUPERSU_DIR, and the Xiaomi ROM into ROM_DIR,
then run this script.
EOM
exit 1
fi
SUPERSU_DIR=$1
echo ${SUPERSU_DIR}/arm64/su
if [ ! -f ${SUPERSU_DIR}/arm64/su ]
then
echo "Invalid SUPERSU_DIR" >&2
exit 1
fi
ROM_DIR=$2
if [ ! -f ${ROM_DIR}/boot.img ]
then
echo "Invalid ROM_DIR" >&2
exit 1
fi
# 1. Get mkbootimg and build it
git clone --depth 1 https://github.com/osm0sis/mkbootimg.git || exit 1
cd mkbootimg
make || ( cd .. && exit 1 )
cd ..
# 2. Copy the SuperSU binaries to the device
echo "Waiting for device..."
adb wait-for-usb-device
adb push ${SUPERSU_DIR}/arm64/*su* /data/local/tmp/ || exit 1
adb shell chmod +x /data/local/tmp/su*
# 3. Create the SuperSU systemless root image
# Ideally we'd set up security contexts too, but then you need to be running
# on an SELinux-enabled kernel in permissive mode.
# Instead, we will fix it on first boot.
dd if=/dev/zero bs=1M count=96 of=su.img
mkfs.ext4 su.img
mkdir mnt
sudo mount su.img mnt
sudo mkdir mnt/{bin,xbin,lib,etc,su.d}
sudo chmod 0751 mnt/bin
sudo chmod 0755 mnt/{xbin,lib,etc}
sudo chmod 0700 mnt/su.d
sudo cp ${SUPERSU_DIR}/arm64/{su,sukernel} mnt/bin/
sudo cp ${SUPERSU_DIR}/arm64/su mnt/bin/daemonsu
sudo cp ${SUPERSU_DIR}/arm64/supolicy mnt/bin/supolicy_wrapped
sudo ln -s /su/bin/su mnt/bin/supolicy
sudo chown root:root mnt/bin/{su,daemonsu,sukernel,supolicy_wrapped}
sudo chmod 0755 mnt/bin/{su,daemonsu,sukernel,supolicy_wrapped}
sudo cp ${SUPERSU_DIR}/arm64/libsupol.so mnt/lib/libsupol.so
sudo chown root:root mnt/lib/libsupol.so
sudo chmod 0644 mnt/lib/libsupol.so
# Run a script at first-boot to fix up the SELinux contexts on the image
# It will remove itself after running
sudo bash -c "cat > mnt/su.d/firstboot.rc" <<EOF
#/system/bin/sh
chcon -hR u:object_r:system_data_file:s0 /su /data/local/tmp/su.img
rm /su/su.d/firstboot.rc
sync
EOF
sudo chmod 0750 mnt/su.d/firstboot.rc
sync
sudo umount mnt
# 4. Copy the systemless root image to the device
adb push su.img /data/local/tmp/su.img
# 5. Extract boot.img
mkdir bootimg
mkbootimg/unpackbootimg -o bootimg -i ${ROM_DIR}/boot.img
# 6. Unzip the ramdisk
cat bootimg/boot.img-ramdisk.gz | gunzip > ramdisk
# 7. Copy the ramdisk to the device, for patching
adb push ramdisk /data/local/tmp
# 8. Patch sepolicy and the ramdisk, using the SuperSU tools we copied over
# earlier
adb shell "
cd /data/local/tmp
LD_LIBRARY_PATH=. ./supolicy --file /sepolicy ./sepolicy.patched
LD_LIBRARY_PATH=. ./sukernel --patch ./ramdisk ramdisk.patched
"
# 9. Pull back the patched files
adb pull /data/local/tmp/sepolicy.patched /data/local/tmp/ramdisk.patched .
# 10. Extract the patched ramdisk, and install the patched sepolicy into it
mkdir ramdir
cat ramdisk.patched | sudo cpio --no-absolute-filenames -D ramdir -i
sudo cp sepolicy.patched ramdir/sepolicy
sudo chown root:root ramdir/sepolicy
sudo chmod 0644 ramdir/sepolicy
# 11. Install the SuperSU init scripts
sudo mkdir ramdir/su
sudo chmod 755 ramdir/su
sudo cp ${SUPERSU_DIR}/common/launch_daemonsu.sh ramdir/sbin
sudo chmod 744 ramdir/sbin/launch_daemonsu.sh
sudo chown root:root ramdir/sbin/launch_daemonsu.sh
sudo cp ${SUPERSU_DIR}/common/init.supersu.rc ramdir
sudo chmod 750 ramdir/init.supersu.rc
sudo chown root:root ramdir/init.supersu.rc
# 12. Patch the initscript for our img location and set the su.img context
sudo sed -i 's;/data/su.img;/data/local/tmp/su.img;' ramdir/init.supersu.rc
sudo sed -i '\;on property:sukernel.mount=1;a\ \ \ \ restorecon /data/local/tmp/su.img' ramdir/init.supersu.rc
sudo bash -c "echo /data/local/tmp/su.img u:object_r:system_data_file:s0 >> ramdir/file_contexts"
# Optional: Preserve dm-verity on /system, encryption on /data
if [ ! -z "$PRESERVE_VERITY" ] && [ $PRESERVE_VERITY -ne 0 ]
then
echo "Preserving dm-verity"
mkdir ramdir-stock
cat ramdisk | sudo cpio --no-absolute-filenames -D ramdir-stock -i
sudo cp ramdir-stock/{fstab.song,verity_key} ramdir/
sudo rm -rf ramdir-stock
fi
# 13. Repack the ramdisk
cd ramdir
sudo find . ! -path . | sudo cpio -H newc -o | gzip > ../ramdisk.gz
cd ..
# 14. Repack the boot image
mkbootimg/mkbootimg \
--kernel bootimg/boot.img-zImage \
--ramdisk ramdisk.gz \
--cmdline "console=ttyS0,115200 earlyprintk=uart8250-32bit,0xF900B000 androidboot.hardware=song no_console_suspend debug user_debug=31 loglevel=8" \
--base 0x0 \
--pagesize 4096 \
--kernel_offset 0x0a080000 \
--ramdisk_offset 0x0c400000 \
--dt bootimg/boot.img-dtb \
--tags_offset 0xc200000 \
--os_version 0.0.0 \
--os_patch_level 0 \
--second_offset 0x00f00000 \
--hash sha256 \
--id \
-o boot.supersu.img
# 15. Boot it! (flash it if you want to make it persistent)
adb reboot-bootloader
fastboot boot boot.supersu.img
echo "Waiting for device..."
adb wait-for-usb-device
Hi ,
Can you give me some advice on how to run this on Windows? I can get a adb shell but thats as far as I can get. I don't know how I am supposed to run the script.
Thanks
Stewart
Hello,
I am trying to root my mi 5c with your script, but I can't find sepolicy file on my phone, so for example this line can't be executed:
Code:
LD_LIBRARY_PATH=. ./supolicy --file /sepolicy ./sepolicy.patched
Do you know where I could find this file? I am using xiaomi.eu_multi_MI5c_7.4.6_v8-7.1 rom.
Hello,
I've had exactly the same issue on a multirom and on xiaomi.eu_multi_MI5c_7.4.20(although i'm not sure if installed rom has something to do with it)
blagon said:
...I am trying to root my mi 5c with your script, but I can't find sepolicy file on my phone...
Click to expand...
Click to collapse

[S905] WeTek Hub Boot Image Modification

I recently got my hands on a WeTek Hub. All round quite a nice little box, but the default lowmemorykiller settings are a little annoying, and sometimes result in the boot failing because the kernel decided to kill one of the startup processes. I'm trying to modify the settings in the init.rc, but I'm having a spot of trouble with a boot loop after repacking the boot image.
I copied the image off the device by using dd to extract the partition to a file, and then used the built-in FTP server to copy it off the device, and extracted it using unmkbootimg. after unzipping, extracting, modifying, and re-packing, I used mkbootimg to recreate the image, and dd'd it back onto the box (commands below).
Code:
dd if=/dev/block/boot of=/sdcard/boot.img
Code:
./unmkbootimg boot.img
mv initrd.img{,.gz}
gunzip initrd.img.gz
mkdir initrd
cp initrd.img initrd
cd initrd
cpio -i < initrd.img
rm initrd.img
# change stuff here
find . | cpio -o -H newc > ../initrd.cpio
cd ..
gzip initrd.cpio
./mkbootimg --kernel kernel.gz --ramdisk initrd.img.gz -o new_boot.img
Code:
dd if=/sdcard/new_boot.img of=/dev/block/boot
Unfortunately, that left me with a flashing WeTek logo as the it continuously rebooted. examining the logs from u-boot didn't give anything useful, but luckily I was able to get it into recovery and flash Ricardo's Android TV ROM back on there. Unfortunately, I'm still stuck with the original boot failure issue. Any clues as to what I've missed?
I do so
Code:
cd boot
../mkboot boot.img unpaсk
cd unpack/ramdisk
find . | cpio -o -H newc | gzip > ../ramdisk.packed
[I][B]# (edit size ramdisk in /boot/unpack/img_info file)[/B][/I]
cd ../..
../mkboot unpack boot.img
all is working

Tolino e-Reader with broken android

Hey Guys,
i got a broken Tolino Vision 3 HD from a friend to fix the issues with the android. It´s a popular ebook reader in Germany.
At the moment I got the device it stuck in language selection and the partition for the ebooks wasn´t shown after USB connection.
So I downloaded the new software version from the vendor "mytolino" (I am not allowed to post urls). I tried to update via
fastboot update
Click to expand...
Click to collapse
but i got this error:
archive does not contain 'android-info.txt'
error: update package '..\update.zip' has no android-info.txt
Click to expand...
Click to collapse
. So I unpack the .zip and try to flash the images manualy. This didn´t work. After this is tried to copy the update.zip to /sdcard via adb push but this didn´t work, too.
Question:
Is there any way to flash the device with the given update.zip?
Regards and all good wishes from sunny Germany
Did you tried to do factory reset? Are you able to boot into recovery using key-combination?
The more heavy way I used yesterday to reanimate my Tolino page after trying to install OpenGapps on them (no, did not work oO).
I am not allowed to post URL's because of "Noob-Protection" in Forum. There is a "Tolino Vision 2 rooten" howto in web. Some parts of them you can use to solve your problem.
1. Create own ADB-Enabled custom recovery (Did worked for me only with 10.0.1 update package). Should be done on Linux
Code:
$ mkdir custom_recovery
$ cd custom_recovery
$ unzip ../update.zip recovery.img
$ mv recovery.img recovery.img.orig
$ abootimg -x recovery.img.orig
$ mv initrd.img initrd.img.orig
$ mkdir initrd
$ cd initrd
$ zcat ../initrd.img.orig | cpio -vid
Adjust default.prop with values "ro.secure=0", "ro.debuggable=1" und "persist.sys.usb.config=mass_storage,adb".
Code:
$ find . | cpio --create --format='newc' | gzip > ../initrd_adb_enabled.img
$ cd ..
$ abootimg --create recovery_adb_enabled.img -f bootimg.cfg -k zImage -r initrd_adb_enabled.img
You get error : "updated is too big for the Boot Image" with new size value. Calculate this value to hexadecimal and adjust the "bootsize" in "bootimg.cfg" to hex-value
Do abootimg again.
2. Use the custom recovery to trigger update manually
Code:
$ fastboot boot ../custom_recovery/recovery_adb_enabled.img
$ adb shell
# mount -t vfat /dev/block/mmcblk0p4 /sdcard/
# exit
$ adb push update.zip /sdcard/update.zip
$adb shell
# cd /sdcard
# busybox unzip update.zip META-INF/com/google/android/update-binary -d /tmp
# busybox chmod u+x /tmp/META-INF/com/google/android/update-binary
# /tmp/META-INF/com/google/android/update-binary 3 1 /sdcard/update.zip # Update installieren
# sync && sleep 5 && sync # sicherheitshalber, wenn man dran glaubt
# reboot
Source: google for "e-reader-forum Toolino vision 2 rooten"

[DEV] Ubuntu 18.04 LTS Bionic (Linux for Tegra) for SHIELD Android TV

This is a full featured port of NVIDIA L4T R32.7.2 (Ubuntu 18.04) for the SHIELD TV (2015, 2017). It has full hardware support including:
GPU acceleration
Wifi/Bluetooh
USB 3.0
HDMI with audio
microSD (supported models)
Power management
etc
Download​Download Latest (R32.7.2, 07/09/22)
Details​The main challenge in this port was getting the right kernel version to match with the on-device DTB. The DTB is structured in a way that Cboot must be able to parse (and modify it) and then Linux kernel must be able to parse it as well. There are various issue with previous documented methods of flashing a Jetson DTB. NVIDIA stopped distributing SHIELD TV (Foster) DTBs with L4T releases years ago so you would have to manually port a newer DTB or be stuck with an older kernel. Flashing an (years) older DTB is not an option because a newer Cboot will fail to parse it and you'll end up with a brick. Flashing a custom DTB is dangerous for this reason as well. Flashing an older Cboot is not possible due to signature requirements even on an unlocked device. So we are stuck with one option: build a L4T kernel around the device's Android DTB.
NVIDIA maintains two forks of Linux for Tegra X1. The L4T kernel and the Android (downstream) kernel are not 1-to-1 compatible. DTB property names can differ, ioctl structure sizes can differ, etc. I tried various ways to cleanly merge the two and ended up with the following working strategy:
Kernel 4.9 + NVIDIA drivers from Android fork
Build config from L4T release hand merged with options from the Android TV kernel
NVGPU drivers from L4T fork (due to lack of source for and need for compatibility with userland drivers)
Initramfs from L4T release
I also had to port some patches from one fork to the other (especially for NVGPU). The end result is a kernel that combines both forks and therefore is relatively stable and fully featured.
Booting​
The build is tested with the 9.0.0 and 9.1.0 release. It is recommended that you update to 9.0.0.
Note that once you update Cboot, you cannot downgrade to a lower version anymore! If you do not update, some things may not work properly due to the DTB differences noted above however, any relatively "modern" build may still work.
You need a USB drive with at least 8GB of free space. Flash rootfs.img to the first partition (replace sdX1 with your USB drive partition):
Code:
$ sudo dd if=rootfs.img of=/dev/sdX1 bs=1MiB
Make sure your SHIELD TV is unlocked and connected to fastboot.
Either boot the kernel directly:
Code:
$ fastboot boot boot.img
Or you may also flash the kernel if you want to:
Code:
$ fastboot flash boot boot.img
$ fastboot reboot
The initramfs will attempt to boot from the following devices (in order):
1. sda1: First partition of external USB on 16GB model
2. sdb1: First partition of external USB on 500GB model
3. mmcblk2p1: First partition of microSD on supported models
4. mmcblk0p29: Userdata partition of eMMC on 16GB model
5. sda32: Userdata partition of HDD on 500GB model
6. sda33: Partition 33 of HDD on 500GB model (partition table modification needed)
7. sda34: Partition 34 of HDD on 500GB model (partition table modification needed)
8. mmcblk0p19: System partition of eMMC on 16GB model (too small to hold rootfs unless partition table is modified)
After installation, you should resize the partition if your device is > 8GB (replace sdX1 with your installation device).
Code:
$ sudo e2fsck -f /dev/sdX1
$ sudo resize2fs /dev/sdX1
Flashing to internal eMMC​
If you wish to flash rootfs to your internal eMMC, you need to first install to a USB and boot into Ubuntu. Flashing from fastboot will NOT work due to some eMMC issues (I think Cboot does not respect the block remap).
The following will flash to the userdata partition and will WIPE any existing data on the device!
Code:
$ sudo dd if=rootfs.img of=/dev/mmcblk0p29 bs=1MiB
$ sudo e2fsck -f /dev/mmcblk0p29
$ sudo resize2fs /dev/mmcblk0p29
You can follow similar steps to flash to sda32 on a 500GB model. Follow the steps in the first section to flash boot.img.
Uninstalling​
As long as you didn't touch the other partitions, you can easily restore Android TV with the recovery images.
Code:
$ fastboot erase userdata
$ fastboot flash boot nv-recovery-image-shield-atv-9.0.0/boot.img
​Troubleshooting​The USB/microSD does not boot and is stuck at a blinking cursor
Make sure you wait long enough (at least five minutes).
Make sure your USB drive (or microSD) is formatted with MBR with a single partition. You should be writing to /dev/sdX1 (X is some letter) with a "1" at the end. Do not write to /dev/sdX.
Try to mark the first partition as bootable.
Manual Build​Download Latest (R32.7.2, 07/09/22)
Prerequisite​
Linux for Tegra R32.7.2
Linux for Tegra R32.7.2 Sources
Linux for Tegra R32.7.2 Root Filesystem
Jetson GCC Toolchain 32.2
NVIDIA SHIELD ANDROID TV 2015 Recovery OS Image 9.0.0
Utilities (apt install): simg2img, git, fastboot, abootimg
Building the kernel​
1. Install the toolchain.
Code:
$ wget -O toolchain.tar.xz https://developer.nvidia.com/embedded/dlc/l4t-gcc-7-3-1-toolchain-64-bit
$ tar xpf toolchain.tar.xz
$ sudo mv gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu /opt/l4t-toolchain
2. Fetch the SHIELD TV Android kernel sources.
Code:
$ git clone --depth 1 https://nv-tegra.nvidia.com/r/linux-4.9.git -b rel-shield-r-9.0.2-opensource-4.9 linux-4.9
$ git clone --depth 1 https://nv-tegra.nvidia.com/r/linux-nvidia.git -b rel-shield-r-9.0.2-opensource nvidia
3. Fetch the Linux For Tegra NVGPU sources.
Code:
$ wget https://developer.nvidia.com/embedded/l4t/r32_release_v7.2/sources/t210/public_sources.tbz2
$ tar xpf public_sources.tbz2
$ tar xpf Linux_for_Tegra/source/public/kernel_src.tbz2
$ mv kernel/nvgpu nvgpu
You should have three directories: linux-4.9, nvidia, and nvgpu
4. Patch the sources.
Code:
$ cat patches/kernel-4.9/*.patch | patch -p1 -dlinux-4.9
$ cat patches/nvidia/*.patch | patch -p1 -dnvidia
$ cat patches/nvgpu/*.patch | patch -p1 -dnvgpu
5. Build the kernel and install the modules.
Code:
$ export CROSS_COMPILE=/opt/l4t-toolchain/bin/aarch64-linux-gnu-
$ export ARCH=arm64
$ mkdir -p Linux_for_Tegra/rootfs/
$ pushd linux-4.9
$ make shieldtv_defconfig
$ make -j$(nproc) zImage
$ make -j$(nproc) modules
$ make modules_install INSTALL_MOD_PATH=../Linux_for_Tegra/rootfs/
$ sudo chown -R root:root ../Linux_for_Tegra/rootfs/lib
$ popd
Building Root Filesystem​
1. Extract jetson-210_linux_r32.7.2_aarch64.tbz2 and tegra_linux_sample-root-filesystem_r32.7.2_aarch64.tbz2.
Code:
$ tar xpf jetson-210_linux_r32.7.2_aarch64.tbz2
$ pushd Linux_for_Tegra/rootfs/
$ sudo tar xpf ../../tegra_linux_sample-root-filesystem_r32.7.2_aarch64.tbz2
$ sudo touch etc/nv_boot_control.conf
Note the use of sudo for the last two commands. This is required for file permissions to be correct. The touch at the end resolves a bug in NVIDIA's code that resulted in the installer not launching.
2. Install the filesystem.
Code:
$ cd ..
$ sudo ./apply_binaries.sh
$ popd
3. To enable Wifi and NVDEC, need to first convert vendor.img downlaoded from the SHIELD recovery image to an ext4 image.
Code:
$ simg2img nv-recovery-image-shield-atv-9.0.0/vendor.img vendor-raw.img
4. Next mount the image.
Code:
$ mkdir vendor
$ sudo mount -o loop vendor-raw.img vendor
5. Copy the firmware over.
Code:
$ sudo cp vendor/firmware/bcmdhd_clm_foster.blob Linux_for_Tegra/rootfs/lib/firmware/brcm/bcmdhd.clm_blob
$ sudo cp vendor/firmware/fw_bcmdhd.bin Linux_for_Tegra/rootfs/lib/firmware/brcm/fw_bcmdhd.bin
$ sudo cp vendor/firmware/nvram_foster_e_4354.txt Linux_for_Tegra/rootfs/lib/firmware/brcm/nvram.txt
$ sudo cp vendor/firmware/tegra21x/* Linux_for_Tegra/rootfs/lib/firmware/tegra21x/
$ sudo cp vendor/firmware/tegra21x/vic04_ucode.bin Linux_for_Tegra/rootfs/lib/firmware/nvidia/tegra210/
$ sudo umount vendor
6. Create and mount a new ext4 image. Note that we will create 8GiB image which should be enough to hold the root filesystem. After you flash it to your device and boot successfully, you'll want to run resize2fs.
Code:
$ dd if=/dev/zero of=rootfs.img bs=1MiB count=8196
$ mkfs.ext4 rootfs.img
$ mkdir mount
$ sudo mount -o loop rootfs.img mount
7. Copy the filesystem to the disk image.
Code:
$ sudo mv Linux_for_Tegra/rootfs/* mount/
$ sudo umount mount
Building boot image​
1. Extract the existing initramfs.
Code:
$ mkdir initramfs
$ pushd initramfs
$ cat Linux_for_Tegra/bootloader/l4t_initrd.img | gunzip -c | cpio -i
2. Patch init.
Code:
$ cp patches/initramfs/init init
3. Rebuild the image.
Code:
$ find ./ | cpio -H newc -o -R root:root | gzip -9 -c > ../initramfs.img
4. Build boot.img
Code:
$ abootimg --create boot.img -f patches/bootimg.cfg -k linux-4.9/arch/arm64/boot/zImage -r initramfs.img
I've updated the download to fix an issue I found with connecting to 5GHz wifi. Using the other nvram.txt fixed it. I also noticed that NVENC/NVDEC doesn't work properly and am unsure if it's a kernel issue or a L4T issue. I tried building with nvdec bootloader disabled and used L4T's ns firmware and it still didn't work.
EDIT: Made another update to fix the NVENC/NVDEC issue. Additionally, the led lightbar control driver is added in. I also made the following systemd script to disable the lightbar at boot.
Code:
[Unit]
Description=Disable the lightbar
After=multi-user.target
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/bin/sh -c "/sbin/rmmod leds-cy8c && /sbin/modprobe leds-cy8c"
ExecStart=/bin/sh -c "echo 0 > /sys/class/leds/led_lightbar/brightness"
ExecStop=/bin/sh -c "echo 255 > /sys/class/leds/led_lightbar/brightness"
[Install]
WantedBy=multi-user.target
Is this a fully working ubuntu desktop OS experience or is this a Kernel for the shield?
EgomafiaX said:
Is this a fully working ubuntu desktop OS experience or is this a Kernel for the shield?
Click to expand...
Click to collapse
Full Ubuntu 18.04, it’s not just a kernel. I’ve been using it for the past week and haven’t run into any issues so far. You can try it out without modifying anything by flashing rootfs.img to a usb drive and booting the kernel from fastboot.
Very Interesting, I just got my shield last week and i wanna try some few things on it. Don’t have any experience with flashing whatsoever
What's performance like? I was thinking of buying a new SBC but this could be just what I am looking for
moshtin said:
What's performance like? I was thinking of buying a new SBC but this could be just what I am looking for
Click to expand...
Click to collapse
Nvidia SHIELD TV Benchmarks in Ubuntu Shows Core i3 Like Performance - CNX Software
Nvidia SHIELD Android TV was announced this March with Nvidia Tegra X1 octa-core Cortex A57 + A53 processor. So far, I had not seen any Ubuntu or other
www.cnx-software.com
Hi!
Thanks for your work.
This seems promising. Any chance anything similar should work on SHIELD TV Pro (2019)?
I compared recovery images provided by NVIDIA and I did not come across many differences between vendor binaries so I guess there is won't be any issue with the roottfs and kernel.
However on the SHIELD TV Pro, the boot.img is twice as big and the recovery image seems to contain a DTB image (mdarcy.dtb.img) and a vbmeta.img. I suspect the boot process to be somewhat different on this plateform.
Did anyone manage to get anything working on a SHIELD TV Pro?
yifanlu said:
$ pushd kernel-4.9
Click to expand...
Click to collapse
I guess you meant:
Code:
$ pushd linux-4.9
yifanlu said:
$ sudo mv Linux_for_Tegra/rootfs/rootfs/* mount/
Click to expand...
Click to collapse
and
Code:
$ sudo mv Linux_for_Tegra/rootfs/* mount/
Also the shieldtv_defconfig is located in arm/ instead of arm64/ in the patches you provide.
I tried the instructions from the first post on a Shield TV (2017) model and after doing "fastboot boot boot.img" the screen goes black with a blinking underscore on the top left and gets stuck there.
Any idea on what could be wrong? I dd'ed the rootfs.img to a usb stick attached to the usb port adjacent to the hdmi port. The usb A->A cable for fastboot/adb is attached to the usb port away from the hdmi cable.
chaitan3 said:
I tried the instructions from the first post on a Shield TV (2017) model and after doing "fastboot boot boot.img" the screen goes black with a blinking underscore on the top left and gets stuck there.
Any idea on what could be wrong? I dd'ed the rootfs.img to a usb stick attached to the usb port adjacent to the hdmi port. The usb A->A cable for fastboot/adb is attached to the usb port away from the hdmi cable.
Click to expand...
Click to collapse
I also seem to have hit same roadblock, did you succed with this.
kihmathi said:
I also seem to have hit same roadblock, did you succed with this.
Click to expand...
Click to collapse
No, I have not been able to proceed. @yifanlu any hints on what we could do to debug?
I only have a 2015 shieldtv but I read the hardware are the same. Maybe I was wrong and there’s some kernel changes needed. I would diff the defconfig between the latest android release for both and see what the differences are. Then add those to the config.
EDIT: I downloaded the recovery image for 2017 and compared the kernel defconfig and it’s identical. That means the kernel isn’t the issue. My next guess would be the init script I wrote. Maybe the dev number is different on 2017?
Can confirm, I have the same issue on model P2897 not pro.
In my init script, I wait 10s for the root device to show up before giving up and trying the next one. Perhaps this isn’t long enough?
If you update the init file inside the initramfs, there is on line 71 “while [ ${count} -lt 20 ]” maybe change that to “while [ ${count} -lt 100 ]” to try 100 times (with 0.2s in between).
Could anyone here running this image try out https://github.com/cobalt2727/L4T-Megascript? It's been tested against the base model Nintendo Switch and a Jetson Nano, but no Shield hardware so far (although it should perfectly support it in theory)
yifanlu said:
In my init script, I wait 10s for the root device to show up before giving up and trying the next one. Perhaps this isn’t long enough?
If you update the init file inside the initramfs, there is on line 71 “while [ ${count} -lt 20 ]” maybe change that to “while [ ${count} -lt 100 ]” to try 100 times (with 0.2s in between).
Click to expand...
Click to collapse
I tried this on my 2017 shield, didn't fix the issue, there is a blinking underscore on the top left. Is there any way to get logs, or show some debug messages on the screen?

Categories

Resources