Thanks again Tim.
I enabled UART for bootcode.ini (https://www.raspberrypi.com/documentati ... art-enable)
and for 2ndstage (https://www.raspberrypi.com/documentati ... art-enable) and was able to see the Kernel command line included the watchdog option (watchdog.open_timeout=15).
My observation is that this watchdog functionality isn't going to suit my use case. For one thing - as you said in your last post - it seems that initramfs is inheriting the watchdog and keeping the OS alive. But the main reason it won't suit me is that all of these settings are in the 'tryboot' OS, and I'm looking for a failsafe return to the old OS should the tryboot OS not come up as expected. If the tryboot OS needs to have custom parameters set in config.txt and possibly a custom initramfs, then I'm left back where I started - with the strong likeliehood that a basic error in these settings (or others) in the tryboot OS could leave the system hanging at initramfs, waiting for user input. It's a sort of catch-22.
I scanned through the kernel documentation for something that could be added to the kernel command line, e.g. to set a timeout on the initramfs prompt, or to automatically reboot instead of waiting for user input, but my search came up blank.
It's been an interesting challenge, and I've learned a lot in the process which is the whole point, for me, but I'm going to drop this line of investigation here.
I enabled UART for bootcode.ini (https://www.raspberrypi.com/documentati ... art-enable)
and for 2ndstage (https://www.raspberrypi.com/documentati ... art-enable) and was able to see the Kernel command line included the watchdog option (watchdog.open_timeout=15).
My observation is that this watchdog functionality isn't going to suit my use case. For one thing - as you said in your last post - it seems that initramfs is inheriting the watchdog and keeping the OS alive. But the main reason it won't suit me is that all of these settings are in the 'tryboot' OS, and I'm looking for a failsafe return to the old OS should the tryboot OS not come up as expected. If the tryboot OS needs to have custom parameters set in config.txt and possibly a custom initramfs, then I'm left back where I started - with the strong likeliehood that a basic error in these settings (or others) in the tryboot OS could leave the system hanging at initramfs, waiting for user input. It's a sort of catch-22.
I scanned through the kernel documentation for something that could be added to the kernel command line, e.g. to set a timeout on the initramfs prompt, or to automatically reboot instead of waiting for user input, but my search came up blank.
It's been an interesting challenge, and I've learned a lot in the process which is the whole point, for me, but I'm going to drop this line of investigation here.
Statistics: Posted by bcb2k — Sat Oct 25, 2025 1:59 am