Sorry, not Warner. ;-) On Wed, 17 Sep 2025 12:56:11 +0200 "Peter 'PMc' Much" <p...@citylink.dinoex.sub.org> wrote:
> Dear Warner, > > after upgrading my desktop 13.5 to 14.3, it suddenly stared at me > with ascii-art, and in single-user with a horrifying 80x25 resolution. > > I started to experiment. I need a proper resolution to at least get a > chance to read what the kernel tells me when booting (the mixup in > log/messages and log/console is usually not intellegible). > > The functionality of the graphics options in loader.conf has always > stayed obscure to me. Between options like "kern.vt.fb.modes.HDMI-A-1" > or "vbe_max_resolution", which are hardware dependent and frequently > change, and multiple different monitors that cannot be switched off > (because even when unplugged from mains, they still babble to the > system), it is really a matter of luck to get to something useful. > > So, in short, when graphics didn't appear, I started to search for my > own mistake. That it could have been turned off deliberately, was > unimaginable to me. > > Only when I finally gave up that approach, and started the radical > way, install six clean new systems for analysis (13.5 and 14.3 > each with MBR, GPT and EFI), I noticed that EFI would work in 14.3 > (the machine is old, I didn't know it could even do EFI). > > Then I started to read the published documentation, very thoroughly, > to finally find a small kind of sidenote that *might*, with some > understanding, be interpreted as a change in the singleuser hi-res. > It still didn't tell people what to do about it, but instead send > them on a paper chase into the source configuration, solveable > only for those already used to build from source. > > I don't know how long it took me to read all the stuff, but I do know > that I started to put 14.3 onto the desktop around 2300, and it was > 0600 when completing the hunt. > This is not acceptable. > > I would have expected a prominent notice in the release notes (that > is, in each of them, not only in a single minor release), like so: > > "Single-user graphics have been removed from loader. If you > have a graphics screen and still want to read your kernel messages > on-screen, do this-and-that..." > > And *AT LEAST* I would have expected an elaboratory notice in UPGRADING. > > Cheers, > PMc Putting other than boot time graphics mode aside. In short, use UEFI if you want graphical beastie. In detail, legacy (BIOS) bootcodes are tooo restrictive in size. This is because bootcodes in legacy boots are running on "real mode", only 1MB of address space including mapped ROM, memory mapped I/O and any other reserved area, thus, around 540kB is available. This is too small to support everything UEFI bootcode (currently, loader.efi itself by default, and before, boot1.efi), which runs on 64 (or in rare cases, 32) bit address space. So to add (back) anything, something equivalent in size SHALL be removed instead. IMHO, if graphics mode in legacy boot is MANDATORY for most of users, disallowing Root-on-ZFS boot on legacy BIOS would be the candidate. Who wants it? So such an angers should go to Intel, as Intel didn't decided to make 32bit address space at the first place on 8086/8088. (In 8bit era, IIUC/IIRC, many CPUs supported address bus width doubled with data bus, 16bit.) And yes, differences in configurations for vt between backend is a pain. But I think it comes from the differences of the mechanism that each backends (various different framebuffers) uses. If UEFI forcibly designates per-resolution/depth modes to be fixed number as mandatory spec, I think things would be much cleaner and simpler. Maybe for VGA, VESA (both for legacy BIOS) and whole UEFI. Maybe refactoring to integrate configs would be complexed. Regards. -- Tomoaki AOKI <junch...@dec.sakura.ne.jp>
