BTW, I will try to find the culprit (if it is not simply an option not
present in GENERIC...) with the following scheme:
1) I have installed a Linux/Debian, that comes with GRUB2; resized the
Linux partition and installed (with the rescue image, using qemu) a
NetBSD in the second (MBR) partition;
2) GRUB2 ignores flags in the MBR and only boots what is in its menu
found in the Linux root partition. So I have added an entry to chainload
the stage1 block (first block of the NetBSD (MBR) partition)---chainloading
in GRUB does the standard legacy procedure of a classic boot manager in
the MBR: loading the block at the defined address and jumping to its
entry point. This works under qemu, so should work (I could also verify
that stage2 is loaded by having an entry simply rebooting---see below);
3) I use the boot once feature of GRUB2, that is using:
# grub-reboot 2
where 2 is the ordinal (starting from 0) of the NetBSD entry in the
GRUB2 menu. This sets the variable next_entry (in the grubenv file) to
2. When rebooting, GRUB2 will boot the entry 2 but, before booting, will
unset next_entry so that when a reboot happens (a panic and reboot of
NetBSD), the default entry is booted and I will be back under
Linux/Debian.
Then, I will try to bisect the NetBSD kernel using cpu_reboot(). If it
reboots and I have the Linux/Debian system back, it means that NetBSD
is OK so far.
When the system doesn't come back (by rebooting in Linux), I will
know that the problem is "before". Then, having spotted the portion with
the problem, and having the dmesg description of the machine and the
Linux sources too, I will perhaps manage to find what is missing or
failing.