Hi, I don't know what is causing your problems - the procedure worked for me, although I probably havn't tried it in the last 2 years or so. One way round it might be to dump the kernel/ramdisk file to a disk using some other system, then use 147bug to read the disk in to memory and 'go' it.
Richard On Mon, Aug 12, 2002 at 10:56:23PM +0200, Kars de Jong wrote: > Hello everyone, > > At work I found an old Motorola Delta crate gathering dust. On closer > inspection it contained an MVME147SA-1 SBC, an MVME332XT serial wossname and > a cradle with 3 SCSI devices: a 150 MB CDC-III (wow!), an Archive 150 MB QIC > tape drive and a huge 5 1/4 inch full height Micropolis drive which refused > to spin up completely and just went 'clunk, clunk' softly followed by spin > down and then it starts all over again. Awwww. > > Powered it up, found out the battery and thus NVRAM was dead. Looked up some > stuff on the web and got a replacement for the Timekeeper. After installing > this and reinitialising everything I could boot into the Motorola SYSV/68 > SVR3.2 OS which was sitting on the CDC-III. That looked pretty bad. None of > my favourite commands installed, plus major Y2K problems :p > > Time to try and run Debian on the beast. Got the MVME147 specific > installation notes from Richard Hirst on > http://www.sleepie.demon.co.uk/linuxvme/mvme147-potato.txt and started > working through them. > > It all worked up until actually trying to download the kernel-ramdisk combo > with sboot. It starts to download fine, but after a while it just stops > transferring and aborts after some retries on timeout. I never seem to get > much further than a few hundred KB. The 'other side' is running RedHat 7.2. I > have succesfully downloaded the kernel-ramdisk image with a TFTP client on > the SYSV/68 OS. I tried using several different versions of the TFTP server > but to no avail. The strange thing is, when using Ethereal on the same RedHat > 7.2 box, I didn't see the TFTP retransmissions 'on the wire', however, when > attaching to the TFTP server process with strace I did see a 'send()' call > which seemed to succeed (it returned '516' which I think is a full TFTP data > packet). > > After this I tried booting OpenBSD 3.1. It had similar problems trying to > download a kernel+ramdisk with its sboot program, but creating a diskless > setup (using bootparamd and NFS) and using its secondary netboot loader did > work (netboot is quite small and is in that case the only program downloaded > with TFTP, the rest is done through NFS). > > So, I got OpenBSD to work, but I prefer to be able to run Linux (diskless or > not). Does anyone have any clue as to what is going wrong? > > Any help would be apreciated. > > Kind regards, > > Kars. > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
