I've discovered a couple of more clues about the problem, but not enough to solve it yet. Apparently any process that attempts to reset its UID before executing execve gets killed. Since servicemanager wants to run as 1000 (for system), it gets killed. I've tried replacing the servicemanager executable with a shell script and the exact strace happens, so the problem has nothing to do with the servicemanager executable itself.
If I alter init.rc so that all services run as root, I get as far as the animated Android logo (before an unrelated Java exception stops the party). I don't suppose anyone has seen this setuid problem before? Thanks, David On Apr 16, 12:56 pm, David Wang <mirrorsp...@gmail.com> wrote: > On Apr 16, 4:59 am, mizmit1222 <mizmit1...@gmail.com> wrote: > > > Hi, > > > I guess you got very close to make a thing happen. > > ashmem - OK > > binder - OK > > /data fs type - ext2 - OK > > > Just double checking, but you do chroot to ext2 fs? > > Yes, as you can see at the bottom ofhttp://iphwn.org/planetbeing/postmortem/, > both init and strace is run under a chroot environment. > > > > > One more question. > > > It seems to me "adbd" is up. Is there any way to connect to your > > iPhone > > while booting up through USB or WiFi to get adb logcat? > > Yes, I've been connecting over wifi and running the commands. I did > actually obtain a logcat log (using cd /android; chroot . /system/bin/ > logcat > /data/blah) but I forgot to upload it. It is > here:http://iphwn.org/planetbeing/postmortem/logcat.log.txt(this is from a > different run) > > I don't think the logcat log says anything useful. This is after > servicemanager has started and exited a good few times. As you can > see, it seems like AndroidRuntime is being killed before it can do > anything. I'm not sure how adb works or how I can use it over the > network. This is only "day 2" of my Android experience. :) > > Another funny thing I've noticed is that if I kill init, the other > processes it spawns keep working and seem to do a little better. Then > I get stuck on Waiting for SurfaceFlinger, even though there's some > messages from SurfaceFlinger inside logcat. > > Also it may be important to note that the GPIO inputs have not yet > been implemented by me, and I've compiled in CONFIG_POWER_SUPPLY, but > I haven't yet put in an interface for it to communicate with the PMU > (so Android wouldn't be able to get power supply status or battery > status). The last thing is that the Android USB gadget drivers are not > working, but that is probably because the host driver I am using (Ben > Dooks's s3c-hsotg driver) seems to be almost unusably buggy on my > hardware. > > > > > > > Cheers, > > > On Apr 16, 1:00 pm, David Wang <mirrorsp...@gmail.com> wrote: > > > > So titled because my problem is very similar in symptoms to the thread > > > "Problem porting Android to OMAP". My port to the iPhone runs Debian > > > and X.org with the multitouch screen, sound, WLAN and USB gadget ether > > > net working fine. In order to maintain dual-boot capability, I put the > > > Android images on one of the iPhone's partitions (which is HFS+ on top > > > of Samsung's Whimory FTL on top of a few NAND chips) and I'm planning > > > on booting Android from that. I built the images from a checkout with > > > repo using the generic instructions fromhttp://pdk.android.com. I set > > > TARGET_USERIMAGES_USE_EXT2 in the environment so I get ext2 images. I > > > created a 1 MB ext2 image to store the ramdisk files instead of using > > > it as an actual initramfs. I modified the /init.rc to comment out the > > > mtd mounts, since my code will be mounting /system, /data and /cache > > > before Android's init is called. > > > > Android's /init doesn't seem to care if it's PID 1 (I've observed from > > > reading this mailing list), so I've been calling it from my > > > busybox/buildroot ramdisk. However, it doesn't seem to work. After > > > awhile, it will complain "init: critical process 'servicemanager' > > > exited 4 times in 4 minutes" and will reboot. I commented out the > > > "critical" specification for the servicemanager service in init.rc and > > > ran /init under strace. You can see all the logs that resulted as well > > > as the exact commands I performed > > > here:http://iphwn.org/planetbeing/postmortem/ > > > > kernel-config.txt is my kernel configuration, in case there is some > > > option I forgot to enable or some option I must not enable. My patches > > > to kernel/common android-2.6.32 (done on commit > > > e27f17b5318851395a66cbaf1524ea89ff8f0cb9) is also present in that > > > directory if those are helpful. Finally, here's what df shows: > > > > # df > > > Filesystem Size Used Available Use% Mounted on > > > /dev/root 9.2M 8.1M 1.0M 89% / > > > tmpfs 60.8M 96.0K 60.7M 0% /tmp > > > /dev/nand0p2 14.4G 1.4G 13.0G 10% /mnt > > > /dev/loop0 1003.0K 278.0K 674.0K 29% /android > > > /dev/loop1 72.1M 52.2M 20.0M 72% /android/system > > > /dev/loop2 193.7M 14.8M 168.9M 8% /android/data > > > /dev/loop3 48.4M 810.0K 45.1M 2% /android/cache > > > > I think that's enough space for Android. /dev/loop0 is ramdisk.img. > > > > From my analysis of the strace files, it seems as if servicemanager is > > > being sent SIGKILL by an unknown murderer soon after it starts > > > (http://iphwn.org/planetbeing/postmortem/strace.486.txt). None of > > > Android's init or its children seem to be to blame from the strace > > > outputs. Android's init DOES send a SIGKILL to servicemanager but only > > > after it receives a notification that it has already died. There's no > > > kernel messages (http://iphwn.org/planetbeing/postmortem/messages.txt) > > > that indicate that some OOM killer is at work (unless Android's > > > LOW_MEMORY_KILLER is utterly silent). I certainly did not kill the > > > process myself. > > > > Ignore the stuff in messages.txt about the multitouch firmware > > > requests. I didn't bother to send the firmware for that test but it > > > doesn't make a difference if I load the firmware before running > > > Android's init. > > > > I don't own an Android-capable phone so I can't even test whether the > > > images produced by my build are sane at all. Anyone have any hints > > > about what could be happening? Is there an alternate track I should be > > > following? > > > > Thanks, > > > > David > > > > -- > > > unsubscribe: android-porting+unsubscr...@googlegroups.com > > > website:http://groups.google.com/group/android-porting > > > -- > > unsubscribe: android-porting+unsubscr...@googlegroups.com > > website:http://groups.google.com/group/android-porting > > -- > unsubscribe: android-porting+unsubscr...@googlegroups.com > website:http://groups.google.com/group/android-porting -- unsubscribe: android-porting+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-porting
