Some notes from recent 10.0_RC1 installs

[John Klos <john%klos.com@localhost>]

Hi,

This is meant to share a handful of notes for things that may not warrant 
PRs or messages by themselves.

I did quite a few installs of NetBSD 10.0_RC1 on several amd64 systems 
over the last few days, and, in no particular order:


1) The installation media kernel has nouveau / radeon / whatever Intel
   stuff enabled still, so on a monitor size of 1024x768 (common when you
   keep around a physically small monitor for this kind of thing), sysinst
   still gives a "Screen too narrow" error, similar to this:

http://mail-index.netbsd.org/tech-install/2022/05/29/msg000669.html

With 1024x768, we get a 64 x 24 text screen. Perhaps we need a different 
default font size for this resolution.


2) Making a 12 TB volume with -b 65536 -d 8192 (and a 30 TB volume),
   copying about 8 TB of data on to it, enabling user and group quotas,
   running fsck -fy (several times, just to be sure), then trying to use
   the filesystem led to filesystem related panics, like so:

[  2019.276251] panic: ufsdirhash_findfree: free mismatch
[  2019.345380] cpu0: Begin traceback...
[  2019.389058] vpanic() at netbsd:vpanic+0x17c
[  2019.437935] panic() at netbsd:panic+0x3c
[  2019.487852] ufsdirhash_findfree() at netbsd:ufsdirhash_findfree+0x251
[  2019.566242] ufs_lookup() at netbsd:ufs_lookup+0x5b1
[  2019.616807] VOP_LOOKUP() at netbsd:VOP_LOOKUP+0x39
[  2019.681282] lookup_once() at netbsd:lookup_once+0x1a3
[  2019.736400] namei_tryemulroot.constprop.0() at netbsd:namei_tryemulroot.constprop.0+0x910
[  2019.841435] namei() at netbsd:namei+0x49
[  2019.889272] do_sys_mkdirat.isra.0() at netbsd:do_sys_mkdirat.isra.0+0x18c
[  2019.971429] syscall() at netbsd:syscall+0x1f8
[  2020.026546] --- syscall (number 136) ---
[  2020.074384] netbsd:syscall+0x1f8:

Making the filesystem, enabling quotas, fsck'ing, then copying 8 TB of 
data results in a happy system.

This obviously takes a LOT of time to do, but if anyone wants to look in 
to this, I could try again and give remote access.


3) "consdev=com,0x3f8,9600" in boot.cfg works to provide a serial console
   in UEFI boots, thanks to this fix:

https://releng.netbsd.org/cgi-bin/req-10.cgi?show=361

Perhaps it'd be worth adding an option for serial console, like what 
exists for older boot blocks?


4) UEFI NetBSD shows up in the BIOS menu of various systems as just "UEFI
   OS". Is it possible to have a custom name, perhaps user-configurable,
   so we know which OS we're booting?


5) When using GPT, I observed a huge performance difference between
   aligned and unaligned filesystems. This might be due to drives having
   4K native sectors but emulating 512 byte sectors - I'm not sure - but
   the difference after manually creating GPT slices was very noticeable.
   Perhaps all filesystems should be aligned with -a 4k?

Related to this, specifying a swap size of 65536m (so that swap equals 
memory size) gives a swap size of 134217695 blocks, which is 33 less than 
65536 megabytes. I don't know how much alignment affects swap, but it's 
worth considering. This was with / auto-sized to the rest of the whole 
disk (minus EFI, of course).


6) UEFI booting gives an entropy warning (/var/db/entropy-file exists):

WARNING: couldn't open /var/db/entropy-file
WARNING: 1 module failed to load

Removing rndseed from boot.cfg gives:

[   1.0000000] WARNING: system needs entropy for security; see entropy(7)

I wondered if the bootloader is looking for this on the EFI partition? It 
wouldn't make much sense, but when I copied entropy-file to the EFI 
partition and set "rndseed entropy-file", I got:

WARNING: couldn't open entropy-file (/stand/amd64/10.0/modules/entropy-file/entropy-file.kmod)
WARNING: 1 module failed to load

What's the best way to fix this?


Thanks!
John