Re: boot loader that can read from partition?

On Fri, 20 Oct 2006 21:27:10 GMT Tauno Voipio <tauno.voipio@xxxxxxxxxxxxx> wrote:

|> But it has to store the list somewhere if it's using a list. There is not
|> enough space in the MBR to store that there. A range could be stored in
|> the MBR. Or even less space is needed to store and index into the partition
|> table.
|
| GRUB cannot live in MBR alone, anyway. It's about 100 kbytes (depending
| on which filesystems are included). The raw partition block list is
| pretty simple: just starting block and count of blocks.

Where do all those 100 kbytes reside? The space after the MBR up to
the first possible partition in the next track is at most 63 sectors
and may on some drives be even less.

I don't need any filesystems to be included. So now how big is it
without any?


| Normally, GRUB boot sector has a LILO-style block list of the
| next part (phase 1.5 or phase 2). The phase 2 part is the full-
| capability loader. Thses things have to be stored into a file
| system that is understood by GRUB.
|
|> | The problem is how many blocks to load. When using LILO,
|> | the installer can read it from the kernel file properties,
|> | and GRUB reads the length from the file system. The built-in
|> | loader of kernels up to version 2.4 got the length from the
|> | length of the linked kernel image.
|> |
|> | Note that the length problem is there regardless which
|> | loader you'll use.
|>
|> The length problem means some extra sectors are loaded into memory in
|> locations beyond the end of the kernel. That's not a big deal. But it
|> can be dealt with by updating the partition table to match the kernel
|> size (but not update it into the next partition, of course).
|
| The overflow is more than a couple of sectors - the partitions
| are counted in units of cylinders (although this is obsolete and
| has nothing to do with the physical cylinders anymore).
|
| Methinks that a file system in the boot partition is much less
| prone to trouble than re-partitioning due to kernel size changes.

So if I format the filesystem and put the kernel back in, GRUB will
load it OK? If it understands and reads the filesystem (as opposed
to the collection of a list of sectors that LILO does), I would think
that it should. But where are those 100 kbytes hiding? if they are
in the filessytem, they may be lost.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-2006-10-20-1924@xxxxxxxx |
|------------------------------------/-------------------------------------|
.

Relevant Pages

  • Re: How to backup the MBR?
    ... > are 63 sectors per track or head). ... take), the DiskID, and the master partition table. ... Fixmbr is a convenient way to restore the standard MBR boot code, ...
    (microsoft.public.windowsxp.general)
  • Re: How to backup the MBR?
    ... >> Their MBRutil lets you save the 512 bytes of the MBR or the ... >> are 63 sectors per track or head). ... > that it includes the partition table. ... Of the programs that I've seen use the bootstrap code area in the MBR, ...
    (microsoft.public.windowsxp.general)
  • Re: kernel has null dereference during boot
    ... Forgot to identify the kernel. ... > First I would save copies of the partition table and bootloader for future ... > After locating and identifying any problem, I would rewrite the MBR ... fdisk's "p" comment (the one in the installer did not notice anything ...
    (Debian-User)
  • Re: FreeDOS installation
    ... is also the linux loader, you will get the same result. ... I'm not sure what you mean by "the MBR copy". ... FAT in an MS-Dos partition... ... kernel file in the linux partition. ...
    (comp.os.msdos.misc)
  • Re: COFF
    ... > partition in its partition table. ... > the MBR program jumps to memory location 0000:7C00. ... > system has its own boot sector format. ... > loader program (or perhaps the kernel itself or perhaps a "boot manager ...
    (comp.programming)
Loading