rufus mkusb from android persistence boot

android - mkusb - Realice cambios persistentes en init.rc



rufus (8)

Quiero cambiar el archivo init.rc de una plataforma de Android. Pero después de cambiarlo y reiniciar el sistema, vuelve el init.rc original.

¿Cómo puedo hacer el cambio al init.rc persistentemente sin reconstruir el sistema (ya que no tengo el código fuente del sistema)? ¿O hay alguna forma de evitarlo?

Cuando se inicia un sistema Android, uboot descomprime una bola comprimida especial de archivos en su partición de arranque llamada ''uRamdisk'' en la RAM, y define esos archivos para que comprendan el directorio raíz del sistema. uRamdisk normalmente contiene un grupo de directorios (sistema, datos, medios, etc.) que sirven como puntos de montaje para particiones que contienen los archivos que van dentro de ellos, pero también tiene algunos archivos básicos que son vitales para su sistema, incluidos el inicio y el inicio de init. scripts como init.rc.

Cuando edite init.rc, en realidad acaba de editar la copia no empaquetada de init.rc que reside en su RAM. Para cambiarlo realmente, debe copiar su uRamdisk, extraerlo, editar el init.rc desde allí, volver a empaquetar uRamdisk y luego reemplazar el nuevo con el anterior en / boot.

Intente buscar los scripts ''xuramdisk'' y ''mkuramdisk'', estos hacen que el proceso sea muy simple.

Desempaquete el uramdisk usando el siguiente comando en la PC host (Linux)

mkdir /tmp/initrc cd /tmp/initrd sudo mount /dev/sdb1 /mnt

sdb1 es una partición donde reside uramdisk/uInitrd .

dd bs=1 skip=64 if=/mnt/uInitrd of=initrd.gz gunzip initrd.gz

En este punto, ejecutar el file initrd comando file initrd debe mostrar:

mkdir fs cd fs cpio -id < ../initrd

Realice cambios en init.rc

Pack uramdisk usando los siguientes comandos:

find ./ | cpio -H newc -o > ../newinitrd cd .. gzip newinitrd mkimage -A arm -O linux -C gzip -T ramdisk -n "My Android Ramdisk Image" -d newinitrd.gz uInitrd-new

No sé si todavía estás intentando hacer esto, pero sin conocer tu dispositivo exacto, nadie puede darte una respuesta exacta.

Intente tomar una dd image de todas sus particiones internas y use algunos scripts como los que se incluyen con la cocina android en los foros de xda. Sus particiones de recuperación y arranque tendrán un disco RAM, pero es probable que desee modificar el init.rc en el boot.img no en la recuperación, a menos que solo desee los cambios presentes en el modo de recuperación.

La función Unyaffs no se aplica a todos los dispositivos y la mayoría de los dispositivos tienen diferentes diseños de particiones, por lo que debe averiguar cuál es el arranque y qué tipo de fs es. Tal vez si le da las especificaciones de su dispositivo puede obtener una mejor respuesta.

Su partición raíz (donde vive /init.rc) es un ramdisk que se desempaqueta de un archivo initrd y se monta cada vez que se inicia el dispositivo. Cualquier cambio que realice se aplicará únicamente al disco RAM y se perderá el próximo reinicio.

Si puede obtener el archivo initrd, puede montarlo en su sistema host Linux, modificar los archivos allí, desmontarlo y volver a escribirlo en su Android.

El archivo initrd existe en su propia partición en el dispositivo. Si puede averiguar qué partición es, puede tomarla del dispositivo en su host, montarla, modificarla y volver a escribirla en el dispositivo. De esto es de lo que el tripler estaba hablando arriba.

En general, modificar boot.img es algo que solo los desarrolladores de sistemas hacen. Si está construyendo todo el sistema Android, tendrá acceso al código fuente necesario. Mi flujo de trabajo para esto se ve así:

# Modify init.rc m -j8 bootimage_signed adb reboot bootloader fastboot flash boot $OUT/boot.img fastboot reboot

Tienes que editar / cambiar el init.rc antes de construir tu sistema de archivos pad Android. Esta es la forma preferida, y siempre funciona.

Varios dispositivos Android incluyen código para evitar modificaciones de raíz en los archivos del sistema. La forma en que esto se hace es usar la partición de recuperación. Al reiniciar, básicamente restauran la partición del sistema usando la imagen de recuperación. Si su sistema está haciendo eso, entonces no puede hacer cambios persistentes: lo mejor que podría hacer sería conectar algo para ejecutar después del reinicio para volver a aplicar su cambio. En CyanogenMod tenían ganchos en init.rc para ejecutar los scripts de sdcard si los encontraban. Tal vez pueda crear una aplicación o artilugio para luego lanzar una secuencia de comandos para hacer las modificaciones requeridas usando un script raíz setuid de la partición de datos. Sin construir tu propia ROM, estás bastante restringido en esta área.

Es posible que pueda obtener la imagen de recuperación e intentar desempaquetarla, realizar los cambios y volver a empaquetarla y flashearla. Pero asegúrate de que puedes recuperar con fastboot antes de intentar esto.

Tenga en cuenta que puede ser más fácil para usted utilizar una aplicación como Scripter para ejecutar un script en el momento del arranque que modificar este archivo.

Antes de seguir las instrucciones de @ tripler anteriores, necesita un archivo llamado boot.img que se puede extraer (ejecutar en un dispositivo Android rooteado, sin probar sin root):

dd if=/dev/block/platform/<someplatform>/by-name/boot of=/sdcard/boot.img

Luego conecta tu Android a tu computadora y copia el archivo boot.img desde allí.

Guión:

http://linuxclues.blogspot.ca/2012/11/split-bootimg-python-android.html

Aquí hay una versión modificada y más fácil de ver de las instrucciones del tripler (suponiendo que boot.img está en tmp):

cd /tmp mkdir fs # Now use the linked script above to split the boot.img file into ramdisk.gz and kernel python split_boot_img.py -i boot.img -o parts cd fs gunzip -c ../parts/ramdisk.gz | cpio -id # make changes to init.rc

En ese momento, tendrá que volver a compilar boot.img antes de volver a aplicar el brillo, que será específico del dispositivo. No puedo ayudarte con eso, lo siento!