boot loader that can read from partition? - Linux

This is a discussion on boot loader that can read from partition? - Linux ; Is there a boot loader than can read a kernel in from a raw partition? It should be able to work after having used a tool like "dd" to copy the kernel image directly to the partition device, without having ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: boot loader that can read from partition?

  1. boot loader that can read from partition?

    Is there a boot loader than can read a kernel in from a raw partition?
    It should be able to work after having used a tool like "dd" to copy
    the kernel image directly to the partition device, without having to
    reconfigure the boot loader whatsoever (e.g. initially configured to
    know which partition(s) have kernels to load, which is default, and be
    able to load whatever gets written there as long said partition has
    enough space to hold the kernel).

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

  2. Re: boot loader that can read from partition?

    phil-news-nospam@ipal.net wrote:
    > Is there a boot loader than can read a kernel in from a raw partition?


    Which architecture(s)? What environment (BIOS, OpenFirmware, etc.)
    for I/O? What disk layout for partitions (PC-DOS, Sun, BSD, Apple, ...)?


    For i386 with the usual BIOS and DOS-style ("basic") partitions:

    http://bitwagon.com/ftp/mbr03.tgz
    List partitions to console, select which partition using console
    (with user-defined labels, timeout, default), boot that partition.
    Fits in 446 bytes (512 - 2 - 16*4) of Master Boot Record (MBR).

    http://bitwagon.com/ftp/e2boot4c.tgz
    Boots named kernel and initrd and commandline from ext2 (also ext3)
    filesystem that uses 1KB blocksize [which is the default blocksize
    for "small" partitions; includes 100MB, for instance]. Fits in
    1024 - 2*2 bytes boot block of ext2/3 filesystem; requires mbr03
    [above] to provide "read block" subroutine.

    --

  3. Re: boot loader that can read from partition?

    On Sat, 14 Oct 2006 10:14:29 -0700 John Reiser wrote:
    | phil-news-nospam@ipal.net wrote:
    |> Is there a boot loader than can read a kernel in from a raw partition?
    |
    | Which architecture(s)? What environment (BIOS, OpenFirmware, etc.)
    | for I/O? What disk layout for partitions (PC-DOS, Sun, BSD, Apple, ...)?

    PC x86, DOS style partitions.

    Other architectures would be interesting, too, such as Sun Sparc.
    But for now, it is the commodity PC.


    | For i386 with the usual BIOS and DOS-style ("basic") partitions:
    |
    | http://bitwagon.com/ftp/mbr03.tgz
    | List partitions to console, select which partition using console
    | (with user-defined labels, timeout, default), boot that partition.
    | Fits in 446 bytes (512 - 2 - 16*4) of Master Boot Record (MBR).
    |
    | http://bitwagon.com/ftp/e2boot4c.tgz
    | Boots named kernel and initrd and commandline from ext2 (also ext3)
    | filesystem that uses 1KB blocksize [which is the default blocksize
    | for "small" partitions; includes 100MB, for instance]. Fits in
    | 1024 - 2*2 bytes boot block of ext2/3 filesystem; requires mbr03
    | [above] to provide "read block" subroutine.

    Is there any way to combine these? Since I don't need the ext2 code
    at all, and loading from a partition is always purely sequential,
    would it be possible to get the partition boot loader to load from
    the partition directly? It should just be a matter of reading the
    partition table to get the partition loadcation that mbr03 knows to
    do, load the image sequentially from start to end of the partition
    (it may be more sectors than needed) by simple sector increment by
    one, and then pass control to the kernel? Would it fit? Since at
    least sector 0 is never assigned to a partition, could additional
    unassigned sector be used to cheat for space on the boot loader?

    I don't have sufficient x86 assembly knowledge plus the spare machine
    needed to experiment with coding x86 assembly at the boot loader level
    to be able to put this together myself. So I was hoping there would
    be something already out there for what I think is a very straight
    forward way to boot load a kernel (if one is willing to chop up their
    space in partitions to hold a kernel someone). The kernel I have has
    a size of 4679831 right now. I figure an partition just shy of 8 MB
    would be well more than enough to hold a future kernel, and not too
    much for a boot loader to "over load" (e.g. it won't know anything
    more about the image size unless there is a field in the image that
    gives the size).

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

  4. Re: boot loader that can read from partition?

    phil-news-nospam@ipal.net wrote:
    > On Sat, 14 Oct 2006 10:14:29 -0700 John Reiser wrote:
    > | phil-news-nospam@ipal.net wrote:
    > |> Is there a boot loader than can read a kernel in from a raw partition?


    > PC x86, DOS style partitions.


    > | For i386 with the usual BIOS and DOS-style ("basic") partitions:
    > |
    > | http://bitwagon.com/ftp/mbr03.tgz
    > | http://bitwagon.com/ftp/e2boot4c.tgz


    > Is there any way to combine these? Since I don't need the ext2 code
    > at all, and loading from a partition is always purely sequential,
    > would it be possible to get the partition boot loader to load from
    > the partition directly? It should just be a matter of reading the
    > partition table to get the partition loadcation that mbr03 knows to
    > do, load the image sequentially from start to end of the partition
    > (it may be more sectors than needed) by simple sector increment by
    > one, and then pass control to the kernel? Would it fit? Since at
    > least sector 0 is never assigned to a partition, could additional
    > unassigned sector be used to cheat for space on the boot loader?


    The request "boot from a raw disk partition" [i.e., a marked extent
    of contiguous sectors] is somewhat strange. Unless there will be
    _no_ filesystem of any kind after boot, then put the kernel and initrd
    into a filesystem. Using the two .tgz above works for ext2/ext3.
    Syslinux works for FAT. loadlin also works on FAT, and will even
    boot linux from inside a running DOS. The OS/2 boot loader runs
    with upto 15 extents; you might try it.

    > I don't have sufficient x86 assembly knowledge plus the spare machine
    > needed to experiment with coding x86 assembly at the boot loader level
    > to be able to put this together myself.


    Use qemu. http://fabrice.bellard.free.fr/qemu/

    Explain enough about the need to use a raw disk partition, in order to
    convince other hackers to join you. Until then, qemu + {syslinux,
    loadlin, mbr03+e2boot4c, possibly others} is what you get.

    --

  5. Re: boot loader that can read from partition?

    On Sat, 14 Oct 2006 16:40:44 -0700 John Reiser wrote:
    | phil-news-nospam@ipal.net wrote:
    |> On Sat, 14 Oct 2006 10:14:29 -0700 John Reiser wrote:
    |> | phil-news-nospam@ipal.net wrote:
    |> |> Is there a boot loader than can read a kernel in from a raw partition?
    |
    |> PC x86, DOS style partitions.
    |
    |> | For i386 with the usual BIOS and DOS-style ("basic") partitions:
    |> |
    |> | http://bitwagon.com/ftp/mbr03.tgz
    |> | http://bitwagon.com/ftp/e2boot4c.tgz
    |
    |> Is there any way to combine these? Since I don't need the ext2 code
    |> at all, and loading from a partition is always purely sequential,
    |> would it be possible to get the partition boot loader to load from
    |> the partition directly? It should just be a matter of reading the
    |> partition table to get the partition loadcation that mbr03 knows to
    |> do, load the image sequentially from start to end of the partition
    |> (it may be more sectors than needed) by simple sector increment by
    |> one, and then pass control to the kernel? Would it fit? Since at
    |> least sector 0 is never assigned to a partition, could additional
    |> unassigned sector be used to cheat for space on the boot loader?
    |
    | The request "boot from a raw disk partition" [i.e., a marked extent
    | of contiguous sectors] is somewhat strange. Unless there will be
    | _no_ filesystem of any kind after boot, then put the kernel and initrd
    | into a filesystem. Using the two .tgz above works for ext2/ext3.
    | Syslinux works for FAT. loadlin also works on FAT, and will even
    | boot linux from inside a running DOS. The OS/2 boot loader runs
    | with upto 15 extents; you might try it.

    For loading from index sectors I have LILO. For loading from files in
    a filesystem, I have GRUB. Either of these should have been able to
    load from a partition mostly because it should be easy. Or what would
    be hard about it?


    |> I don't have sufficient x86 assembly knowledge plus the spare machine
    |> needed to experiment with coding x86 assembly at the boot loader level
    |> to be able to put this together myself.
    |
    | Use qemu. http://fabrice.bellard.free.fr/qemu/
    |
    | Explain enough about the need to use a raw disk partition, in order to
    | convince other hackers to join you. Until then, qemu + {syslinux,
    | loadlin, mbr03+e2boot4c, possibly others} is what you get.

    It's a system that will be dynamically built each time it boots up.
    But it also needs to be able to reboot in certain cases where it is
    not rebuilt for whatever reason. I can't rely on a filesystem being
    buildable. This also involves a small flash disk.

    This probably should have been the basic way to boot a system from
    early on. It would have, for example, avoided the need to store an
    array of indexes by LILO. It would have been easy to update the
    kernel. With two partitions, there could also be a fallback. I do
    not think it is strange at all. It's booting the KISS way. But if
    people don't like partitions, then I guess that might be the real
    reason.

    Does QEMU pass a whole disk device from the real machine into the
    virtual machine it emulates, at a different position ... e.g. can
    it make all of /dev/hdc appear as IDE primary master and then run
    a boot loader that uses BIOS for initial I/O?

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

  6. Re: boot loader that can read from partition?

    phil-news-nospam@ipal.net wrote:
    > Is there a boot loader than can read a kernel in from a raw partition?


    I would say that if a boot loader can't read an image which is just a
    contiguous sequence of sectors (size being determined by figuring out
    the image type from its header) it's a pretty darn useless boot loader.

    I mean, that's like the "hello, world" of booting, right? File system
    support is chrome plating.

    Under Grub, you can specify a block list instead of a filename, e.g.

    hd(0,1)+100,200+50

    Which means read blocks 0-99 and then 200-249.

    You can also tell Grub to select the root device without mounting it as
    a filesystem with "rootnoverify".

    I don't know if Grub is smart enough to stop reading when it encounters
    the end of the image, even if there are blocks left to read in the
    list. If that's the case, you could make the block list extra long and
    then not have to reconfigure it. In any case, Grub could probably be
    easily hacked into doing that if it doesn't.


  7. Re: boot loader that can read from partition?

    Kaz Kylheku wrote:
    > phil-news-nospam@ipal.net wrote:
    >
    >>Is there a boot loader than can read a kernel in from a raw partition?

    >
    >
    > I would say that if a boot loader can't read an image which is just a
    > contiguous sequence of sectors (size being determined by figuring out
    > the image type from its header) it's a pretty darn useless boot loader.
    >
    > I mean, that's like the "hello, world" of booting, right? File system
    > support is chrome plating.
    >
    > Under Grub, you can specify a block list instead of a filename, e.g.
    >
    > hd(0,1)+100,200+50
    >
    > Which means read blocks 0-99 and then 200-249.


    Note that Grub itself is heavily plated; some would say "bloated."
    Namely, it is approximately 30KB big, and those bytes must be somewhere.
    Better find out where, before you rely on it. On current vintage EIDE
    disks where sectors per track is assigned the value 63, there just
    happens to be 31KB in the last 62 sectors of the first track; the
    first sector of the first track is the Master Boot Record (MBR).
    On older vintage EIDE disks there may be only 60, or 32, or 31,
    or 17, or 16, or 15, or some other number of sectors per track;
    and on USB flash memory devices there can be many more choices.

    --

  8. Re: boot loader that can read from partition?

    On 15 Oct 2006 14:12:02 -0700 Kaz Kylheku wrote:
    | phil-news-nospam@ipal.net wrote:
    |> Is there a boot loader than can read a kernel in from a raw partition?
    |
    | I would say that if a boot loader can't read an image which is just a
    | contiguous sequence of sectors (size being determined by figuring out
    | the image type from its header) it's a pretty darn useless boot loader.
    |
    | I mean, that's like the "hello, world" of booting, right? File system
    | support is chrome plating.

    The boot loader that came with the kernel and allowed it to boot from a
    floppy by just dd-ing the image file to a floppy, back when it was small
    enough to fit on a floppy, would not do so on a hard drive. Maybe all
    it would have taken was some hack to change device? Is that loader even
    still part of the kernel source tree?

    I suppose I could argue something similar of a BIOS/PROM system that is
    a part of a computer. Back when computers had virtually no programming
    at startup, merely getting _one_ sector loaded into RAM was a nice trick.
    I remember hand toggling in a boot loader on a PDP-8 back in the 1970's.
    It was just enough to load some more words from the paper tape and run
    that. That code then loaded the rest.


    | Under Grub, you can specify a block list instead of a filename, e.g.
    |
    | hd(0,1)+100,200+50
    |
    | Which means read blocks 0-99 and then 200-249.

    But no capability select a partition by number? I suppose if I don't
    move the partition without reconfiguring Grub, that might be usable.


    | You can also tell Grub to select the root device without mounting it as
    | a filesystem with "rootnoverify".

    What does "select" mean in this case?


    | I don't know if Grub is smart enough to stop reading when it encounters
    | the end of the image, even if there are blocks left to read in the
    | list. If that's the case, you could make the block list extra long and
    | then not have to reconfigure it. In any case, Grub could probably be
    | easily hacked into doing that if it doesn't.

    I hope that reading in excess blocks is of no consequence as long as it
    doesn't get loaded into RAM that would cause some effect, such as the I/O
    space of a PC (0xA0000-0xFFFFF), and as long as it successfully hands off
    control to the loaded program correctly.

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

  9. Re: boot loader that can read from partition?

    phil-news-nos...@ipal.net wrote:
    > | Under Grub, you can specify a block list instead of a filename, e.g.
    > |
    > | hd(0,1)+100,200+50


    That should have been (hd0,1), oops!

    > | Which means read blocks 0-99 and then 200-249.
    >
    > But no capability select a partition by number?


    That's what the (hd0,1) syntax does. In this case, second partition of
    the first drive.

    > | You can also tell Grub to select the root device without mounting it as
    > | a filesystem with "rootnoverify".
    >
    > What does "select" mean in this case?


    Simply to remember device and partition as current in some global
    variable, similarly to what chdir() does for your current working
    directory in a process.

    When the device is set, then it can be omitted from subsequent
    commands. After:

    rootnoverify (hd0,0)

    the abbreviated block list "+100" implicitly means "(hd0,0)+100". With
    the "root" command, the device is also mounted, whatever that means
    inside Grub. The documentation says so. Probably, Grub groks the file
    system and retains some information about it.


  10. Re: boot loader that can read from partition?

    On Sun, 15 Oct 2006 15:14:40 -0700 John Reiser wrote:

    | Kaz Kylheku wrote:
    |> phil-news-nospam@ipal.net wrote:
    |>
    |>>Is there a boot loader than can read a kernel in from a raw partition?
    |>
    |>
    |> I would say that if a boot loader can't read an image which is just a
    |> contiguous sequence of sectors (size being determined by figuring out
    |> the image type from its header) it's a pretty darn useless boot loader.
    |>
    |> I mean, that's like the "hello, world" of booting, right? File system
    |> support is chrome plating.
    |>
    |> Under Grub, you can specify a block list instead of a filename, e.g.
    |>
    |> hd(0,1)+100,200+50
    |>
    |> Which means read blocks 0-99 and then 200-249.
    |
    | Note that Grub itself is heavily plated; some would say "bloated."
    | Namely, it is approximately 30KB big, and those bytes must be somewhere.
    | Better find out where, before you rely on it. On current vintage EIDE
    | disks where sectors per track is assigned the value 63, there just
    | happens to be 31KB in the last 62 sectors of the first track; the
    | first sector of the first track is the Master Boot Record (MBR).
    | On older vintage EIDE disks there may be only 60, or 32, or 31,
    | or 17, or 16, or 15, or some other number of sectors per track;
    | and on USB flash memory devices there can be many more choices.

    I was under the impression Grub would not do what I wanted. Maybe it can
    be tricked into it. But the bloat is a big reason I'd rather not use it.
    If I have to hack something (like those programs of yours) I would much
    rather start with something simpler than Grub.

    I don't like the idea of having to put filesystem knowledge in a bootloader.
    That locks me into filesystem types it knows. And I don't like LILO's
    method of keeping index blocks in the filesystem space (and its dependency
    on filesystem data blocks not moving).

    I suppose having a boot loader that only knows PC/DOS style partitions is
    a lock in, too. But it looks like things are simple enough that a different
    instance could be made with knowledge of other partition types like BSD.

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

  11. Re: boot loader that can read from partition?

    phil-news-nospam@ipal.net writes:

    > rather start with something simpler than Grub.
    >
    > I don't like the idea of having to put filesystem knowledge in a bootloader.
    > That locks me into filesystem types it knows. And I don't like LILO's
    > method of keeping index blocks in the filesystem space (and its dependency
    > on filesystem data blocks not moving).


    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.

    > I suppose having a boot loader that only knows PC/DOS style partitions is
    > a lock in, too. But it looks like things are simple enough that a different
    > instance could be made with knowledge of other partition types like BSD.


    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 ...".

    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.

    --
    Lajos Parkatti

  12. Re: boot loader that can read from partition?

    On 19 Oct 2006 16:12:08 +0300 Lajos Parkatti wrote:
    | phil-news-nospam@ipal.net writes:
    |
    |> rather start with something simpler than Grub.
    |>
    |> I don't like the idea of having to put filesystem knowledge in a bootloader.
    |> That locks me into filesystem types it knows. And I don't like LILO's
    |> method of keeping index blocks in the filesystem space (and its dependency
    |> on filesystem data blocks not moving).
    |
    | 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.


    |> I suppose having a boot loader that only knows PC/DOS style partitions is
    |> a lock in, too. But it looks like things are simple enough that a different
    |> instance could be made with knowledge of other partition types like BSD.
    |
    | 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.

    The boot loader would either need to have the partition starting point
    coded into it, or read the partition table to get it.


    | 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.

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

  13. Re: boot loader that can read from partition?

    phil-news-nospam@ipal.net writes:

    > On 19 Oct 2006 16:12:08 +0300 Lajos Parkatti 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.

    > | 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).

    > 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).

    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.

    > | 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).

    So:

    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.


    --
    Lajos Parkatti


  14. Re: boot loader that can read from partition?

    On Thu, 19 Oct 2006 17:35:40 -0400 Bill Marcum wrote:

    | On 19 Oct 2006 19:25:51 GMT, phil-news-nospam@ipal.net
    | wrote:
    |>
    |> 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.
    |>
    | Sounds like you want grub.

    I could not find the capability I wanted in the grub documentation.

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

  15. Re: boot loader that can read from partition?

    On 20 Oct 2006 12:28:39 +0300 Lajos Parkatti wrote:
    | phil-news-nospam@ipal.net writes:
    |
    |> On 19 Oct 2006 16:12:08 +0300 Lajos Parkatti 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@ipal.net |
    |------------------------------------/-------------------------------------|

  16. Re: boot loader that can read from partition?

    phil-news-nospam@ipal.net wrote:
    > On Thu, 19 Oct 2006 17:35:40 -0400 Bill Marcum wrote:
    >
    > | On 19 Oct 2006 19:25:51 GMT, phil-news-nospam@ipal.net
    > | wrote:
    > |>
    > |> 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.
    > |>
    > | Sounds like you want grub.
    >
    > I could not find the capability I wanted in the grub documentation.



    GRUB can load a list of disk blocks - and that's all we
    know about a kernel stored into a raw partition.

    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.

    --

    Tauno Voipio
    tauno voipio (at) iki fi

  17. Re: boot loader that can read from partition?

    On Fri, 20 Oct 2006 16:08:57 GMT Tauno Voipio wrote:
    | phil-news-nospam@ipal.net wrote:
    |> On Thu, 19 Oct 2006 17:35:40 -0400 Bill Marcum wrote:
    |>
    |> | On 19 Oct 2006 19:25:51 GMT, phil-news-nospam@ipal.net
    |> | wrote:
    |> |>
    |> |> 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.
    |> |>
    |> | Sounds like you want grub.
    |>
    |> I could not find the capability I wanted in the grub documentation.
    |
    |
    | GRUB can load a list of disk blocks - and that's all we
    | know about a kernel stored into a raw partition.

    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.


    | 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).

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

  18. Re: boot loader that can read from partition?

    phil-news-nospam@ipal.net wrote:
    > On Fri, 20 Oct 2006 16:08:57 GMT Tauno Voipio wrote:
    > | phil-news-nospam@ipal.net wrote:
    > |> On Thu, 19 Oct 2006 17:35:40 -0400 Bill Marcum wrote:
    > |>
    > |> | On 19 Oct 2006 19:25:51 GMT, phil-news-nospam@ipal.net
    > |> | wrote:
    > |> |>
    > |> |> 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.
    > |> |>
    > |> | Sounds like you want grub.
    > |>
    > |> I could not find the capability I wanted in the grub documentation.
    > |
    > |
    > | GRUB can load a list of disk blocks - and that's all we
    > | know about a kernel stored into a raw partition.
    >
    > 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.

    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.

    --

    Tauno Voipio
    tauno voipio (at) iki fi


  19. Re: boot loader that can read from partition?

    On Fri, 20 Oct 2006 21:27:10 GMT Tauno Voipio 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@ipal.net |
    |------------------------------------/-------------------------------------|

  20. Re: boot loader that can read from partition?

    phil-news-nospam@ipal.net wrote:
    > So if I format the filesystem and put the kernel back in, GRUB will
    > load it OK?


    Not if Grub lives on that same filesystem. In that case, Grub has to be
    reinstalled after the reformatting.

    > 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.


    Grub's stage 1 boot loader uses a sector list to get Grub itself. Once
    that is running, it has the filesystem support. It can read and execute
    a configuration script file from the filesystem, which tells it how to
    behave and where to find images. You can reconfigure all that without
    having to update the Grub image or the boot sector.


+ Reply to Thread
Page 1 of 2 1 2 LastLast