peterc@softway.sw.oz.au (Peter Chubb) (02/11/91)
I obtained Amiga Minix last week from Prentice-Hall in Australia. After fixing minor problems with the boot disc (the copy of minix.img had a bad sector, so I used minix.img.bu), I wanted to create some file systems. I used messyfmt from the MSH1.30 product to format 720K 9 sector discs for MS-DOS, then rebooted with minix. mkfs /dev/dd1 720 seemed to access drive 1, then complained that it couldn't access sector 719. I tried another disc, and this time mkfs dumped core. I looked at the mkfs binary, and it was truncated to around 11k. Restored a much larger mkfs from the backup, then tried again -- similar behaviour. OK, thought I, I'll recompiled mkfs, and put some instrumentation in to see what's going on. Needed a new empty filesystem to do this, of course -- rebooted Amigados, used diskcopy and msh to copy one of the source disks, rebooted minix, mounted the copy, rm -r *, then go through the palaver necessary to extract the mkfs source from the archive, and start compiling. No go. Syntax errors galore. Turns out that NAME_MAX is only defined if _POSIX_SOURCE is defined. Try again., with _POSIX_SOURCE defined. This time, the compiled complains about a perfectly innocent sizeof (*sup) on or near line 290. Replaced this with sizeof (struct super_block) (or whatever -- can't remember exactly here), and all compiled cleanly, to exhibit the same behaviour as the original binary. Also, there are several things commented out with #if (MACHINE == ATARI) that I think perhaps should include AMIGA, etc, too. Can anyone help me? Is there something wrong with the floppy device, or something? Has mkfs never been compiled on an Amiga? Yours in anticipation, - Peter Chubb Softway Pty Ltd, P.O. Box 305, Strawberry Hills, NSW 2012, AUSTRALIA Phone: +61 2 698 2322; Fax: +61 2 699 9174; Telex: AA27987 Internet: peterc@softway.oz.au UUCP: ...!uunet!softway.oz!peterc
sreiz@cs.vu.nl (Steven Reiz) (02/12/91)
peterc@softway.sw.oz.au (Peter Chubb) writes: > mkfs /dev/dd1 720 > seemed to access drive 1, then complained that it couldn't access > sector 719. It seems that you might benefit from the latest version of amiga minix, which fixes some bugs in the floppy task. You can ftp it from ftp.cs.vu.nl [130.37.24.6], directory /pub/sreiz/minix. Please give it a try, it has helped other people who had similar problems. > OK, thought I, I'll recompiled mkfs, and put some instrumentation in > to see what's going on. Needed a new empty filesystem to do this, of >[...] > archive, and start compiling. No go. Syntax errors galore. Did you use the original Makefile? > Also, there are several things commented out with > #if (MACHINE == ATARI) > that I think perhaps should include AMIGA, etc, too. You're right, it should probably be #if (ENDIANITY == BIG) or something like that. > Can anyone help me? Is there something wrong with the floppy device, > or something? Has mkfs never been compiled on an Amiga? I hope so. Probably, yes. No, it hasn't. All the commands have been compiled on an Atari ST running minix 1.5, with the original atari minix makefiles. That should not be the problem, though. Regards, Steven Reiz
tsarna@polar.bowdoin.edu (Tyler Sarna) (02/13/91)
In comp.os.minix, Steven Reiz <sreiz%CS.VU.NL@VM1.NoDak.EDU> writes: > It seems that you might benefit from the latest version of amiga minix, > which fixes some bugs in the floppy task. You can ftp it from > ftp.cs.vu.nl [130.37.24.6], directory /pub/sreiz/minix. > Please give it a try, it has helped other people who had similar problems. Could you make diffs/sources for the floppy driver changes ONLY availible? I would really like to have reliable floppy access, but because there are no sources included with latest_aminix.lzh and because of either 020/hard disk icomptatibility with my system, I can't use the supplied minix.img. I realize the hard disk driver is still in beta, but the floppy changes are "done", right? At the very least, floppy reliability can't get any WORSE than it is now [1/2 :-)] ------///------------------------------------------------------------ /// Tyler "Ty" Sarna E-Mail: tsarna@polar.bowdoin.edu \\\/// "So you see, the overhead gets underfoot..." --\XX/---------------------------------------------------------------
sreiz@cs.vu.nl (Steven Reiz) (02/13/91)
tsarna@polar.bowdoin.edu (Tyler Sarna) writes: >Could you make diffs/sources for the floppy driver changes ONLY >availible? I would really like to have reliable floppy access, >but because there are no sources included with latest_aminix.lzh >and because of either 020/hard disk icomptatibility with my >system, I can't use the supplied minix.img. I realize the hard Good point, other people have complained about it as well. We will try to produce YANAMV (yet another new amiga minix version) ASAP, which will let you boot minix, even if it doesn't work with your harddisk. I think that that's better than having two versions, one with the harddisk task, and one without. >disk driver is still in beta, but the floppy changes are "done", >right? At the very least, floppy reliability can't get any WORSE >than it is now [1/2 :-)] I sure hope so! We will produce the source/diffs for our changes as well, as soon as we're satisfied with them. Regards, Steven Reiz
tsarna@polar.bowdoin.edu (Tyler Sarna) (02/14/91)
In comp.os.minix, Steven Reiz <sreiz%CS.VU.NL@VM1.NoDak.EDU> writes: > tsarna@polar.bowdoin.edu (Tyler Sarna) writes: > >Could you make diffs/sources for the floppy driver changes ONLY > >availible? I would really like to have reliable floppy access, > >but because there are no sources included with latest_aminix.lzh > >and because of either 020/hard disk icomptatibility with my > >system, I can't use the supplied minix.img. I realize the hard > > Good point, other people have complained about it as well. We will > try to produce YANAMV (yet another new amiga minix version) ASAP, > which will let you boot minix, even if it doesn't work with your > harddisk. I think that that's better than having two versions, one > with the harddisk task, and one without. Great. Did you include Andy Michael's amiga q&d mpx.s patch for 010/020 compatibility? Also, the hard disk task should look for the first Commodore *HARD DISK CONTROLLER* board, not just the first C= board, since anyone with a C= A2620 like myself will probably get bashed because the wini task will think it's found the hard disk. You can check a board type field as well as the manufacturer field in the autoconfig list to accomplish this. Keep up the good work! ------///------------------------------------------------------------ /// Tyler "Ty" Sarna E-Mail: tsarna@polar.bowdoin.edu \\\/// "So you see, the overhead gets underfoot..." --\XX/---------------------------------------------------------------