Re: What made You think You could just kill graphics in singleuser

On Wed, Sep 17, 2025 at 10:25:26PM +0900, Tomoaki AOKI wrote:

! Putting other than boot time graphics mode aside.
! 
! In short, use UEFI if you want graphical beastie.

I don't need beastie (I like it, but dont need it).
What I *do* need is some 60-90 lines of text in single-user.

So, if this has worked before (and I formerly went to some lengths
to  make it work, because there are three monitors of different size
attached, and it should then cleanly switch over to i915kms, and
then again switch to X), and now it doesn't anymore, that is
certainly worth noting.

Then when I finally figure that this is not my own derived configuration
falling apart in the new release due to some mistake of mine. No,
it is something that was done deliberately, but seemingly was kept under
the carpet.

! 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?

I don't know. I don't use Root-on-ZFS (on dependables, for safety
reasons).

! 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.)

That is not the point, I build all from source, always, so I have
no issue whatsoever with adjusting things to my need.
(But that works only after I come to know that there is a need.)
 
! 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.

I think the problem is that I just never managed to study it in-depth.
Graphical desktops are not my favourite plaything; I like servers. But
I have to make my desktop machine working, and I'm happy if it comes
up on at least two monitors with a proper resolution.

My point is, specifically in such matters where one isn't even sure if
one is doing it correctly, it is the more imperative that others who
change the behaviour, do vocally pronounce that they did so.

I have no issue with a decision made one way or another, as long
as somebody tells that something was decided and *that* I possibly
have to remedy for it. Would be even better if they tell me *how* to
remedy (but that is optional).

! 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.

I understand UEFI even less. (Sadly, I do more and more fail to
develop a full understanding of every component of the environment.)
So with UEFI, I'm still just happy when I don't need to use it. 

Cheerio,
PMc