segmentation fault while downloading preseed file

Casper.log displaying wget aborting with a failed assertion:
__getpagesize: Assertion `_rtld_global_ro._dl_pagesize != 0' failed.

Mathieu,

Are you seeing this on x86 installs?

Ameet,

I confirm, this is reproducible on i386.

Do you get the same error in casper.log on i386? I can't reproduce this in an isolated test case, but I have not tried NFS-booting, only running wget by hand.

Colin, the casper.log attachment is a log for i386. There is no Segmentation fault, but there is an assertion error. Same goes for amd64 after I tried it again, I would still get assertion errors rather than a segfault.

I've also tried to reproduce it by running wget by hand, with no luck.

Trying again today to get a clearer view of what's going on.

Further testing shows it crashes with a segfault on amd64, and an assertion error on i386. I could not find a core file to investigate.

Just tried a custom initrd.lz image; after applying the suggested workaround for bug 602273, further modifying the initrd to call wget directly and dropping preseed file in /root/tmp rather than going through 'chroot /root', the file is properly downloaded, preseed is valid and the install continues.

Is this REALLY a problem in wget?

Good point, I also feel it might not be. The way I initially thought of it was that there might be something different in the environment with which wget in chroot is being run, as opposed to how busybox's wget is being run -- something like a library that is not available yet, etc.

After talking with Mathieu, this issue is affecting a number of systems in the lab. There is a workaround in place, but it would be beneficial for test if this issue was resolved.

I had a nasty thought.

This can't possibly be a bug in wget, because busybox chroot behaves as follows:

  $ sudo busybox sh

  BusyBox v1.15.3 (Ubuntu 1:1.15.3-1ubuntu4) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  /home/cjwatson # chroot / rm --help
  BusyBox v1.15.3 (Ubuntu 1:1.15.3-1ubuntu4) multi-call binary

  Usage: rm [OPTIONS] FILE...

  Remove (unlink) the FILE(s). Use '--' to
  indicate that all following arguments are non-options.

  Options:
          -i Always prompt before removing
          -f Never prompt
          -r,-R Remove directories recursively

In other words, busybox invokes its own applets when chrooting, so it isn't running the real wget in /root, it's running its own wget from busybox-static, unexpectedly.

This all seems like a very bad idea, and I think busybox should always exec real programs when chrooting rather than trying to use applets. Could you please test the new busybox-initramfs in https://launchpad.net/~cjwatson/+archive/ppa (currently building)?

busybox-initramfs is built in my PPA and ready for testing.

Replacing /bin/sh with the busybox binary in that package does indeed fix the issue.

This bug was fixed in the package busybox - 1:1.15.3-1ubuntu5

---------------
busybox (1:1.15.3-1ubuntu5) maverick; urgency=low

  * applets-fallback.patch: Never execute busybox applets when chrooting
    (LP: #594162).
 -- Colin Watson <email address hidden> Mon, 04 Oct 2010 16:06:06 +0100