colin at greenballenterprises.net
Wed Aug 23 14:38:12 PDT 2006
On Aug 23, 2006, at 2:43 PM, Brandon Peirce wrote:
> 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 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.
> Chapter 5 of the same document also explains the best way to
> combine /var and /usr on one partition.
> FAQ: http://www.linuxfromscratch.org/lfs/faq.html
> Unsubscribe: See the above information page
Thanks man, i thought something like that had happened... I'll let
you know how it all works out
colin at greenballenterprises.net
More information about the lfs-support