brandon_peirce at hotmail.com
Wed Aug 23 11:43:18 PDT 2006
Dan Nicholson wrote:
>On 8/22/06, Colin Kemp <colin at greenballenterprises.net> 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
>>- 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
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.
Chapter 5 of the same document also explains the best way to combine /var
and /usr on one partition.
More information about the lfs-support