Yes, I am going to use etherboot to load kernel image, but I don't know how to link those files. Bendany told me : "etherboot will init the harddisk, and get the linux kernel from the first partition of your harddisk. so you just put the kernel into your harddisk's first partition and the kernel name must be "kernel". filesystem can be ext2. " But I have multiple partitions on my harddisk, Linux is not on /dev/hda1 , is there any other solutions ? Thanks.
From: ron minnich <rminnich@lanl.gov> To: Yap Ee Huey <yapeehuey@hotmail.com> CC: linuxbios@clustermatic.org, <etherboot-users@lists.sourceforge.net> Subject: Re: Linuxbios + Etherboot + tagged Kernel Image Date: Thu, 24 Apr 2003 08:42:08 -0600 (MDT)
one quick question: are you using etherboot to load the kernel image?
ro
_________________________________________________________________ Using a handphone prepaid card? Reload your credit online! http://www.msn.com.my/reloadredir/default.asp
"etherboot will init the harddisk, and get the linux kernel from the first partition of your harddisk. so you just put the kernel into your harddisk's first partition and the kernel name must be "kernel". filesystem can be ext2. " But I have multiple partitions on my harddisk, Linux is not on /dev/hda1 , is there any other solutions ? I think the patch support ext2, ext3 and vfat at the moment. If you are using something other than these. You still can extract file system code from grub to support other filessystem, eg reiserfs, xfs, jfs.
-Andrew -- Andrew Ip Email: aip@cwlinux.com Tel: (852) 2542 2046 Fax: (852) 2542 2036 Mobile: (852) 9201 9866 Cwlinux Limited Unit 202B 2/F Lai Cheong Factory Building, 479-479A Castle Peak Road, Lai Chi Kok, Kowloon, Hong Kong. Tel: (852)2542 2046 Fax: (852)2542 2036 For public pgp key, please obtain it from http://www.keyserver.net/en.
On Fri, 25 Apr 2003, Andrew Ip wrote:
"etherboot will init the harddisk, and get the linux kernel from the first partition of your harddisk. so you just put the kernel into your harddisk's first partition and the kernel name must be "kernel". filesystem can be ext2. " But I have multiple partitions on my harddisk, Linux is not on /dev/hda1 , is there any other solutions ? I think the patch support ext2, ext3 and vfat at the moment. If you are using something other than these. You still can extract file system code from grub to support other filessystem, eg reiserfs, xfs, jfs.
Wrong etherboot. For file system support you want my patch against etherboot-5.0.6 found at http://www.missl.cs.umd.edu/~agnew/ (the rules change though, now you want to "make bin32/sis900.ebi")
On Fri, 25 Apr 2003, Yap Ee Huey wrote:
Yes, I am going to use etherboot to load kernel image, but I don't know how to link those files. Bendany told me :
Here is what I did: I used fdisk to make an empty partition at the front of the drive, at hda1. When I had a kernel ready: cat vmlinux.gz > /dev/hda1 That puts it where etherboot can get it. ron
ron minnich <rminnich@lanl.gov> writes:
On Fri, 25 Apr 2003, Yap Ee Huey wrote:
Yes, I am going to use etherboot to load kernel image, but I don't know how to link those files. Bendany told me :
Here is what I did:
I used fdisk to make an empty partition at the front of the drive, at hda1. When I had a kernel ready:
cat vmlinux.gz > /dev/hda1
That puts it where etherboot can get it.
Note. Etherboot is not limited to only one hard disk so it may make sense to put it on a secondary disk. Eric
cat vmlinux.gz > /dev/hda1
That puts it where etherboot can get it.
Note. Etherboot is not limited to only one hard disk so it may make sense to put it on a secondary disk.
Eric
I don't see how this works, with an 8kbytes limit how etherboot could find it in hda1. Typical disks are 63 sectors, so the initial skip to partition 1 is 63 x 512 ~= 32K, or much larger than 8K. -Steve
Steve Gehlbach <steve@nexpath.com> writes:
cat vmlinux.gz > /dev/hda1
That puts it where etherboot can get it. Note. Etherboot is not limited to only one hard disk so it may make sense to put it on a secondary disk. Eric
I don't see how this works, with an 8kbytes limit how etherboot could find it in
hda1. Typical disks are 63 sectors, so the initial skip to partition 1 is 63 x 512 ~= 32K, or much larger than 8K.
So again my goal was not to be able to boot out of hda1 but to provide a MBR like boot mechanism that would work with older systems. It happens that you can tell some of the partition programs to create a partition that is not aligned on cylinder boundaries. So they can create a partition hda1 that you can just throw the ELF image into. The way etherboot loads the image is it interprets all addresses in the ELF image as disk addresses with offsets from the start of the ELF image. There is support for ELF64 so you can if you wish scatter the image across an entire disk. The only restriction is there is an assumption that the entire ELF header, and ELF program header are read into memory with the first 8K read. I have a proof of concept utility that will look up the addresses a ELF images is stored on disk (like lilo) and generate a new 64bit ELF header that will allow it to be loaded from anywhere on the disk. I have not published it because the address it puts the ELF header at is currently hard coded, and there are several other stupid assumptions. If you want the code holler and I will send it to you. Eric
On Fri, 25 Apr 2003, Steve Gehlbach wrote:
cat vmlinux.gz > /dev/hda1 I don't see how this works, with an 8kbytes limit how etherboot could find it in hda1. Typical disks are 63 sectors, so the initial skip to partition 1 is 63 x 512 ~= 32K, or much larger than 8K.
my mistake. What I have done is this for now: dd if=elfImage of=/dev/hda bs=4096 skip=1 preserves partition information. A kludge, but it works. ron
ron minnich wrote:
my mistake. What I have done is this for now: dd if=elfImage of=/dev/hda bs=4096 skip=1
preserves partition information. A kludge, but it works.
IMHO it is a better solution than non-standard partitioning. Actually I think the region past the first sector (512 bytes) is unused, if I am reading http://www.ata-atapi.com/hiwtab.htm correctly. One should also point out that this overlaps into partition 1, if that is not obvious, so partition 1 should be large enough and unused. -Steve
On Sat, 26 Apr 2003, Steve Gehlbach wrote:
IMHO it is a better solution than non-standard partitioning. Actually I think the region past the first sector (512 bytes) is unused, if I am reading http://www.ata-atapi.com/hiwtab.htm correctly.
you are but Plan 9 uses the second 512 bytes and just to be safe I decided to put it at 4096.
One should also point out that this overlaps into partition 1, if that is not obvious, so partition 1 should be large enough and unused.
yes. ron
Steve Gehlbach <steve@nexpath.com> writes:
ron minnich wrote:
my mistake. What I have done is this for now: dd if=elfImage of=/dev/hda bs=4096 skip=1 preserves partition information. A kludge, but it works.
IMHO it is a better solution than non-standard partitioning. Actually I think the region past the first sector (512 bytes) is unused, if I am reading http://www.ata-atapi.com/hiwtab.htm correctly.
Right the region past the first sector (512 bytes) is unused. Which is why I just move up the start of first partition into the unused space. I don't see how using the standard partition tables to force a partition to a particular location on the disk is non-standard partitioning. I agree it drops compatibility with ancient versions of DOS but otherwise it is just reserving space.
One should also point out that this overlaps into partition 1, if that is not obvious, so partition 1 should be large enough and unused.
So why should partition 1 not contain the correct information. If you really want to dig into this, my proof of concept utility that will allow much more interesting layouts than starting an ELF image within 8K of the start of the disk. ftp://ftp.lnxi.com/pub/src/linuxbios/installelf.c With that you can just put start of the ELF image in the unused space (normally 63 sectors I think) and put the ELF image on a filesystem. Eric
Steve Gehlbach wrote: (Hey, Steve! How's it going?)
ron minnich wrote:
my mistake. What I have done is this for now: dd if=elfImage of=/dev/hda bs=4096 skip=1
preserves partition information. A kludge, but it works.
IMHO it is a better solution than non-standard partitioning. Actually I think the region past the first sector (512 bytes) is unused, if I am reading http://www.ata-atapi.com/hiwtab.htm correctly.
The 62 sectors after the MBR are not officially used, but there are apps and OSes that do make use of that space. For example, the latest version of TurboTax sticks some crap in there somewhere for its DRM mechanism. There was a big stink about it by some users, because it hosed other apps that also use that space. So if the PC is used for anything other than Linux (I don't know of any Linux OS or app related uses of that space), you might want to be careful.
One should also point out that this overlaps into partition 1, if that is not obvious, so partition 1 should be large enough and unused.
-Steve
Alternatively, could partition 1 start farther along on the disk, leaving enough space for the kernel at the front of the disk? This would eliminate the possible confusion of having a partition that is off limits. (I haven't used the newer Etherboot, so I am not very familiar with this boot-from-disk capability.) -Don -- Don Christensen Senior Software Development Engineer djc@cisco.com Cisco Systems, Santa Cruz, CA "It was a new day yesterday, but it's an old day now."
On Tue, Apr 29, 2003 at 02:00:58PM -0700, Donald J Christensen wrote:
IMHO it is a better solution than non-standard partitioning. Actually I think the region past the first sector (512 bytes) is unused, if I am reading http://www.ata-atapi.com/hiwtab.htm correctly.
The 62 sectors after the MBR are not officially used, but there are apps and OSes that do make use of that space. For example, the latest version of TurboTax sticks some crap in there somewhere for its DRM mechanism. There was a big stink about it by some users, because it hosed other apps that also use that space.
So if the PC is used for anything other than Linux (I don't know of any Linux OS or app related uses of that space), you might want to be careful.
I think GRUB is using this space to store its "stage1.5" image. It's 6-9KB in size. -- Takeshi
participants (8)
-
Adam Agnew -
Andrew Ip -
Donald J Christensen -
ebiederman＠lnxi.com -
ron minnich -
SONE Takeshi -
Steve Gehlbach -
Yap Ee Huey