Re: Disabling framebuffer at boot time

[tlaronde%polynum.com@localhost]

Le Thu, Aug 18, 2022 at 07:52:14PM +0000, RVP a écrit :
> On Thu, 18 Aug 2022, tlaronde%polynum.com@localhost wrote:
> 
> > But the NetBSD kernel does not even crash (since I use the "boot once"
> > feature,
> > 
> 
> 1. Can you post the dmesg from Linux?

You will find it at:

http://downloads.kergis.com/misc/rpt.dmesg

BTW, I'm realizing now that I have taken the GENERIC kernel (the server
has not a lot of devices and is 10 years old, with a "classic" Intel
Gb ethernet card) but I have not verified if GENERIC has activated
or not some Ivy bridge options. I will start by building a custom
kernel reviewing the config.

> 
> 2. Does `boot -1' (disable multiprocessor) or `boot -2' (disable ACPI)
>    get you a working system?
> 
> 3. Can the support staff connect a monitor to the machine and take a
>    movie/picture of the screen?

It's a first entry level proposal. (Background: my ISP has switched,
without any previous notice, my connection to IPv6-CGNAT and I then lost
my IPv4 address, while I administer GIS KerGIS servers remotely, on
private network I have no hand on and, hence, make them callback to my
IPv4 address; so I needed in emergency just an IPv4 address and manage
to configure Linux/Debian to restore my needs; I don't use at the moment
the server for something else.)

So asking for connecting a screen is not possible (there are other
proposal with IPMI, allowing you to follow see the booting process with
your web account utils).

Once I have build a custom kernel, I will set boot.cfg in order to test
also disabling multiprocessor and acpi.

For your other question:

> Could it be that NetBSD has panicked because there's no console on
your
>server? Ie. no physical keyboard and nothing connected to the serial
>port. Headless servers usually have a serial port console, right?

I doubt there could be a problem. I have installed NetBSD on headless,
no keyboard node (but I do not remember if all had at least a serial
line on the motherboard even if there was no physical socket on the box
or not), and there was no problem.


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.

Best,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                    http://kertex.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C