First, I don't believe there is an issue with apt-get, but I am trying to understand what about my setup is causing apt-get update to fail. If this is not the correct place to email that type of issue, please direct me to the correct list.
Second, my setup is weird. I am developing a new PRoot extension for GNURoot. PRoot allows non-root users to do something like chroot, but by intercepting system calls as opposed to the fakechroot.so method. GNURoot is an Android app that allows running standard Linux distros on an non-rooted device. This new extension is allowing most of the files to be on the sdcard (a vfat noexec, nosetuid partition). The directory structure, special files and symbolic links are on the internal ext3 partition and anything needed to run a program is copied from the vfat to ext3 as needed. This is all done in a way that running programs don't know that anything is funny. Like I said, weird.
What is working... I have partitions and directory structures setup to mimic Android on my debian x86 install and there I can PRoot (with described custom extension) into an armhf rootfs and do apt-get update, apt-get install etc just fine.
What is not.... When I do this on an actual Android device apt-get update is failing. I am looking for any suggestions on how to debug.
From debug info from PRoot and normal output from apt-get, I can see that the files have all been downloaded correctly and apt-get is in a process of doing something like this...
Good scenario on Debian machine setup to have an armhf rootfs and partitions and directories like android
1) rename /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp.ZxSd /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp
2) stat /var/lib/apt/lists/partial/...main_binary-armhf_Packages - exists
3) stat /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp - exists
4) open /etc/localtime
5) stat /var/lib/apt/lists/...main_binary-armhf_Packages - does not exist
6) open /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp
7) fstat /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp - exists
8) rename /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp /var/lib/apt/lists/...main_binary-armhf_Packages
9) move onto doing similar for ....contrib_binary-armhf_Packages*
Bad scenario on Android device
1) rename /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp.ZxSd /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp
2) stat /var/lib/apt/lists/partial/...main_binary-armhf_Packages - exists
3) stat /var/lib/apt/lists/partial/...main_binary-armhf_Packages.decomp - exists
4) Move onto doing similar for ...contrib_binary-armhf_Packages* and print out "Err
http://ftp.debian.org wheezy/main armhf Packages"
So, I am guessing there is something that apt-get did not like when it did the stat calls in steps 2) and 3) when running on an Android device, but I am not sure what. Is someone familiar with this part of apt-get update? I believe the code that is most pertinent is in apt-pkg/acquire-item.cc (at least that is where I see the renaming of the decomp files). What checks are being done on these files to make sure they are as expected? Is there anyway to get more verbose information about this failure from apt-get?
Thanks,
Corbin Champion