Bug 195734

Summary:	vt(4) / Newcons causes unbootable system in the absence of a graphics card
Product:	Base System	Reporter:	zurvan.akarana
Component:	kern	Assignee:	Ed Maste <emaste>
Status:	Closed FIXED
Severity:	Affects Only Me	CC:	emaste
Priority:	---	Keywords:	vt
Version:	10.1-RELEASE
Hardware:	amd64
OS:	Any
Bug Depends on:
Bug Blocks:	203349

Description zurvan.akarana 2014-12-06 06:25:34 UTC

CPU: AMD FX-4100
Motherboard: ASUS Sabertooth 990FX R2.0

I have a home server with above specs which I run headless. It does not have integrated graphics and I insert a regular PCI-E graphics card only when the system becomes inaccessible over SSH.

This arrangement has worked fine from 8.0-RELEASE up to and including 10.0-RELEASE.

When I upgraded to 10.1-RELEASE and rebooted the system failed to reach a stage where I could access it over SSH. Inserting a graphics card, however, and viewing the boot process showed no errors.

The system boots from BIOS so by default 'sc' console driver is loaded.

After struggling with various combinations of loader.conf settings I came to the following conclusions:

1. If the system is without a graphics card and boots from BIOS, i.e. loads 'sc' by default, the only way to get past bootloader and successfully boot is to force 'vt' driver with 'kern.vty=vt' and force text mode with 'hw.vga.textmode=1' in loader.conf.

2. If the system has a graphics card and 'kern.vty=vt' is forced but 'hw.vga.textmode=1' is not forced the system boots only when a display is plugged into the graphics card. Otherwise, it waits indefinitely at bootloader stage.

3. If the system has a graphics card, boots from BIOS, is allowed to load the default 'sc' driver it boots fine without a display plugged into the graphics card.

4. If the system has no graphics card, boots from BIOS, and is allowed to proceed with defaults it will not get past bootloader.

For my situation I used conclusion (1), added those two lines to loader.conf. Now I can run the system headless and without a graphics card as I was able to prior to 10.1-RELEASE.

Comment 1 Ed Maste freebsd_committer

2014-12-18 15:41:10 UTC

Sorry for the trouble - I will look into this.

Comment 2 Ed Maste freebsd_committer

2015-11-26 22:11:53 UTC

Is it possible to test an up-to-date -CURRENT snapshot on this system? There have been a number of commits to the VT VGA driver that may have fixed this.

All of my readily-available test hardware has built-in VGA and I haven't been able to test on physical HW, but I have confirmed a snapshot works in QEMU with -vga none. I'll still try to track down a machine w/o VGA to confirm.

Comment 3 zurvan.akarana 2015-11-26 22:33:23 UTC

(In reply to Ed Maste from comment #2)

Thanks for following up on this issue all the time. Unfortunately, the system I listed when reporting the bug performs an important job for me so I cannot afford fiddling with it except in absolute necessity. It will also be a great deal of work to get a display and graphics card over where it is located to test with different loader.conf settings and recover from non-working ones. I apologize for this.

What I can add is loader.conf on that system still contains the two parameters I figured out in the bug report. The system is finely bootable and stable with 10.2-RELEASE.

Comment 4 Ed Maste freebsd_committer

2015-11-27 22:16:58 UTC

> Unfortunately, the system I listed when reporting the bug performs an important
> job for me so I cannot afford fiddling with it except in absolute necessity.

Understood. I believe this issue is fixed, but will leave this ticket open until someone can confirm.

Comment 5 Ed Maste freebsd_committer

2016-06-13 15:15:52 UTC

I believe this is fixed. Please reopen if not.