bevan@ecr.mu.oz.au (Bevan Anderson) (04/24/91)
G'day all. Yes I have allready got a problem with Mini-x. I compiled the new kernel last night, and have a problem. GRAPHICS in fs/table.c is not defined anywhere, so comiling it bombs out. So what and where should it be defined? Also, should there be a new valye for NR_PROCS ? Compiling kernel/table.c bombs out due to multiply defined case statements or something like that. So should NR_PROCS be NR_PROCS + 1 ? (for the graphics) Thanks for you thoughts, Bevan. _______________________________________________________________________________ Bevan Anderson. Engineering bevan@ecr.mu.oz.au Melbourne Uni.
CRAWFORD_B%PLU.BITNET@cornellc.cit.cornell.edu (brian) (04/25/91)
I, too, am having problems with MINI-X. I received the nine shell archive files, transfered them to the Minix machine, put them in their own directory and tried the command sh <filename>. It started working just fine. All the directories were created that were needed and some of the files began to be unpacked. A few files got the length incorrect error (can't remember the exact wording) and then after doing kernel/makefile.new, the error message "Can't create pipe -- try again" came up. This was on the first of the nine files. I didn't try any others. I've looked at the shell archive file; the code after unpacking kernel/makefile.new follows the same format as the part that works--I don't see anything wrong. Can anyone help? What am I doing wrong? I'm running Minix 1.3 (is this a problem; does MINI-X only work with 1.5?) on a 486 25MHz compatible. There is plenty of hard disk space and there is plenty of ram disk space and there ought to be plenty of memory--there are no other process running other than the shell upon bootup, update, and the shell invoked to unpack the shell archive. Any help here would be greatly appreciated. Thanks, Brian Crawford CRAWFORD_B@PLU.BITNET
"Volker A. Brandt" <UNM409%DBNRHRZ1.BITNET@cunyvm.cuny.edu> (04/25/91)
Hello! brian <CRAWFORD_B%PLU.BITNET@CORNELLC.CIT.CORNELL.EDU> writes: >I, too, am having problems with MINI-X. I received the nine shell archive >files, transfered them to the Minix machine, put them in their own >directory and tried the command sh <filename>. It started working just >fine. All the directories were created that were needed and some of the >files began to be unpacked. A few files got the length incorrect error (can't >remember the exact wording) ... ... >Can anyone help? What am I doing wrong? You are not doing anything wrong. Your only problem is that you are on BITNET. The second I saw that Mini-X was distributed in un-encoded shar files, I threw it away and ftp'ed it from Cologne (ftp.tph.uni-koeln.de). The particular problem here was that long lines were split. It simply isn't possible to get un-encoded shar files through BITNET. What most Non-BITNETters don't understand is that there are two distinct file tyes in BITNET: Binary, and EBCDIC text. Binary is recognized throughout BITNET, which is why multi-megabyte gif pictures and .lzh files traverse the entire BITNET unscathed (so to speak :-). Mail from The Outside, on the other hand, is considered to be EBCDIC text (AFTER the incoming conversion, of course :-). EBCDIC text is broken up to contain no lines longer than 80 chars (are you listening, Dr. T. ?) so that you can read it on your terminal .... The preferred distribution means is tar -> compress -> uue. This works just fine. Another point for unsing tar: it preserves file attributes and the date/time info of the files, whereas sh just leaves the file the way it is when you unshar it ... Enough for now. ---------------------------------------------------------------------------- Bitnet: UNM409@DBNRHRZ1 Volker A. Brandt UUCP: ...!unido!DBNRHRZ1.bitnet!unm409 Angewandte Mathematik ARPAnet: UNM409%DBNRHRZ1.BITNET@CUNYVM.CUNY.EDU (Bonn, Germany)
lft@cmn14.Stanford.EDU (Alfred Leung) (05/02/91)
In article <7432@munnari.oz.au> bevan@ecr.mu.oz.au (Bevan Anderson) writes: >G'day all. > >Yes I have allready got a problem with Mini-x. > >I compiled the new kernel last night, and have a problem. > >GRAPHICS in fs/table.c is not defined anywhere, so comiling >it bombs out. >So what and where should it be defined? >Also, should there be a new valye for NR_PROCS ? >Compiling kernel/table.c bombs out due to multiply defined case >statements or something like that. >So should NR_PROCS be NR_PROCS + 1 ? (for the graphics) I had the same problems. What I did was: in /usr/include/minix/com.h, I defined GRAPHICS as -8 in /usr/include/minix/const.h, I defined NR_TASKS as 10 (was 9, 15 for Amoebas?). These are the two definitions that I know of to be changed for the added graphic task. Anyone got another fix? -- -------------------------- Alfred Leung, grad student, Stanford U n i v gaia@portia.stanford.edu | H H | H H H H | H | . H | . lft@ccrma.stanford.edu | | | | | | | | | | | | . . __________________________|----------------- -- - - - - .