Re: mips64eb seems to be mostly 32-bit

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

On Sun, 4 Jul 2021 07:39:36 +0200
Martin Husemann <martin%duskware.de@localhost> wrote:

> On Sun, Jul 04, 2021 at 03:26:53AM +0100, Denis Ovsienko wrote:
> > * The installer segfaults if you create a NetBSD MBR partition and
> > then edit it and enable both "install" and "active". (I do not use
> > the pre-built root filesystem image because it is partitioned such
> > that the root filesystem is on "dk1", and the kernel by default
> > expects it to be on "sd0a". This bug is not a mipsn64eb regression
> > because mips64eb has it wrong in the first place.)  
> 
> I'll look at the first issue (like mathew I have not looked at the
> n64 builds at all so far).
> 
> I don't understand the dk1 vs sd0a issue - can you describe that in
> more details? Especially I don't understand what you mean by the
> kernel "expecting" it "to be on sd0a".

Thank you.

For clarity, the root device name issue happens with both n32 and n64.
The n64-specific thing is that the installer segfaults on a non-critical
interaction (setting the NetBSD MBR partition as "install" only does
not trigger the segfault on n64).

Now regarding the dk1/sd0a issue. For example, if you write [1] or [2]
to an SD card and try to boot from it, the boot process will stop at a
prompt:

[   3.1199641] sd0: fabricating a geometry
[   3.1199641] sd0: 7464 MB, 7464 cyl, 64 head, 32 sec, 512 bytes/sect x 15286272 sectors
[   3.1310549] sd0: fabricating a geometry
[   3.1430380] dk0 at sd0: "octeon-boot", 163840 blocks at 32768, type: ntfs
[   3.1538992] dk1 at sd0: "octeon-root", 761856 blocks at 196608, type: ffs
[   3.1606850] WARNING: 1 error while detecting hardware; check system log.
[   3.1606850] boot device: sd0
[   3.1708506] root on sd0a dumps on sd0b
[   3.1708506] vfs_mountroot: can't open root device
[   3.1817997] cannot mount root, error = 16
[   3.1817997] root device (default sd0a): 

If you manually point the kernel to the right block device, the boot
will continue:

[   3.1817997] root device (default sd0a): dk1
[   4.7655787] dump device: <Enter>
[   5.0455172] file system (default generic): <Enter>
[   5.4775712] root on dk1
[   5.4775712] root file system type: ffs
[   5.4911243] kern.module.path=/stand/evbmips/9.99.86/modules
[   5.4990382] WARNING: no TOD clock present
[   5.4990382] WARNING: using filesystem time
[   5.5070929] WARNING: CHECK AND RESET THE DATE!
[   5.5175828] init path (default /sbin/init): <Enter>
[   6.0695715] init: trying /sbin/init
Sat Jul  3 18:12:50 UTC 2021
Starting root file system check:
/dev/rdk1: file system is clean; not checking
gpt: /dev/rsd0: No valid PMBR partition found
[   8.3495591] dk0 at sd0 (octeon-boot) deleted
[   8.3620308] dk0 at sd0: "octeon-boot", 163840 blocks at 32768, type: ntfs
[   8.3713088] dk1 at sd0: "octeon-root", 15081472 blocks at 196608, type: ffs
/dev/rsd0: Partition 2 resized: 196608 15081472
Resizing / (NAME=octeon-root)

(As a side note, during this test mips64eb had hung 15% into resizing,
and mipsn64eb managed to complete it fine. Might be the serial console
bug.)

An easy way to work around this mismatch is to pre-initialize the SD
card with an MBR partition table before the installation. This way the
installer does not go into the GPT/wedge space and the root filesystem
device ends up where the pre-compiled kernel is expecting it
(/dev/sd0a).

1:
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202107031340Z/evbmips-mips64eb/binary/gzimg/octeon.img.gz
2:
http://nycdn.netbsd.org/pub/NetBSD-daily/HEAD/202107031340Z/evbmips-mipsn64eb/binary/gzimg/octeon.img.gz

-- 
    Denis Ovsienko