Bug#539744: chroot to lenny /target in debootstrap segfaults

[Frans Pop <elendil@planet.nl>]

On Tuesday 04 August 2009, Ferenc Wagner wrote:
> The two traces are very similar indeed.  What I could spot:
>  * /target vs. /target/ on the command line.

That's just from auto-completion. Not relevant.

>  * The new chroot binary reads 4 bytes from urandom and does an extra
>    mprotect before chrooting; the old one does not.  I don't know what
>    it is, maybe an extra tripwire which (the new?) mount manages to
>    trip, or some new type of randomization which mount isn't prepared
>    for...  Just guessing.
>
>  * The new fstab is 841 bytes, the old is 492.

That's because it now contains UUID= instead of /dev/[hs]dX.

>  * The new mount does some prctl trickery, and in general starts to do
>    very different things (reads /etc/blkid.tab, /proc/whatever) just
>    before segfaulting.  Maybe it tries to use UUID-s or labels to
>    achieve device persistence, and makes an invalid memory access
>    analyzing the data.

Note that it is not "the new mount"; the version of mount is identical.
But I guess that must be it: the change from /dev/[hs]dX to UUID=.

And yes, replacing the UUIDs in the fstab by regular devices gets rid of 
the segfault. Still weird that an empty mtab avoids it though.

Colin, any thoughts (given that you implemented the switch to UUID)?

> All in all it looks like some of the above reveal a bug in mount.  The
> segfault does not come from the kernel, but from application code, as
> I see it.

Question is whether we have a realistic chance of fixing that bug or not. 
After all, we are talking about mount in *stable*.