"funny" ASUS P5A-B-AT motherboard
dugan at passwall.com
Fri Aug 4 15:56:58 PDT 2000
On Fri, 4 Aug 2000, Bob Blick wrote:
> Running loadlin like this:
> loadlin vmlinuz mem=96M root=/dev/hdc5 ro
> Gave me 96 megs of ram. I thought I'd tried this combination before but
> maybe position in the line is important, but this works. Thanks!
OK, then *that* part is solved...
> Still no luck with lilo. But every time I run lilo I would get a report
> like this:
> /dev/hdb reports 0 bytes and 10000000 bytes (or something like that)
> That line and another one would repeat a few times before the usual:
> added linux *
> added dos
> The message was about the ATAPI Zip drive and that seemed strange because
> neither /etc/fstab or /etc/mtab have reference to the zip drive, so I am
> assuming lilo tries to map my drives.
> I disconnected the zip drive and tried again, this time lilo just gave me:
> added linux *
> added dos
I dont know about this. Your report of this is the first I have heard of
this. I am not dis-believing you, just saying I dont have much direction
to offer in fixing that. If I had it in front of me, I might be able to do
some more research, but your best bet is finding someone else that has
found this problem, diagnosed it, and fixed it.
> However I still get stuck at LI at boot. "linear" was in lilo.conf, but
> removing it(this was something I'd tried before) didn't cure it. Here's my
> lilo.conf currently:
> Changing boot=/dev/hda to boot=/hda1 didn't make lilo work any better, but
> made removing lilo a little harder, since running MSDOS fdisk /mbr would no
> longer replace it, I had to run the MSDOS sys command also. Lilo is
> definitely writing to the disk in all the right places :-)
> I am wondering about "image=/boot/vmlinuz-2.2.14-5.0". Is lilo getting
> confused where /boot is located, and somehow thinks it's on hda? Just a
I believe that boot=/dev/hda specifies where to update the MBR. As long as
your MBR (LILO) is there, you should be able to tell it to boot from
hda,b,c or d assuming you have support with these devices for booting and
you have the proper referenc ein the /etc/lilo/conf .
My gut feeling is that lilo uses the image entry and the root
specification with that image to locate the place on disk with the kernel.
Another thing pointed out by: Mitchell Patenaude <mrp at sonic.net>
(Quoting his reply here)
>Last time I saw this, it was because of the old cylinder>1024 bug.
>(All files needed for boot, i.e. the kernel and the system map, have
>to reside on the disk below cylinder 1024 because of a limitation with
>the boot/BIOS spec.)
>I redid the drive so that entire root partition was below that cylinder,
>and then the problem went away.
>I used partition magic to shuffle the partitions around, and it worked
>like a champ.
I forgot about this until he mentioned it. (The wonders of having many
skilled professionals working together bring us to solutions. :-)
This is a something I have worked with before too. It may not be a problem
now, but it was before, and is worthy of examination. (Your lilo man page
may tell you if this is still a problem.) Look at your partitions. Since
you have root on /dev/hdc5, this suggestest an extended partition, and
people often place their first partitions near the start of the cyl count,
and the larger the partition number, the farther our in cyls the count may
extend. If we assume you follow the common procedure for partitions and
cyl locations, then /dev/hdc5 might be beyond the 1024 cyl mark specified
in Mitchell Patenaude <mrp at sonic.net> 's e-mail message.
Could you also run fdisk /dev/hdc and then "p"rint the partitions, and
paste that into an e-mail to the list? (If you have not used fdisk from
the command line, then here is an example of what you could do:
# fdisk /dev/hdc
(press "p" and then return to print the partition information)
(press "q" and then return to quit fdisk)
(Nothing should be changed on your disk if only p and then q are used in
This 5 in /dev/hdb5 being so high is the only thing in your /etc/lilo.conf
that stands out to me right now.
I know it may not be helpful for you now, but the general scheme I use for
partitioning a single disk workstation is:
/dev/sdX1 (or /dev/hdX1) is root=/
/dev/sdX2 (or /dev/hdX2) is /usr
/dev/sdX3 (or /dev/hdX3) is swap
then use the rest for extended partitions as needed with /usr/local /var
/var/log and /tmp
(Where "x" is a,b,c,d... etc. )
This has the advantage of keeping your root withing the first 1000 cyl
(most of the time) and puts swap close to the middle of your disk. If we
could assume that the center of your cyl count was the center of your
disk, the seek time for going into virt memory/swap might be minimized as
it is close to the middle of this disk in any sweep. However, this is not
always true of all drive manufacturers, or when using gemotery translation
Also, it gives your root, swap and /usr in non-extended partitions. If for
some reason the extended partition information gets blow away, the most
important (IMHO) parts "swap", "/" and "/usr" have most of the common
utitlities for ressurecting your system. (Of course, if your MBR, and
partition info gets clobbered, then this does little to help.)
When running a server, I would put swap on a separate disk, or maybe even
a separate SCSI bus with its own disk depending upon how much swap was
used, and for what operations.
Busy trees would also want their own bus, and maybe some level of
hardware RAID for fault tolerance or speed.
(I was assuming you are setting up a workstation, not a server.)
Even if you don't need this last part, someone else might find it useful
for more than confetti. :-)
More information about the talk