Hi everybody,
in revision 125 of buildrom an optional delay before the LAB environment kexecs the on-disk kernel has been introduced. For me this does not work. There is neither a delay nor can I enter the busybox environment by pressing return. After showing the delay-press-key-message, the on-disk kernel is booted immediately. I use a 64 bit kernel in LAB. (The default one with amd64 configuration.) What can go wrong?
Regards,
Andi
Hi Andi,
On Sat, Mar 29, 2008 at 06:45:19PM +0100, Andreas B. Mundt wrote:
in revision 125 of buildrom an optional delay before the LAB environment kexecs the on-disk kernel has been introduced. For me this does not work. There is neither a delay nor can I enter the busybox environment by pressing return. After showing the delay-press-key-message, the on-disk kernel is booted immediately. I use a 64 bit kernel in LAB. (The default one with amd64 configuration.) What can go wrong?
Most likely you're missing
CONFIG_ASH_READ_TIMEOUT=y
in your busybox config. It's necessary to make the '-t' flag work for the 'read' command. If you don't have CONFIG_ASH_READ_TIMEOUT set, 'read -t' will fail with an error message, which seems to match the failure mode you describe.
Thanks, Ward.
On Sat, Mar 29, 2008 at 01:59:11PM -0400, Ward Vandewege wrote:
Most likely you're missing
CONFIG_ASH_READ_TIMEOUT=y
in your busybox config. It's necessary to make the '-t' flag work for the 'read' command. If you don't have CONFIG_ASH_READ_TIMEOUT set, 'read -t' will fail with an error message, which seems to match the failure mode you describe.
Hi Ward,
thanks for your hint, but a search for CONFIG_ASH_READ_TIMEOUT gives:
...buildrom-devel$ egrep -r CONFIG_ASH_READ_TIMEOUT * deploy/config/busybox/.config:CONFIG_ASH_READ_TIMEOUT=y packages/busybox/conf/.svn/text-base/defconfig.svn-base:CONFIG_ASH_READ_TIMEOUT=y packages/busybox/conf/.svn/text-base/defconfig-serengeti_cheetah-x86_64.svn-base:CONFIG_ASH_READ_TIMEOUT=y packages/busybox/conf/defconfig-serengeti_cheetah-x86_64:CONFIG_ASH_READ_TIMEOUT=y packages/busybox/conf/defconfig:CONFIG_ASH_READ_TIMEOUT=y work/busybox/busybox-1.1.3/.config:CONFIG_ASH_READ_TIMEOUT=y work/busybox/busybox-1.1.3/include/bb_config.h:#define CONFIG_ASH_READ_TIMEOUT 1 work/busybox/busybox-1.1.3/include/config/config/ash/read/timeout.h:#define CONFIG_ASH_READ_TIMEOUT 1 work/busybox/busybox-1.1.3/shell/ash.c:#if defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/ash.c:#if defined(CONFIG_ASH_READ_NCHARS) && defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/ash.c:#elif defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/ash.c:#if defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/ash.c:#if defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/Config.in:config CONFIG_ASH_READ_TIMEOUT work/busybox/busybox-1.1.3/.config.old:CONFIG_ASH_READ_TIMEOUT=y work/busybox/logs/build.log: Enable 'read -t S' support. (CONFIG_ASH_READ_TIMEOUT) [Y/n/?] y ....
so this seems not to be the reason.
Regards,
Andi
Hi Andi,
On Sat, Mar 29, 2008 at 07:15:35PM +0100, Andreas B. Mundt wrote:
thanks for your hint, but a search for CONFIG_ASH_READ_TIMEOUT gives:
...buildrom-devel$ egrep -r CONFIG_ASH_READ_TIMEOUT * deploy/config/busybox/.config:CONFIG_ASH_READ_TIMEOUT=y packages/busybox/conf/.svn/text-base/defconfig.svn-base:CONFIG_ASH_READ_TIMEOUT=y packages/busybox/conf/.svn/text-base/defconfig-serengeti_cheetah-x86_64.svn-base:CONFIG_ASH_READ_TIMEOUT=y packages/busybox/conf/defconfig-serengeti_cheetah-x86_64:CONFIG_ASH_READ_TIMEOUT=y packages/busybox/conf/defconfig:CONFIG_ASH_READ_TIMEOUT=y work/busybox/busybox-1.1.3/.config:CONFIG_ASH_READ_TIMEOUT=y work/busybox/busybox-1.1.3/include/bb_config.h:#define CONFIG_ASH_READ_TIMEOUT 1 work/busybox/busybox-1.1.3/include/config/config/ash/read/timeout.h:#define CONFIG_ASH_READ_TIMEOUT 1 work/busybox/busybox-1.1.3/shell/ash.c:#if defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/ash.c:#if defined(CONFIG_ASH_READ_NCHARS) && defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/ash.c:#elif defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/ash.c:#if defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/ash.c:#if defined(CONFIG_ASH_READ_TIMEOUT) work/busybox/busybox-1.1.3/shell/Config.in:config CONFIG_ASH_READ_TIMEOUT work/busybox/busybox-1.1.3/.config.old:CONFIG_ASH_READ_TIMEOUT=y work/busybox/logs/build.log: Enable 'read -t S' support. (CONFIG_ASH_READ_TIMEOUT) [Y/n/?] y ....
so this seems not to be the reason.
Hmm, ok. Can you debug the lab environment? You could try to chroot into it on your build system, or else just comment out the kexec line and start a busybox shell instead on your target. You should then see what error 'read' is throwing.
Thanks, Ward.
Hi Ward,
On Sat, Mar 29, 2008 at 06:09:27PM -0400, Ward Vandewege wrote:
Hi Andi,
On Sat, Mar 29, 2008 at 07:15:35PM +0100, Andreas B. Mundt wrote:
thanks for your hint, but a search for CONFIG_ASH_READ_TIMEOUT gives:
...buildrom-devel$ egrep -r CONFIG_ASH_READ_TIMEOUT * deploy/config/busybox/.config:CONFIG_ASH_READ_TIMEOUT=y
...........
support. (CONFIG_ASH_READ_TIMEOUT) [Y/n/?] y ....
so this seems not to be the reason.
Hmm, ok. Can you debug the lab environment? You could try to chroot into it on your build system, or else just comment out the kexec line and start a busybox shell instead on your target. You should then see what error 'read' is throwing.
I stopped in LAB and got just:
# read -t 5 ash: read: arg count
the same as if I just type:
# read ash: read: arg count
The weird thing is, that even the debian lenny busybox gives the same on my box (2.6.24-1-amd64):
andi@flashgordon:~$ busybox ash
BusyBox v1.1.3 (Debian 1:1.1.3-5) Built-in shell (ash) Enter 'help' for a list of built-in commands.
~ $ read -t 5 ash: read: arg count ~ $ read ash: read: arg count ~ $ exit
from the source of busybox in debian I checked that CONFIG_ASH_READ_TIMEOUT=y is enabled there as well.
Only bash works fine:
andi@flashgordon:~$ read -t 5 hello andi@flashgordon:~$ echo $REPLY hello
So for the time being I'm stuck, and I guess the weather is to good to explore that further now...
Thanks,
Andi
-
Andreas B. Mundt -
Ward Vandewege