Re: MBR table looks strange after the installation

[Denis Ovsienko <denis%ovsienko.info@localhost>]

On Mon, 5 Jul 2021 06:21:47 +0200
Martin Husemann <martin%duskware.de@localhost> wrote:

> On Sun, Jul 04, 2021 at 06:32:43PM +0100, Denis Ovsienko wrote:
> > The installer sees the MBR table, it creates a NetBSD (type 0xa9)
> > partition just after the FAT partition and even copies the FAT MBR
> > partition into the NetBSD disklabel automatically:  
> 
> The installer is confused about the boot disk being partitioned with
> MBR (as required on this platform) on a port (mips) where we do not
> usually wrap disklabel-inside-MBR (like x86, where the 'c' partition
> is used for the MBR NetBSD partition of the disk and 'd' is the
> raw/whole disk partition).
> 
> We have similar issues on arm platforms, but special code to deal
> with it there.
> 
> I'll have a look (don't have an easily testable mipsn64 setup right
> now, so will take a bit).

Thank you for your comments Martin.

If it helps, the problem reproduces with both mips64eb and mipsn64eb.
Feel free to move this discussion to port-mips@ if you think it belongs
there. Meanwhile let me try to explain the problem space better, at
least from the end user point of view.

The main reason why I use manual MBR partitioning in the first place is
because the default (GPT) partitioning does not work with the default
kernel, as already discussed elsewhere. I do not see practicable means
to change the kernel root device, but I see practicable means to
produce a disk that boots without user interaction. Other than that,
GPT would be workable in my use case: both devices at hand (E100 and
E300) have GPT support in u-boot and can load and start the kernel from
gzimg/octeon.img.gz expanded onto a USB disk. The root device name is
one issue.

The use of manual MBR partitioning made another issue easier to see.
Since the installer recognizes MBR partitioning and allows to edit and
to use it to complete the installation, it would be reasonable to expect
the final MBR partition table to be exactly as configured in the
process. The current behaviour is different. It seems to me, the most
useful way to eliminate this difference would be to fix MBR
partitioning support rather than to switch to GPT completely.

Let me know in case you need any additional input, diagnostics or
testing -- I would be glad to help as much as I can.

-- 
    Denis Ovsienko