(no subject)

Brandon Peirce 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
>>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 

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 mailing list