First, sorry about the delay ... holiday season has me going too many directions at once. Replies, by #:
#17: This all started with a fully functional system that has dropbear installed. When the monitor was disconnected (as opposed to powered off) it was no longer a functional system.
#18: There are at least two times during the TC Linux boot (AFTER BIOS) that the screen is cleared before more data is written. I suspect that the hang may be occurring at one of those points.
#19: When there is a monitor attached, TC booted from a CDROM will at least start its network using DHCP and respond to pings at the address it was given. With no monitor attached, it never requests an address from the DHCP server and therefore, cannot respond to network traffic. Ergo, I call it hung. It will also not respond to a keyboard or mouse once a monitor IS connected, even if they were present at boot. Again, I call that hung.
#20: OK, I figured out how to activate a serial console using a standard CDROM distro. Using the minimal Core image, at the boot: prompt I'm entering 'mc console=tty0 console=ttyS0' (without the quotes) and I capture the following output from a boot with a monitor attached:
Booting Core 5.1
Running Linux Kernel 3.8.13-tinycore.
Checking boot options... Done.
Starting udev daemon for hotplug support... Done.
Scanning hard disk partitions to create /etc/fstab
Setting Language to C Done.
Possible swap partition(s) enabled.
Loading extensions... Done.
Setting keymap to us Done.
Setting hostname to box Done.
login[342]: root login on 'tty1'
Booting without a monitor attached produces *NO OUTPUT* on the serial line. I tried typing the command line blind as well as disconnecting the monitor between typing the command line and pressing ENTER to activate it. In both cases, the CDROM spins up like it is loading, then nothing.
re "All we have is a bug report lacking any evidence and without anyone else being able to reproduce.": Unless someone has taken the time and effort to obtain the same Acrosser AR-ES0631 hardware, then no one has actually tried to reproduce the problem. It doesn't exist on anything else I've tried, but neither does it exist on our hardware with any other operating system I've tried. Since the beginning, I've tried to be clear that this TC problem is only manifesting on one hardware platform that I know of. Unfortunately, it is the one that my boss already bought 20 of and I *MUST* use it. For now, we just labeld the dummy VGA connectors we were forced to build to work around this TC bug as "TinyCore Linux Bug Prevention Dongle" and are proceeding from there.
Yes, of course my idea that a known (but rare) bug might become less rare in the future is speculative. Since it exists in TC at least back to the early 3.x releases and is still present (but is NOT in any other linux I've tried) I'm comfortable assuming that TC will carry it until it is fixed. If any other hardware starts working like the Acrosser AR-ES0631 hardware that we are using, it will appear again.
For now, I guess I give up. I don't want to keep bothering (and likely annoying) the good people here who are honestly trying to help. As a software developer, I understand the urge to dismiss/ignore bugs one cannot duplicate, because being able to duplicate them means that one may use many tools to make the debugging easier. Unfortunately, that is rarely an option for me and I must still go into the code -- without a debugger! -- to find the causes for things I cannot duplicate. Since this is a free product, I obviously cannot ask for that level of dedication and work. If no one cares about bugs they cannot duplicate, then they will remain and that's just the way it is.
Thanks for listening and for all of the suggestions.
EDIT: My boss just told me that I can offer to send someone one of the Acrosser boxes we're using in order to duplicate, debug and hopefully resolve this issue. Assuming, of course, that anyone is interested. You can contact me at svalli at e-visions dot com.