Re: playing with bootxx_ext2fs

[Greg Troxel <gdt%lexort.com@localhost>]

pierre-philipp braun <pbraun%nethence.com@localhost> writes:

> This closely relates to the previous message, but tackles another
> approach to get NetBSD boot strapped right by preparing the boot blocks
> from a gnu/linux rescue system, namely trying to use the full native
> chain against an kernel that is available on an ext2 file-system:

Read mbr(8) and boot(8), but they don't fully explain what you are
(entirely reasonably) asking.

> NetBSD MBR --> bootxx_ext2fs --> /boot --> netbsd

I'm not sure you need "NetBSD MBR", but you might.  On NetBSD x86,
sector 1 is for disklabel and the plan is for the MBR to load sectors
2-15.  That lets you not have an MBR partition at all.  Normally people
put the NetBSD partition at 63 in the old days, probably 64 now, to
leave the first few blocks cleanly not in a partition.  Then the MBR
boot chain loads the first sector of the partition, which in NetBSD then
loads 2-15 of the partition.

In a filesystem/partition, sectors 2-15 contain bootxx_foo.  These read
the fs and find /boot.  On some systems (sparc?) they are patched with
the sectors of /boot, but on x86 they read the fs and this isn't
necessary.  /boot always reads the fs to find /netbsd.

I am a little fuzzy on what happens when you have a system like:
  fdisk partition 1: start at 64, NetBSD, active
  disklabel (presumably at 65) shows a at 64-x, e at x+1 to end

Then, there is MBR with boot code and fdisk table at 0.

So I went looking on a physical system.

there is one fdisk partition:
0: NetBSD (sysid 169)
    bootmenu: 2T
        start 64, size 3907029104 (1907729 MB, Cyls 0/1/2-243201/80/63), Active
        
sector 0 has an MBR, with bytes match /usr/mdec/mbr_bootsel up until
byte 401.

sectors 1 to 63 have not been written (I know this because I wrote a
test pattern and read it back when I got this disk, and it's still
there).

sectors 64-79 (0-15 of the partition) look to be a chain sector,
disklabel, and bootxx_ffsv2 contents.  But the match was fuzzy in bytes.
I then installed the bootxx_ffsv2 from /usr/mdec (-8, the old one had
been from netbsd-7):
  installboot -v /dev/rwd0a /usr/mdec/bootxx_ffsv2
(Be sure to keep ffsv1 and ffsv2 straight; they are similar but have
different bootxx.) 

and then running cmp on the file obtained from dding blocks 64-79
against bootxx_ffsv2 resulted in a bunch of differing disklabel bytes
(within bytes 512-1023, actually different 89 bytes within 513-769) and
then hitting eof on bootxx_ffsv2.

I am unclear on whether the first block of bootxx_foo is considered part
of that, or something else that is glued on during the build.  I am
guessing that it can function as MBR on a system with no fdisk partition
table where the bootxx code is written starting at 0.  (Historically,
BSD had disk labels and did not run on PCs; the use of fdisk partitions
to reserve space for the BSD portion of the disk arose in order to
accomodate multi OS on a system and play nice with PC conventions.  You
won't find those on sparc, VAX, etc.)


So that's your answer: the MBR has to load the first block of the fs,
and that is from bootxx_foo, which loads 2-15 of the fs, which reads the
fs and loads /boot.  You almost certainly need a disklabel in block 1 of
the partition.



I am unclear on which filesystems /boot can handle, other than
ffs1/ffs2.  Surely that includes ext2fs and fat32, or we'd have
/boot-foo for them and I'd have heard about it.

I don't know the details of linux booting, but I wouldn't be shocked if
the 2-15 plan for ext2fs were the same.  That is what I would try to
figure out next if I were you.

I'm also not sure how netbsd disklabels fit in ext2fs.  I would try to
make a physical local machine have an ext2fs fs only, and see how it
works, before trying to mimic it on the VPS.

> The problem is obvious: there is no `installboot` command on gnu/linux.

There isn't natively, but when you cross-build netbsd it will be
produced as a tool as nbinstallboot.  See $TOOLDIR/bin.

> So I have tried some dirty things, namely `dd`ing the primary bootstrap
> against the device, and then `fsck.ext2` it to clean it up.  The result
> is not so great, as expected.
>
> 	NetBSD MBR boot
> 	Error no magic
>
> I found the `no magic` string onto `bootxx_ext2fs`, meaning that I
> cannot reach the secondary bootstrap so far.

I hope the above, which I had to inspect to figure out again, helps.

> Please help me understand how installboot is doing its job.  I can try
> to take bits from bootxx_ext2fs and push it on the right places onto the
> ext2 file-system with dd if/skip of/seek.

The big question is where your partition starts, and if 2-15 is
available.  NetBSD filesystems, following ancient tradition, leave 0-15
free so that this boot stuff has a home.

> Or let me know if there is a better idea.

Please describe the VPS/etc. environment precisely, in terms of the
virtualization approach, how linux boots and what is available in terms
of tools.

If this is meant to look like hardware, then presumably you need to end
up with an MBR that the pseudo-bios is ok with (perhaps that just "load
sector 0, jump to it" and it doesn't care) and then take it from there.

If it's xen you may be able to use py-grub instead.

Also note that NetBSD supports multiboot, which could be useful.