Subject: Clue-Gap

From: Dan Pinkard <[email-masked]>
Date: Mon, 20 Jul 1998 00:31:11 -0500 (CDT)

Either a lack of indy-clue, irix-clue, or possibly even linux-clue has
made the install process slow goings for me. If you can tell me where I
went wrong, or what I'm missing, I'll thank you. 

I'm booting with 
boot bootp():/tftplinux/vmlinux 

which sucessfully pulls the kernel and boots. The tftpboot directory has
been populated with the hardhat tarball and will actually get me into the
installer. I have also gotten it to work by copying vmlinux to the root
irix partition and booting from dhcp in the kernel. It needs nfsroot= but
works fine.

In either case, once I'm in, it cannot get past the fdisk screen. After
choosing done on fdisk it immediately dumps the kernel info and I'm left
with a very unresponsive machine.

I'm thinking that it is likely due to a poorly partitioned drive... Using
dsk0d4s1 and dsk0d4s7 as linux partitions I first used the old redhat 5.0
installer for the irix mke2fs and fscke2fs and remade dsk0d4s7. I
decided to follow through and let the installer dump the cpio image into
dsk0d4s7. After several reboots I realized it would get farter running
boot vlinux.2.1.99 root=/dev/sdc2 than anything else, but it, too, froze,
asking for some init level. I assume it only needs to be passed as a boot
param, so I moved on. (The goal was to verify the name of the partition,
not to boot into the old installer)

Again, the hardhat installer did not make it past the fdisk screen. 

Next I rebooted and used the hardhat installer to refdisk it all myself.
Quite nice.. worked fine, but it didn't make it beyond the fdisk screen.

At any rate, What can I salvage of this situation? Where did I most likely
go wrong, and what can I/we do to better answer this question for next
time?

Thanks... d.p.

---

From: "James V. Hendricks" <[email-masked]>
Date: Mon, 20 Jul 1998 11:16:58 -0600 (MDT)

What is the kernel error message you are getting?  I was having problems
getting a second disk to work as sdb1 -- it seems to give a page fault (or
something like that) and about 10 lines of hex dump with an "Aiyee, Kernel
Panic" or some other funny message like that.  When I only use one of the
drives it works fine.  And I can use /dev/sdb2.
  Once I start getting X up I'll try to figure out my disks problems a
little more...  Right now, running 'X' gives the message
 execve failed for /etc/X11/X (errno 8)
I tried copying over Xsgi from another indy but I got the same error
message.  Any suggestions/any documentation?

---

From: Ulf Carlsson <[email-masked]>
Date: Mon, 20 Jul 1998 20:40:59 +0200 (CEST)

Hi,

Ralf has done some changes in the kernel tree for the egcs compiler (as
far as I understand it). So, here's a fix for the crosscompiler, a
modified specs file (/usr/local/lib/gcc-lib/mips-linux/2.7.2.2/specs).

Thank Ralf, not me - he told me what to change.

- Ulf

---

From: [email-masked]
Date: Tue, 21 Jul 1998 01:41:18 +0200

> Thank Ralf, not me - he told me what to change.

Ok, now that Ulf already posted the patch to the spec file, let me explain
the problem.  The usual C compilers for MIPS systems define a C preprocessor
macro based on the language of the input file.  These macros have names
like LANGUAGE_C or LANGUAGE_ASSEMBLER.  Usually several variations are
being defined with no, one or two heading underscores, sometimes even
trailing underscores.  The Linux/MIPS compiler handled this different.
As the result the definitions which were expected by the kernel headers,
were not available.

While it would have been easy to fix the kernel to compile with either
gcc 2.7.2 or egcs I don't intend it makes much sense to carry this historic
garbage with us.  So I just fixed it to compile with egcs.

Now brewing crosscompilers has historically proven to be a tough problem
for many user, so the hacked Spec file posted by Ulf can take away this
pain for crosscompiler users.

  Ralf