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)?
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)?