Re: boot loader that can read from partition?

On 20 Oct 2006 12:28:39 +0300 Lajos Parkatti <lparkatt@xxxxxxxxxxx> wrote:
| phil-news-nospam@xxxxxxxx writes:
|
|> On 19 Oct 2006 16:12:08 +0300 Lajos Parkatti <lparkatt@xxxxxxxxxxx> wrote:
|
|> | It is /sbin/lilo that needs to have the index file in a filesystem,
|> | not LILO. You could copy most (all) of the LILO code and simply
|> | replace the references to sectors belonging to a file system with
|> | references to sectors somewhere else.
|> |
|> | So use the code, but don't run /sbin/lilo.
|>
|> LILO still reads the list of sectors. It would still need to be changed
|> to iterate through a range of sectors.
|
| Yes. That change cannot be hard to do. You could still use a list to
| load the secondary boot loader.

Where is the list stored?


|> | Why do you need a partition? To get the starting point from the
|> | partition table. But you could save that pointer in the bootloader
|> | itself. And you need "dd of=/dev/hda seek= ..." instead of plain
|> | "dd of=/dev/hdaX ...".
|>
|> To _write_ the kernel, of=/dev/hdaX will work.
|
| As long as you use one partition per kernel and have all your boot
| loader code in the boot sector. And use only those boot parameters
| that are coded into the kernel itself (I think other boot parameters
| are difficult to implement with your approach).

One partition per kernel is fine. I would expect a more spartan boot
loader.


|> The boot loader would either need to have the partition starting point
|> coded into it, or read the partition table to get it.
|
| Yes. If the value is coded into the boot loader in the same format as
| in the partition table and used by reference, then the code to read it
| would be the same (I think BIOS loads all of the MBR, both the boot
| code and the partition table, to the same place).

Yes, I believe it does. It would be extra effort to avoid it.


| Of course using a partition is cleaner. But even then you do not have
| to restrict yourself to the beginning of the partition. Even in one
| "cylinder" of a modern disk there is space for more than one kernel.
| If you use offsets you could store several kernels in one partition.

I wouldn't rule out some kind of structure for multiple kernels.
But I want to at least get the basics working, first.


|> | You can then either use a partition or space not belonging to any
|> | partition. You are not limited to one kernel per partition as you can
|> | reserve some space in the beginning of your partition for a simple
|> | table - or for the LILO secondary boot loader and your hand crafted
|> | LILO map file.
|>
|> I don't want to land the kernel at some arbitrary sector. I want it
|> specifically to be in a partition. I don't want to have to re-write
|> the boot loader to disk to change anything besides which partition
|> number is the default.
|
| Ok. Are the partition borders supposed to move around? In that case
| you of course have to look at the real partition table. There is no
| need to restrict yourself to the beginning of the partition though
| (as long as you are willing to use the "seek" option of dd).

They may. I haven't figured out what the future holds, yet. Give
me 10 years and I'll tell you what I need 9 years from now :-)


| The boot loader reads the starting address of the relevant partition
| from the partition table (or from some arbitrary place). Then it
| either loads the kernel from the first sectors of that partitions or
| from consecutive sectors at some offset from the beginning of the
| partition. The latter is much more flexible and doesn't waste more
| than a few bytes - and leaves space for a secondary boot loader.
|
| When you want to change kernel you can change the partition number
| or you could also change the "kernel count" in this partition. Some
| more bits to write.
|
| If you want to use LILO you get a load of extra features that you do
| not need, but if you change it to use ranges instead of lists you do
| not need a lot more space. Just the secondary boot loader and a small
| map file. If you change the addresses to be offsets from the start of
| your partition you can move around the partitions without having to
| reinstall the boot loader. Even with those changes I think using the
| LILO code is much easier than to code a simpler boot loader from
| scratch.

Where would this map file be? One thing I want to avoid is the boot
loader storing anything it needs in any filesystem. I want to be able
to zero-out and reformat every filesystem and still have the boot loader
be able to bring up a kernel.

Right now I'm playing around with QEMU. It has this option -kernel which
loads a kernel from a file it reads instead of depending on a boot loader.
This is actually kind of nice for when I am building a new system on a
2nd disk drive. At some point that new drive is almost complete, but has
no boot loader. LILO seems to never get it right when trying to make one
drive (e.g. /dev/hdc) bootable for when it will be another (e.g. /dev/hda).
So I run QEMU and make /dev/hdc appear as /dev/hda to the guest, and bring
up the first time kernel from an image file in the host system. Then I do
the lilo command in the guest OS and it operates as if everything is on
/dev/hda, even though physically it went to /dev/hdc.

At the moment, my kernel resides in a partition that is a smallish (256MB)
system, along with lilo and many recovery tools. That partition is not
used during normal system operation which uses other full size partitions.
I would like to be able to easily rebuild that extra system partition but
not clobber the kernel when doing so. Hence the need for another partition.

Here is what my partition layouts look like on some different machines.
In all cases, partition 1 is the mini system with the kernel and lilo.
What I would do is have the kernel be in partition 1, the mini system
in partition 2, and the rest follow in some arrangement.

------------------------------------------------------------------------
Disk /dev/hda: 122.9 GB, 122942324736 bytes
255 heads, 63 sectors/track, 14946 cylinders, total 240121728 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 64 514079 257008 83 Linux
/dev/hda2 514144 1028159 257008 83 Linux
/dev/hda3 1028160 11309759 5140800 5 Extended
/dev/hda5 1028224 1799279 385528 83 Linux
/dev/hda6 1799344 3084479 642568 83 Linux
/dev/hda7 3084544 3855599 385528 83 Linux
/dev/hda8 3855664 9253439 2698888 83 Linux
/dev/hda9 9253504 11309759 1028128 82 Linux swap
/dev/hda4 11309760 240107489 114398865 83 Linux
------------------------------------------------------------------------
Disk /dev/hda: 122.9 GB, 122942324736 bytes
255 heads, 63 sectors/track, 14946 cylinders, total 240121728 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 64 514079 257008 83 Linux
/dev/hda2 514080 4626719 2056320 5 Extended
/dev/hda5 514144 771119 128488 83 Linux
/dev/hda6 771184 1028159 128488 83 Linux
/dev/hda7 1028224 2313359 642568 83 Linux
/dev/hda8 2313424 2570399 128488 83 Linux
/dev/hda9 2570464 4626719 1028128 82 Linux swap
/dev/hda3 4626720 12851999 4112640 83 Linux
/dev/hda4 12852000 240121727 113634864 83 Linux
------------------------------------------------------------------------
Disk /dev/hda: 80.0 GB, 80026361856 bytes
255 heads, 63 sectors/track, 9729 cylinders, total 156301488 sectors
Units = sectors of 1 * 512 = 512 bytes

Device Boot Start End Blocks Id System
/dev/hda1 64 514079 257008 83 Linux
/dev/hda2 514080 5654879 2570400 5 Extended
/dev/hda5 514144 771119 128488 83 Linux
/dev/hda6 771184 1028159 128488 83 Linux
/dev/hda7 1028224 3084479 1028128 83 Linux
/dev/hda8 3084544 3598559 257008 83 Linux
/dev/hda9 3598624 5654879 1028128 82 Linux swap
/dev/hda3 5654880 18506879 6426000 83 Linux
/dev/hda4 18506880 156301487 68897304 83 Linux
------------------------------------------------------------------------

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

Relevant Pages

  • Re: writing to a partition
    ... and places it at address 0x07c00, and passes execution to it. ... boot loader used by LILO, when executed, moves _itself_ to address 0x96a00, ... LILO all together, as it would need to be tricked into thinking all the ... I still have the Linux partition and the FREEDOS partition and still ...
    (comp.os.linux.misc)
  • Re: boot loader that can read from partition?
    ... loader storing anything it needs in any filesystem. ... to zero-out and reformat every filesystem and still have the boot loader ... But you obviously can't zero-out and reformat every partition. ... configuration file, and kernel images. ...
    (comp.os.linux.development.system)
  • Re: boot loader that can read from partition?
    ... You could copy most of the LILO code and simply ... | references to sectors somewhere else. ... As long as you use one partition per kernel and have all your boot ... If the value is coded into the boot loader in the same format as ...
    (comp.os.linux.development.system)
  • Re: how to tell if a specific data block is sparse?
    ... | The MBR, the very first sector of the drive, is outside any filesystem. ... | The e2fs boot block is just the first two sectors of its partition. ... a boot loader, unless the boot loader is made to be part of the image ... that goes into a partition meant to hold the kernel. ...
    (comp.os.linux.development.system)
  • Re: boot rh9
    ... > Is it possible to copy the contents of the boot floppy into /boot?? ... >> Populate it by reloading the kernel RPM from the distro. ... Above will not repopulate the "/boot" partition with Lilo required ...
    (linux.redhat)