> space available for bootloader code there. My question is where does
> LILO or GRUB get put in a normal parition, because mke2fs seems to claim
> the whole parition, without leaving any room at the front for boot
> loading code.
Ok, I've answered my own question. It must have been late at night when
I was checking this before, but there is indeed room at the front of
normal partitions for boot loading code. Things like mkswap and mke2fs
don't touch the first 1024 bytes of the partitions they act on. That
must be where boot code goes for those things.
sopwith% dd if=/dev/zero of=img bs=512 count=20808
20808+0 records in
20808+0 records out
sopwith% sudo losetup /dev/loop0 img
sopwith% mke2fs /dev/loop0
sopwith% sudo losetup -d /dev/loop0
sopwith% hexdump img| more
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000400 0a30 0000 28a4 0000 0208 0000 2748 0000
0000410 0a25 0000 0001 0000 0000 0000 0000 0000
0000420 2000 0000 2000 0000 0518 0000 0000 0000
0000430 cf88 3af5 0000 0014 ef53 0001 0001 0000
0000440 cf88 3af5 4e00 00ed 0000 0000 0001 0000
0000450 0000 0000 000b 0000 0080 0000 0000 0000
0000460 0002 0000 0001 0000 f465 48d2 36c2 0042
0000470 a38d 2053 399b 2ed5 0000 0000 0000 0000
0000480 0000 0000 0000 0000 0000 0000 0000 0000
*
0000800 0003 0000 0004 0000 0005 0000 1f4c 050d
0000810 0002 0000 0000 0000 0000 0000 0000 0000
0000820 2003 0000 2004 0000 2005 0000 07fc 0518
As you can see, nothing is placed before 0000400, so the first two
sectors are available for things like LILO and GRUB.
Now, this begs the question, why 2 sectors instead of one?
--Ian
>
> --Ian
>
> >
> > Ian Duggan wrote:
> >
> > > Thanks. When I asked the original question, I really didn't understand
> > > how disk geometry and partitions and all worked. I've since dug into
> > > lots of information on the subject and am fairly secure in it now. These
> > > directions confirm what I'm currently attempting.
> > >
> > > There is one bit of information that I still haven't squared away in my
> > > head. I don't know of a good list to ask on, but perhaps since it is
> > > related to this, someone here will know.
> > >
> > > When the machine first boots, it runs the code in the MBR and uses the
> > > parition table there to find the partitions on the machine. If there is
> > > an extended partition, it will have another 512 byte boot sector at the
> > > beginning with its own partition table. My question is about regular
> > > partitions. When I create a file system in an image file (loopback
> > > mounted), it seems to use the entire space, including the initial 512
> > > bytes. When LILO or some other boot loader is installed into a partition
> > > rather than the MBR, where does it put its code and how is it run? I
> > > thought there would be an initial 512 bytes in regular partitions that
> > > could be used for bootcode, but the filesystem seems to use it... Where
> > > does LILO place itself when it is installed in a regular partition?
> > >
> > > My goal is to get the Hurd booting under plex86. I'll report back any
> > > progress I make.
> > >
> > > --Ian
> > >
> > > James McMechan wrote:
> > > >
> > > > Err, I don't think you have a "direct" geometry is the problem.
> > > > your Grub is trying to load based on where the data was in partition 3 but
> > > > your file does not have
> > > > the unused space that partitions 1 and 2 used. Grub is trying to skip over
> > > > to get to your kernel.
> > > > To fix this you can use a sparse file created something like this
> > > >
> > > > use fdisk DEVICE2 to get CYCLINDERS/HEADS/SECTORS
> > > > and PARTITION3's CYCLINDERSTART, CYCLINDEREND
> > > >
> > > > and then use dd to copy only the data you need
> > > > Master boot record (MBR)
> > > > dd if=DEVICE2 of=disk.img bs=512 count=1
> > > > and then skipping all the other partitions
> > > > dd if=DEVICE2 of=disk.img bs=$(( 512 * HEADS * SECTORS ))
> > > > seek=CYCLINDERSTART \
> > > > skip=CYCLINDERSTART count=$(( CYCLINDEREND-CYCLINDERSTART ))
> > > >
> > > > this will produce a spase file ( all unallocated cyclinders will read as
> > > > zero and not take up space )
> > > > which will have the same geometry as your real hard disk.
> > > > This will show up in 'ls -l' as being the same size as your hard disk but
> > > > 'df' will only show that sizeof(PARTITION3) is used
> > > > |MBR|unallocated space|Boot sector Grub|Hurd
> > > >
> > > > ----- Original Message -----
> > > > From: "Ian Duggan" <[EMAIL PROTECTED]>
> > > > To: "plex86" <[EMAIL PROTECTED]>
> > > > Sent: Friday, May 04, 2001 12:40 PM
> > > > Subject: [plex86] Disk Image Layout
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm trying to create a bootable disk image for plex86 using another
> > > > > partition that I have and am looking for assistance. I keep getting
> > > > > drive geometry errors from GRUB, which I'm trying to use as a boot
> > > > > loader.
> > > > >
> > > > > Here was the layout of the original partions
> > > > >
> > > > > DEVICE1: PARTITION1 (NTFS): Windows2k
> > > > > DEVICE2: PARTITION1 (ext2): Linux
> > > > > PARTITION2:(ext2): Hurd
> > > > > PARTITION3:(swap): Swap (linux and hurd)
> > > > >
> > > > > I had LILO in the MBR of DEVICE1, which booted Win2k, or took you to the
> > > > > boot sectors of D2P1 or D2P2. D2P1 had another LILO for booting various
> > > > > Linux kernels in D2P1. D2P2 had GRUB for booting various Hurd/Gnumach
> > > > > kernels in D2P2.
> > > > >
> > > > > So, I created an image of D2P2
> > > > >
> > > > > dd if=/dev/hdb2 of=disk.img
> > > > >
> > > > > So, I now have an image of D2P2 with Grub in it's boot sector, and
> > > > > Hurd/Gnumach. Something like this:
> > > > >
> > > > > | Boot Sector Grub | Hurd |
> > > > >
> > > > > I think I need to create something like this:
> > > > >
> > > > > | MBR | Boot Sector Grub | Hurd |
> > > > >
> > > > > To try to boot it using plex86 and not have GRUB get the drive
> > > > > geometries confused.
> > > > >
> > > > > Can someone point me to documentation on how I could lay out a proper
> > > > > image file to boot with, or provide instructions on how to go about
> > > > > creating it?
> > > > >
> > > > > --Ian
> > > > >
> > > > >
> >
> > --
> > Drew Northup, N1XIM
