Device files missing - Githubissues

monnier commented 11 years ago

My Mele-A2000 has a /dev/block/sda under Android, but in Debian's chroot there's no corresponding file. I think the start-debian.sh script should "mount -o rbind /dev /debian/dev" instead of selectively binding /dev/.

I added a "test-mount-bind /dev" just before the "mount...devpts" in start-debian.sh to work around this problem.

I think it would also be convenient to do something like

mkdir /debian/android
mount -o rbind / /debian/android

so as to make it easy to access any Android-side file from Debian.

monnier commented 11 years ago

Still trying to figure out how to get my modification to start-debian.sh to stick (it seems like the file is re-created each time). Any hint, where (from) it gets recreated?

eighthave commented 11 years ago

Oops, yeah, it uncompresses the file from the apk each time the app is started for the first time after boot. That was mostly left in there because I didn't have time yet to make it know how to upgrade the scripts. I recommend working with the source, its not hard to built if you have the Android SDK and NDK setup on Debian, Ubuntu, etc. Otherwise, I'll make this change on the next update.

monnier commented 11 years ago

I don't have the SDK installed (and don't feel like installing it, since I'm mostly interested in using Android "as-is", and relying on Debian for any "non-stock" needs). But my main point was the lack of /dev/block/sda because you don't do "test-mount-bind /dev".

eighthave commented 11 years ago

Ok, that latest version of LilDebi in git no longer blows away app_bin every time, but instead checks the VERSION file. So now you should be able to edit the scripts and having Lil Debi use them.

About the /dev/block/*, its bizarre that it doesn't show up in Debian, I don't understand why. /dev/block is not listed as a mount, so it should fall under the /dev/ mount. Also, busybox mount does not have the rbind option: http://www.busybox.net/downloads/BusyBox.html#mount I have found for loop[0-7] devices, they show up as /dev/block/loop[0-7] on Android, but it seems the same devices are listed as /dev/loop[0-7] under Debian

eighthave commented 11 years ago

Also about mount -o rbind / /debian/android, I couldn't get anything like that working, it just didn't mount. Let me know if you get it working because it would be quite handy to have.

monnier commented 11 years ago

Right, the /dev/block problem is not so much that /dev/block doesn't show up, but that LilDebi's /dev is static. Since I couldn't easily change LilDebi (e.g. to "mount -o bind /dev /debian/dev"), I just do a "mount -o devtmpfs /dev" which does then give me easy access to sda and such. Regarding the ext2 problem, I worked around it by using a small LilDebi ext2 install and whose startup script does a pivot_root to an ext4 partition (on the HDD) and then unmounts the ext2 one read-only. That also avoids problems linked to slow writing to the nand. And as for "mount -o bind / /debian/android" I couldn't get it working either. That's too bad because it prevents Debian from accessing Android's init files. I wonder why/how this bind mount is disallowed.

eighthave commented 11 years ago

I couldn't figure out how to get your mount -o devtmpfs /dev/ command to work. Should it work just like that? If so, looks like my device's kernel doesn't support devtmpfs.

monnier commented 11 years ago

The command I use is "mount -o devtmpfs devtmpfs /dev", but indeed it might be that devtmpfs is not compiled in your kernel. In any case, LilDebi shouldn't use that approach (it's just a workaround I use in my Debian startup script). It should "mount -o bind /dev /debian/dev" instead.

eighthave commented 11 years ago

Oops, didn't mean to close this, I have no idea how that happened, github glitch I guess. Have you tried mount -o bind /dev /debian/dev? What are the hazards? I wonder if having Debian create nodes in /dev/ will mess up Android? Maybe this should be optional?

monnier commented 11 years ago

I don't think Debian will create nodes in /dev unless you use udev. I don't think there's a need for an option, since Debian's startup script can easily "umount /dev" if using Android'd /dev is a problem.

monnier commented 11 years ago

Oh, and yes, I did try the "mount -o bind /dev /debian/dev" trick and it worked fine (except for the fact that I needed to change LilDebi's script to get it, which was overwritten all the time, which is why I switched to using devtmpfs).

eighthave commented 11 years ago

Ok, keep me posted on how that works for you. I'd like to include it, I'm just worried about it messing up Android. I want to make LilDebi as uninvasive as possible so that it keeps the phone and the Debian chroot both as reliable as possible. 0.4 is going to be posted soon to the Play store, it no longer overwrites app_bin, and even saves old versions when it upgrades app_bin. That should make it much easier for you to mess with the scripts :)

Alexander-- commented 11 years ago

I have been testing the setup in question for a while. It is mostly ok, except for:

Android /dev/log/* (e.g. native logging layer, used by logcat) conflicts with syslog's /dev/log, so syslog daemon won't work in this configuration (actually, it works, but apps, using syslog call in glibc, fail to write logs). Can be "cured" by using sed to replace occurences of "/dev/log" in libc.so with something like "/dev/lol" and reconfiguring logging daemon appropriately, then holding libc in apt-get.
Stuff like udev/mdev/driver packages may create nodes in /dev, which potentially may conflict with inner working of Android (very improbable, IMO). People should be warned, that casually running system-level software in LilDebi/Android may have the same oucome as in any other Linux system, and using any of those inside LilDebi is pure insanity anyway. Installing and running udev by accident may only happen on graphical installs, if user runs the earliest startup scripts. Device management on Android is handled by system itself, so init scripts should be edited to never start udev and held as well.

With all of that in mind, bind-mounting /dev is absolutely essential for proper integration with Android system. Just few examples:

(already mentioned) accepting new devices
running ANY Android applications from inside chroot ( am, logcat etc. fail without /dev, most likely due to liblog.so, failing to open /dev/log/*)
(potentially) using Wayland (/dev/graphics/*)

eighthave commented 11 years ago

Thanks for this info, its very helpful. One thought about udev: I think there is a way to configure apt to ban certain packages. Sounds like Lil' Debi should add such bans on certain packages that are very likely to wreak havoc.

eighthave commented 10 years ago

sure, if someone submits a patch to do it. I've never worked with /dev/tun so I won't know how it should be handled in the chroot.

tvass commented 10 years ago

For info, I managed to get "/dev/tun" in the Debian chroot by simply "cp -a" from Android original /dev... PS : I removed my previous comment about /dev/tun as i think it was not really related to this issue. Thanks for answer, sorry for the noise.

guardianproject / lildebi

Device files missing #41