Roger Leigh wrote: > Bob Proulx wrote: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665827 > > Note that this is a bug against initscripts, not debianutils. Yes. But both are buggy! I also filed a bug against ischroot. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685034 > Is the problem due to ischroot not working in your chroot? > Or is it due to initscripts not using the return value properly? It is both. But the initscripts bug is the most grevious since it ignores an error condition and leaves the system in a bad state. True that ischroot returns the first error. But initscripts ignores the error. > If it's a deficiency in the ischroot tool, then please file a > bug against debianutils about it. If it's the latter, then > a followup to the above bug is appropriate. I did that too. > In the above bug's case, ischroot returns zero if it's a chroot, > 1 if it's not a chroot, and 2 if it wasn't possible to tell. We > only run the chroot codepath if we get a zero value back, > otherwise we run the standard codepath for a base system. I'm > not sure that there's a more reasonable solution here--we don't > have the information to make a better choice if it's 2. So it > would be useful to know exactly what the return value of > ischroot is (it must be run as root), and why. There are two issues. And I know that the /run transition was discussed at length in debian-devel. Unfortunately I wasn't following it then and only run into this problem now. I think using bind mounts in either of the two cases is an unfortunate choice. I *really* dislike it. So for me one issue is that the transition uses bind mounts at all. But I am still investigating. I haven't figured out why initscripts takes two different paths depending upon being in a chroot or not. I think that is the root cause of the problem. Whatever it decides to do it should to the same thing in either case. Regardless the chroot problem is that initscripts upgrade in a chroot leaves the host system with three additional bind mounts in the chroot. These make working with the chroot by traditional means difficult. For example in my test case I ended up with these additional mounts which are invisible inside the chroot. /dev/disk/by-uuid/19984135-8072-4091-a260-2466f14297a5 /srv/chroot/squeeze-test/run ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0 /dev/disk/by-uuid/19984135-8072-4091-a260-2466f14297a5 /srv/chroot/squeeze-test/run/lock ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0 /dev/disk/by-uuid/19984135-8072-4091-a260-2466f14297a5 /srv/chroot/squeeze-test/run/shm ext4 rw,relatime,errors=remount-ro,barrier=1,data=ordered 0 0 Which means that basic operations on the chroot fail: # rm -rf squeeze-test rm: cannot remove `squeeze-test/run/lock': Device or resource busy rm: cannot remove `squeeze-test/run/shm': Device or resource busy rm: cannot remove `squeeze-test/var/run/lock': Device or resource busy rm: cannot remove `squeeze-test/var/run/shm': Device or resource busy # find squeeze-test -print squeeze-test squeeze-test/run squeeze-test/run/lock squeeze-test/run/shm squeeze-test/var squeeze-test/var/run squeeze-test/var/run/lock squeeze-test/var/run/shm # umount /srv/chroot/squeeze-test/run/shm # umount /srv/chroot/squeeze-test/run/lock # umount /srv/chroot/squeeze-test/run # rm -rf squeeze-test But worse is that in order to continue to use the chroot that the /run configuration needs to be manually re-stitched. Bob
Attachment:
signature.asc
Description: Digital signature