[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new Etch install fails to boot [SOLVED]



This problem has been solved, as least in a practical sense.

Repeated tries to install Etch had resulted in the boot failing as soon as
grub was called.  Attempts to build a system with lilo also failed.  The
motherboard (Abit BX133 440BX) has four IDE connectors, allowing 8 drives in
total.  My hard drives were on IDE3 and correctly seen as hde and hdf.  The
only other device was the CD drive (hdc on IDE2).  With a rescue boot from
the CD, I did verify that grub was referenced in the first two 512-byte
blocks of hde, and that the MBR of hdf had not been written by mistake.  So
that was not the problem.

Next I tried disconnecting the spare hard drive (hdf) and doing a fresh
install including disk formatting.  That still crashed.

Finally, I switched both hard drives to IDE1 (hda and hdb) and succeeded in
doing a full install.  The system is running fine now.  Supposedly IDE3 and
IDE4 run at 66 MB/s max, while IDE1 and IDE2 go at 33 MB/s max.  But where
this machine's going that won't matter.

I did notice something odd that may help to understand the cause of the
failures.  With the drives on IDE1 (the successful configuration), the drives
showed as follows during the install:

  IDE1 master (hda) - 41.2 GB IC35L040AVER07-0
  IDE1 slave (hdb) - 41.2 GB IC35L040AVER07-0

With the drives on IDE3 (the unsuccessful configuration), they showed as
follows:

  IDE5 master (hde) - 41.2 GB IC35L040AVER07-0
  IDE5 slave (hdf) - 41.2 GB IC35L040AVER07-0

Although there can be eight devices (hda-hdh), there are only four IDE
connectors.  If hda and hdb are both seen as IDE1, then hde and hdf should be
seen as IDE3, not IDE5.

There was one unrelated issue too.  When the system booted, the serial mouse
didn't work in X.  In /etc/X11/xorg.conf, I changed the mouse device from
/dev/input/mice to /dev/ttyS0, and changed the mouse protocol from ImPS/2 to
Microsoft.  Neither change alone was sufficient.  I don't know if this was
the proper way to go, but it seems to have worked.  I made the changes by
imitating the XF86Config file from the machine's Red Hat days.



Reply to: