On Aug 23, 2006, at 2:43 PM, Brandon Peirce wrote:
Dan Nicholson wrote:
On 8/22/06, Colin Kemp <[EMAIL PROTECTED]> wrote:
When I built my LFS system, i got the GRUB error 18 message at stage
1.5. i looked this up and saw something about my disk was beyond the
scope of the BIOS or something (the meaning of error 18). First, can
i have a clarification of my problem and second, a way to fix it? my
disk has
- hda1 as my LFS system
- hda2 as a Windows partition
- hda3 as a swap
- hda4 as unused, ext3 formatted space
each partition is 60GB, excepting the swap which is about 16GB
Setup looks sane. I'm not familiar with the GRUB errors. /boot
directory is on hda1, correct? Could you show /boot/grub/menu.lst?
Let's make sure the basics are in place before exploring what's up
with your BIOS, etc.
Colin, whether you start again with ALFS or LFS, you are likely to
run into the same problem again. The basic issue as far as I can
see, is that you are using one large partition for LFS. While a
Linux kernel has no problem reading large disks, most PC BIOSs do.
This dates back to the original design of the BIOS disk interface
in the 1980's when a 20MB was a large hard disk. IBM decided to
squeeze the Cylinder, Head, Sector address into one 16-bit
register: 10b for Cyl, 8b for Hd, 6b for Sect IIRC. This addressing
scheme can only access a max of 1024 cyl * 255 hd * 63 sect * 512
Bytes/sect which is approx 8GB if I calculate correctly.
At boot time, the BIOS loads your boot manager (grub, lilo, ntldr,
or whatever) and the boot manager doesn't have much else available
other than the BIOS services to load the kernel from disk into
memory. Once the kernel has booted you have access to your full
disks, but everything needed to load the kernel must be below
cylinder 1024 to be sure of success. There may be ways to bypass
this, e.g. BIOS extensions, a boot loader that implements it's own
disk access bypassing the BIOS (and still fits into about 330 Bytes
of your boot sector?).... The simplest and safest method is to make
sure your kernel is fully contained within the first 1024 cylinders
of your disk.
When you write a file (e.g. your kernel image) to the filesystem
you have no way of controlling which disk blocks within the
partition are used to store it. The only thing you can say is that,
as a genereral rule, the disk will start filling up from the
beginning (low cyl #) and grow towards the end. As you have filled
up your LFS partition with sources and installed programs and only
compiled and installed the kernel right near the end, it is most
likely partly or completely located beyond the 1024 cyl boundary.
The typical solution is to have your kernel on a small partition
located near the beginning of the disk. This is either the root
partition or a dedicated boot partition. A dedicated boot partition
can be shared between different Linux instances on a multi-boot PC,
in which case your root partition can be as big as you like.
However the recommended way is to keep the root partition as small
as possible by moving at least /usr and /var onto separate
partitions (which is rather like putting your "Program Files" and
"Documents and Settings" folders on different disks/partitions in a
Windoze installation, except it's easier to accomplish ;-). The
best is to make /usr a read-only partition (after installing, of
course) and /var writable. The reasoning, I will not repeat as it
is well explained in the (short ~ 1 page) chapter 2 of FHS.
http://www.pathname.com/fhs/pub/fhs-2.3.html#THEFILESYSTEM
Chapter 5 of the same document also explains the best way to
combine /var and /usr on one partition.
Brandon
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
Hey, thanks everybody, i got it to work...
Colin Kemp
Manager of:
GreenBall Enterprises,
www.greenballenterprises.net
[EMAIL PROTECTED]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page