AOSP Part 1 (A New Hope) - Motorola Droid X2

This is a think tank for making 2nd init load aosp based roms. It currently loads only init.rc. Attached below is the zip file I have made of where I currently stand with 2nd init. Please only download it if you want to help fix it. It probably doesnt work yet.
2nd init is further than the attached in this build (This is a full CM build) The script that is currently being hammered out is mot_boot_mode inside of /system/bin/ Also note that I have made the update script work in the build.
http://www.multiupload.com/4QG0NHCRG7

---

Hope this is what you needed:
http://www.multiupload.com/X0GM6Q60S3

---

Here ya go extracted boot.img from cm7-atrix nightly
rename it to .tgz as it wouldnt let me upload that lol
This is the ramdisk uncompressed did you need the kernel as well?

---

Nope, no need for the kernel. Checking those files now.
Edit: That was exactly what I needed, thanks!

---

K im asking the X and D2G devs for help with how to make it load a hijack zip rather than what it's doing. Hopefully we have this fixed soon. I know whats wrong but I just can't get it to work right. It isn't drawing the screen when I use the wrapper because it doesnt use the task sets so I am seeing if the shell script we use to execute we could make it load a hijack zip.

---

Good luck, this community can be secretive @ times
I suspect this thread will gradually decline like the other so i if can suggest, change the title to status update. And continue to update the top post with the newest info. And a mod might wanna move it to general but i personal think it should be here as it is an active dev project.
I think in this way maybe we can start to have a public dev conversation and perhaps pool efforts from others that have similar goals. I know of a few others that are tackling the same issues for different purposes.
Seems the ways things are set up here it discourages anything but releases in the dev section. Perhaps its time for a dev q&a forum lol ...
Allot of things make our situation unique which draws allot of blank stares in the general dev forums.
EDIT:
Yay 200th post lol

---

aceoyame said:
K im asking the X and D2G devs for help with how to make it load a hijack zip rather than what it's doing. Hopefully we have this fixed soon. I know whats wrong but I just can't get it to work right. It isn't drawing the screen when I use the wrapper because it doesnt use the task sets so I am seeing if the shell script we use to execute we could make it load a hijack zip.
Click to expand...
Click to collapse
Im not familiar with a hijack.zip this being my first android device.. Is it a zip to replace the contents of the init ramdisk?? If so why not just use some space in /system?

---

mastafunk said:
Im not familiar with a hijack.zip this being my first android device.. Is it a zip to replace the contents of the init ramdisk?? If so why not just use some space in /system?
Click to expand...
Click to collapse
As far as I know, it loads 2nd-init via exec command, which init then loads and does a hijack.killall and KILLS everything in sight, and then remounts /system as whatever it's booting so recovery would become /system. I think that's how it works? It's all so confusing to me.
aceoyame: You might benefit from getting in touch with RevNumbers, he does nightlies for the CM 4 Droid X w/ Gingerbread Kernel, so he has a lot of experience with 2nd-init and how to make it work.

---

0vermind said:
As far as I know, it loads 2nd-init via exec command, which init then loads and does a hijack.killall and KILLS everything in sight, and then remounts /system as whatever it's booting so recovery would become /system. I think that's how it works? It's all so confusing to me.
Click to expand...
Click to collapse
The implementations i have seen launch second init via a bash hijack or a mount script. The other stuff you describe is a function of second init, and not of any hijack.zip. From searching elsewhere it looks like a hijack.zip is a compressed filesystem for 2ndinit potentialy containing init scripts etc.. but i could be way off..
So this may be beating a dead horse but is there source for our specific 2ndinit?
The answer to why ours functions different has to be in there..
Got it. Research indicates the hijack.zip is cm teams answer to keeping the boot image seperate for device which need 2nd-init it is just the boot filesystem should be similar to the files i posted earlier except for a specific device. The Question i am asking is since 2ndinit is up why not parse those from elsewhere, the nameless series roms limited implementation threw them in /system/etc/rootfs why not pickup from there.. or are you intent with trying to make an official port? Does cm maintain the source for the 2ndinit on supported hardware? If so diffing those to the source for ours should put us in a solid direction as far as a cm port goes...
And for anyone that doesnt know where im coming from im a long time linux dev, but fairly new to android and this is my first android device so be nice

---

2nd init is maintained for supported devices. As for contacting revnumbers... I already was in contact with him lol. I worked with him on the D2G for a lot of things. Really our best contact would be to see if CVPCS can figure out what we need to do exactly. All we need to do is expand that task set but I myself am not sure how it works just yet. If you look in that shell script it calls on the task set and copies init.rc into /system/etc/rootfs. Seems like we need to make ALL of the files for our hijack zip copy into there. Right now the atrix ramdisk should be enough to boot at least. We just need to get it loaded lol. Oh and I don't think CM team actually maintains the Hijack zips, I think they pull it from a seperate repo. But it is maintained for supported devices.

---

aceoyame said:
2nd init is maintained for supported devices. As for contacting revnumbers... I already was in contact with him lol. I worked with him on the D2G for a lot of things. Really our best contact would be to see if CVPCS can figure out what we need to do exactly. All we need to do is expand that task set but I myself am not sure how it works just yet. If you look in that shell script it calls on the task set and copies init.rc into /system/etc/rootfs. Seems like we need to make ALL of the files for our hijack zip copy into there. Right now the atrix ramdisk should be enough to boot at least. We just need to get it loaded lol. Oh and I don't think CM team actually maintains the Hijack zips, I think they pull it from a seperate repo. But it is maintained for supported devices.
Click to expand...
Click to collapse
Nathan,
CVPCS is on Twitter. I've found that to be the best stream to contact him from. He seems to be pretty responsive. Although, he hasn't posted anything in like 5 days. He seems to have dropped off the face of the earth.

---

I asked on IRC in #koush and this might be helpful:
(11:30:47 PM) CEnnis91: the only thing i would have to guess is that you're not starting a service that draws the screen
Click to expand...
Click to collapse
Also here is our init.rc uploaded in pastebin, with syntax highlighting. Perhaps it will be helpful, if indeed there is a service that needs to be started, it would probably be in one of these files:
init.rc: http://pastebin.com/kRmnArby
init.mapphone_cdma.rc: http://pastebin.com/qrBpqxGq
init.mapphone_umts.rc: http://pastebin.com/kRmnArby

---

Btw links #1 and #3 are the same.
I'd like to take a look at several files / outputs from the X2:
Files needed:
/init.rc (or fixed link above)
And the ouput of these adb / terminal commands:
cat /proc/mounts
cat /proc/partitions
cat /proc/cmdline
busybox df

---

Code:
$ cat /proc/mounts
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
/dev/block/mmcblk0p12 /system ext3 ro,noatime,nodiratime,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p16 /data ext3 rw,nosuid,nodev,noatime,nodiratime,errors=continue,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p15 /cache ext3 rw,nosuid,nodev,noatime,nodiratime,errors=continue,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p3 /pds ext3 rw,nosuid,noexec,relatime,data=ordered 0 0
/dev/block/mmcblk0p17 /preinstall ext3 ro,nosuid,nodev,noatime,nodiratime,data=ordered 0 0
/dev/block/vold/179:33 /mnt/sdcard-ext vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/mnt/sdcard-ext /mnt/sdcard-ext ecryptfs rw,dirsync,nosuid,nodev,noexec,relatime,ecryptfs_sig=36933d94cc9c5e9b,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough,no_new_encrypted 0 0
/dev/block/vold/179:18 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:18 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
/mnt/sdcard /mnt/sdcard ecryptfs rw,dirsync,nosuid,nodev,noexec,relatime,ecryptfs_sig=36933d94cc9c5e9b,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_passthrough,no_new_encrypted 0 0
Code:
$ cat /proc/partitions
major minor #blocks name
179 0 7747072 mmcblk0
179 1 3584 mmcblk0p1
179 2 512 mmcblk0p2
179 3 2048 mmcblk0p3
179 4 1 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 512 mmcblk0p6
179 7 512 mmcblk0p7
179 8 1024 mmcblk0p8
179 9 2048 mmcblk0p9
179 10 8192 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 460800 mmcblk0p12
179 13 512 mmcblk0p13
179 14 20480 mmcblk0p14
179 15 315392 mmcblk0p15
179 16 2097152 mmcblk0p16
179 17 307200 mmcblk0p17
179 18 4516864 mmcblk0p18
179 32 15558144 mmcblk1
179 33 15554048 mmcblk1p1
Code:
# cat /proc/cmdline
[email protected] [email protected] vmalloc=224M video=tegrafb console=null usbcore.old_scheme_first=1 tegraboot=sdmmc tegrapart=mbr:1100:100:800,kpanic:2500:400:800 security=tomoyo mot_prod=1 androidboot.serialno=TA05406FDO
Code:
# busybox df
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 206888 56 206832 0% /dev
tmpfs 206888 0 206888 0% /mnt/asec
tmpfs 206888 0 206888 0% /mnt/obb
/dev/block/mmcblk0p12
458562 201471 257091 44% /system
/dev/block/mmcblk0p16
2064204 115632 1948572 6% /data
/dev/block/mmcblk0p15
305420 10287 295133 3% /cache
/dev/block/mmcblk0p3 1980 1139 841 58% /pds
/dev/block/mmcblk0p17
305793 130975 174818 43% /preinstall
/dev/block/vold/179:33
15549952 875136 14674816 6% /mnt/sdcard-ext
/mnt/sdcard-ext 15549952 875136 14674816 6% /mnt/sdcard-ext
/dev/block/vold/179:18
4508040 3258836 1249204 72% /mnt/sdcard
/dev/block/vold/179:18
4508040 3258836 1249204 72% /mnt/secure/asec
tmpfs 4508040 3258836 1249204 72% /mnt/sdcard/.android_secure
/mnt/sdcard 4508040 3258836 1249204 72% /mnt/sdcard
init.rc @ http://iswarm.net/init.rc

---

Hashcode said:
Btw links #1 and #3 are the same.
I'd like to take a look at several files / outputs from the X2:
Files needed:
/init.rc (or fixed link above)
And the ouput of these adb / terminal commands:
cat /proc/mounts
cat /proc/partitions
cat /proc/cmdline
busybox df
Click to expand...
Click to collapse
I have all those files, I had to pull them for CVPCS a while back. How do those help in making 2nd-init work right. I haven't really looked at em so sorry if it's obvious.
Sent from my DROID X2 using XDA App

---

Here is a PM I had from dragonzkiller about a week ago.
Hey, I've appeared to lost my old 2nd-init for CM7. I think that I may actually be able to find it later. I know that you can use mot_boot_mode. Basically if you look at the C code for the hijack that is used for the other motorola devices for CM7 it's really close, but I used a shell script instead. These are the thing that have to happen:
1.Remount the rootfs and system directories as rw
2.rename adbd to adbd.old in /sbin
3.setprop ctl.stop runtime
4.setprop ctl.stop zygote
5.setprop persist.service.adb.enable 1 (this might not work, but I have a new method that actually starts it)
6.mkdir /preinstall
7.mount -t ext3 /dev/block/mmcblk0p17 /preinstall
8./preinstall/update-binary 2 0 NAMEANDPATHOFUPDATE.zip
9.cp -f /NEWROOTPATHFROMUPDATEZIP/* / (CM7 creates a directory named /newboot and all those files will get copied to the rootfs)
10.run the hijack.killall script from the CM7 hijack. (NOTE: you must remove all the references to hijack because we're not using the standard method. just use the regular ones and you'll be fine)
11./sbin/taskset -p -c 0 1 (taskset can be in you update zip)
12./sbin/taskset -c 0 /sbin/2nd-init (this should stop 2nd-init and restart with a new init.rc that you created and copied overy after using the update zip)

---

Here is the way I edited my script, going to test it in a bit here.
#!/system/bin/sh
PATH=/system/xbin:/system/bin
mount -o remount,rw rootfs /
mount -o remount,rw /system
rename /sbin/adb /sbin/adb.old
setprop ctl.stop runtime
setprop ctl.stop zygote
setprop persist.service.adb.enable 1
mkdir /preinstall
mount -t ext3 /dev/block/mmcblk0p17 /preinstall
/preinstall/update-binary 2 0 /system/etc/hijack-boot.zip
cp -f /newboot/* /
/sbin/hijack.killall
/sbin taskset -p -c 0 1
sbin/taskset -c 0 /sbin/2nd-init

---

I think your looking for 'mv' not 'rename' ..
Can you link me to where you got your implementation of 2nd init, so i can play as well...

---

How would mv rename it? I didnt get that part, but rename should work I would imagine.

---

My system doesnt respond to rename mv is the linux equivalent you 'move' the file to a new name, mv oldfile.txt newfile.txt ..
# cd tbin
# ls
mount.sh
unmount.sh
mrw
mro
# rename mro mrx
rename: not found
# mv mro mrx
# ls
mount.sh
unmount.sh
mrw
mrx
#
Click to expand...
Click to collapse