Monitor goes black at time of passphrase and boot options during boot

micski

micski

When starting an older physical machine with an absolute clean install of FreeBSD 12.1 with encryption and ZFS, then the BIOS RAM test is initially shown on the VGA monitor, but then the monitor goes black and nothings happens, when the encryption passphrase prompt should appear. If I enter the encryption passphrase blind and press Enter, then some times passes and the rest of the boot process is shown on the monitor. If I switch to an older VGA monitor, then that monitor does not go black. What could be causing this issue?
 
Incompatibility between monitor frequency and operating system. I have the same with my small BSD server at home: when the BIOS boots, the monitor works, but the moment FreeBSD starts, the monitor turns black. The fix is trivial for me: power-cycle the monitor.
 
  1. Press the "Auto"-Button on the monitor to auto-adjust it's signal timings... ;)
  2. Do not use a analog VGA cable, but a digital one (e.g. whatever<->DVI) instead
    -- but not a VGA to digital converter; it should be a digital protocol at both ends of the cable.
  3. You could try to user the old syscons(4) system console (new default is vt(4)).
    In /etc/boot/loader.conf: kern.vty="sc"
  4. Alternatively, have a look at RTFM vt(4) and try the behaviour with hw.vga.textmode="1"
    and/or kern.vt.fb.default_mode="800x600"
 
Thanks for these interesting suggestions. I tested the power-cycle solution, but it was not succesful. The old machine, a 2009 HP server, has its VGA output connected via an digital converter to the HDMI input on a modern high resolution monitor. I also tested the text mode solution. That was unfortunately worse, because this method kept the monitor black. I am curiuos about switching the system console from vt to sc. Is there a risc, that the server can not display anything at all on any kind of monitor, if this switch for some reason fails? There is none of the well known old font configurations for the sc console by default in FreeBSD 12.1.
 
micski said:
[...], has its VGA output connected via an digital converter to the HDMI input on a modern high resolution monitor. I also tested the text mode solution. That was unfortunately worse, because this method kept the monitor black. I am curiuos about switching the system console from vt to sc. Is there a risc, that the server can not display anything at all on any kind of monitor, if this switch for some reason fails? There is none of the well known old font configurations for the sc console by default in FreeBSD 12.1.
Click to expand...
  • The digital converter is a possible source of (nasty) failures. If the machine has any modern graphics output plug, it's much safer to use that instead. Invest the 20 $/€, it's worth it -- I had such a problem a few days ago, a new cable solved it.
  • try kern.vt.fb.default_mode="640x480" in /boot/loader.conf
  • I do not see any risk by switching to the old syscons(4). It can not use UTF-8 fonts though, but there's a project on that in the source tree. RTFM build(7), make.conf(5) & src.conf(5) and /usr/src/sys/{arch/}conf/NOTES
  • The BIOS screen is shown at boot, so oviously the graphics card works. It must be some software or (physical) problem of the cable/converter. I suspect that the console driver detects the superior capabilities of the monitor (that's possible via a VGA cable -- even if the monitor is "switched off"), enables them, but these settings drive out the physical specs of the cable or converter. These are among the few devices that can not "talk" to the drivers.
  • $ ls /usr/share/syscons/fonts If that's empty, s/th went wrong with your installation.
 
Is the /boot/loader.conf settings read and executed before, at or after the time of encryption passphrase and boot options menu? From a security stand point I would assume, that those settings can not be read before the correct encryption passphrase has been given. If that is true, I would assume, that the change in VGA output signal is caused by other software in a pre-boot cycle.
 
Thanks for your detailed insight, #6. Unfortunately there is no other outputs, than VGA and a serial interface. I am using new cables on the HDMI part of the cables and the VGA part of the cables works fine with another VGA monitor. I would agree, that the problem here is a combination of software and the digital converter. I will test the VGA resolution.
 
micski said:
Is the /boot/loader.conf settings read and executed before, at or after the time of encryption passphrase and boot options menu? From a security stand point I would assume, that those settings can not be read before the correct encryption passphrase has been given. [...]
Click to expand...
If I got it right, /boot/loader.conf is read after /boot/boot1
(RTFM boot(8) -- there's a 3 sec delay after your BIOS boot screen) and before you see the FreeBSD boot menu, which is presented by the loader. You can verify that by choosing the boot console from the menu, and list the variables

?
[short help]
set
[listing of variables and their setting]

and you can see all the variables from /boot/loader.conf and /boot/device.hints
I do not know about the handling of GELI passwd, but I think that w/o the right pw the geom(4) device /dev/ada0p3.geli (or such) does not exist. If your system can run w/o that, all is fine (e.g., only your /home/micski is encrypted)
 
Thanks again, #8. I had no luck on the VGA resolution. The VGA output comes from the onboard graphics of an old HP Proliant server. I could probably insert a PCIe x8 VGA adapter, but those are hard to find these days. It looks like we will have to conclude, that using a VGA to HDMI converter does not work during the boot process. Only a guy with an oscilloscope can tell us, what happens with the output signal during that time. Until then the only solutions is probably, that the VGA output is used with a VGA monitor, or, that the serial interface is used.
 
  1. I have to admit that I was partly wrong about geli(8) encrypted geom(4) devices.
    It affects the ZFS pool, not individual data sets.
    I do not know if it's possible to read kernel dumps written to an encrypted swap that is encrypted w/ a one-time-pw/key. I guess it's not possible, but there might be some tweaks.
  2. Using the serial console provides a real old-school data-center feeling ;)
    You can "shoot" a serial KVM switch at "the bay" or such, should be very cheap since they're not used anymore. I did that 15 years ago for 5€ incl. shipment costs to run a SUN E-4500. See topic #5!
  3. If your server is not too old, there might be a BIOS setting to allow redirecting console output to a network interface. I.e. the server has a network interface reserved for service/maintenance and the others are for data. Then you setup a VLAN for service/maintenance in your switch.
  4. All this violates the KISS principle.
  5. Are you shure you want to run that old machine?
    The running costs for electricity - after about 6 month - will allow you to buy a 5 year old used mini-PC/server, which will outperform your Proliant at much lower running costs (and noise).
 
micski said:
Thanks again, #8. I had no luck on the VGA resolution. The VGA output comes from the onboard graphics of an old HP Proliant server.[...]
Click to expand...
Occasionally, I stumbled over this vt(4) loader(8)-knob. Buggy ACPI implementations in the BIOS are very common, so you could try setting it to 1 in /boot/loader.conf
hw.vga.acpi_ignore_no_vga
Set to 1 to force the usage of the VGA driver regardless of whether ACPI IAPC_BOOT_ARCH signals no VGA support. Can be used to workaround firmware bugs in the ACPI tables.​
 
You must log in or register to reply here.
Back
Top