Re: playing with bootxx_ext2fs

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

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

> ## Sectors 0 and 1
>
> Would sector 0 simply correspond to what is called the Partition Boot Record? *

Yes, I think "Partition Boot Record" or "Master Boot Record".  Really
the first bunch of bytes (400ish) are the boot code and then there is a
partition table (that you use with fdisk under NetBSD and Linux).

> There are bits of disklabel onto sector 1 indeed.

A BSD disklabel will be on sector 1 if you create a filesystem that
starts at 0.

I am not sure if you are talking about sector numbers of the disk, or of
a partition.

> ## Sectors 2-13 and getting closer
>
> The bootxx_ffsv2 and bootxx_ext2fs are both 6656 bytes (13 sectors) so
> one could assume the home for boot blocks is rather the same.

I would expect that each is a chain bootsector (block 0 of the file),
space for a BSD disklabel (block 1), and then the code (11, out of the
14 that it could be).

> As an attempt to figure that out, I eventually filled-up an ext2
> file-system with with random bytes and checked what space at the
> beginning happens to stay intact.  Not much happens until sector 434
> and 436.  So I guess there's lots of room there for whatever purposes.

That does not sound like a reliable way to figure that out.   I would
study the code and/or docs about the layout.

> I found out why I had no magic.  It was because fsck.ext2 cleans-up sector 2 and above.  Its output is pretty self-explanatory as it also talks about "Bad magic".
>
> # fsck.ext2 -y /dev/sda1
> e2fsck 1.44.1 (24-Mar-2018)
> ext2fs_open2: Bad magic number in super-block
> fsck.ext2: Superblock invalid, trying backup blocks...
> /dev/sda1 was not cleanly unmounted, check forced.
> Pass 1: Checking inodes, blocks, and sizes

If fsck_ext2fs wants to clear/write sector 2 of the fs, that's a clue
that the fs definition does not leave that available for boot.

I would read the installboot source code to see what it does; it may be
that there is a boot slot someplace else and that it writes the rest of
bootxx_ext2fs not where I am thinking for a bsd fs.


> So I finally tried the dirty way of `dd`ing bootxx_ext2fs right onto the partition but now without fscking.  The result is
>
> NetBSD/x86 ext2fs Primary Bootstrap
> Boot failed (errno  2): Can't open /boot
>
> Reboot and Select proper Boot device
> or Insert Boot Media in selected Boot device and press a key

So that means you did get the MBR to read the chainload sector 0 of the
partition (that you dd'd) and then the 2-13 or whatever, but then it
could not deal with the fs.

> It suggests the phase 1 boot strap code needs have a clue on its own
> device name.  Maybe it simply needs a disklabel.  I am stuck again,
> although I could try to dd/push a working disklabel over there.  I
> though I could avoid that, as the netbsd kernel seems to generate a
> soft-generated `e` partition.

Here, I think we are lacking clarity on the plan for booting ext2, and
that someone (you?) should figure that out, rather than guessing.

> ## 63 vs 64 vs 2048
>
> On NetBSD x86 we're still starting at 63.  In my previous attempt, I
> used the gnu/linux fdisk and cfdisk utilities with their modern
> defaults so the partition was starting at sector 2048.  While using
> `fdisk -c=dos` I could create a partition starting at 63 (the default
> was indeed 64).

People and defaults make different choices.  on x86, 63 is traditional
because it is one floppy track.  Some people use 64 because modern
spinning disks have 4KB physical sectors even though most present as
512B sections.  There, you don't want to do unaligned writes, so you
want all filesystems aligned to 8 sectors, which 63 is not.  64 is, and
2048 is aligned to 1 MB -- people often choose that.


> I do not think this makes a big difference for my purpose of boot
> strapping netbsd.

agreed.

> ## /boot supports ext2fs?
>
>> 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 would not be so certain.  As far as I've seen, bootxx_ext2fs is a
> pretty new thing and nothing tells the netbsd phase 2 boot strap can
> use it.  I do not know where to check tho.

You are right that it could be work in progress.

> ## hardware
>
> I should have mentioned bare-metal IaaS or root-server only, not VPS.
> This is a Supermicro SYS-5038MA-H24TRFG-ON002 and I reach its physical
> console through IPMI & Java.  NetBSD current dmesg here:
> http://tmp.nethence.com/dmesg/xc2015.txt (that dedibox dates 2015)
>
> The _rescue_ environment I am trying to install NetBSD from -- is an
> Ubuntu Bionic.  I got all the tools I want including qemu-kvm which
> allowed me to install NetBSD as such.  But I am trying to find the
> best approach.  FreeBSD 11.1 is also available.

You may be better off with FreeBSD as an installation base.

If you could get the hoster to add a NetBSD install image isofs (on what
I am assuming is a virtual cdrom that is hooked in to the box), that
might make things really easy.

You can also do a tools build for the rescue OS and copy nbdisklabel,
nbinstallboot onto the rescue system and then run them.

You could also set up a disk that is laid out how you want the system to
be, with a smallish (0.5G) root fs as wd0a.  And then in linux download
that and write it to the disk.  So you'd have netbsd bootblocks and no
grub.

You mention grub, but I don't know why that's involved if this is bare
metal, other than that it may be that's all you could write from the
linux installer.

> I have no issue with the MBR.  I have only issues with bootxx_ext2fs versus an mkfs.ext2.

So to understand, you or someone will have to really understand the
ext2fs layout and the theory of how bootxx_ext2fs is supposed to be
placed and how it is supposed to be run and then how /boot is supposed
to be able to read ext2fs.