Tested this - when running the bootstrap from floppy as GEM program (calling it as bootstrap.prg), the system reboots spontaneously (and will run through a memtest after that, so it's really rather like a cold boot). Changing the name of the bootstrap to bootstrap.tos succeeds ib booting the kernel.So it should be named bootstrap.tos or should that just be documented?
I guess it should just be renamed - you don't usually care whether the bootstrap runs as GEM or TOS app (the screen output is cleaner in the TOS one anyway).
One thing that struck me as odd: the decompression of the kernel image went a hell of a lot faster when run as GEM program. The kernel should be loaded to ST-RAm (-s flag) but it looked as though it wasn't. What details does the bug report give? Kernel hang, or reboot? The kernel hang was quite a common thing for me with Debian kernels due to the botched keyboard init. If the bug reporter has old hardware extensions that hang off the ACIAs, and reports a hang it may well be that my latest patch to linux-m68k will fix that symptom.300730 is a hang, sounds like we can probably close it.
We should close it with the next kernel upload... with any luck, I'll have the SMC91C111 driver working by then (it did finally own up to detecting the proper hardware, instead of stuffing up the ROM-port card or just hanging the kernel).
(Apologies if I seem unresponsive at this time - the mail system at my old lab is migrated to postfix by a new admin, and that often results in no mail going out for a few days ...)Bummer. Maybe when he's done we can get q650's mail working again. Running a buildd with email is a total drag.
I guess I'll let him fix outgoing relay for the whole domain first, before adding something like incoming relay :-)
I'll play with postfix some on my UUCP relay so I'll have a config snip ready when the time comes.
Any news on the buildd front? Michael