Bug#539744: chroot to lenny /target in debootstrap segfaults
Frans Pop <elendil@planet.nl> writes:
> On Monday 03 August 2009, Ferenc Wagner wrote:
>
>> I can't see anything strange in it now, but it would be interesting to
>> know whether it depends on the contents of /target/etc/mtab (what if
>> you delete it before the mount?). Having an strace of a second
>> (successful) run might also provide a clue.
>
> Interesting. /target/etc/mtab does not exist yet at that point.
> A 'touch /target/etc/mtab' before the chroot mount gets rid of the
> segfault...
>
> And fun, fun, fun, after mount has segfaulted the file has magically been
> created (empty), which explains why a second attempt does not segfault.
>
> So, what the @$#@ has changed that makes a Lenny install suddenly fail
> when a Squeeze D-I is used instead of a Lenny D-I?
The two traces are very similar indeed. What I could spot:
* /target vs. /target/ on the command line.
* 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.
* 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.
See for yourself like this:
$ diff -u <(sed 's/[^a-z]*//i;s/0x[0-9a-f]*/ADDR/g;s/10914/PID/g;/^read(/s/".*"/STRING/' chroot.strace) <(sed 's/[^a-z]*//i;s/0x[0-9a-f]*/ADDR/g;s/13894/PID/g;/^read(/s/".*"/STRING/' chroot_lenny.strace) | less
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.
--
Good luck,
Feri.
Reply to: