Won't boot: masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

beans10001

New Member

Reaction score: 3
Messages: 11

I decided to reinstall one of my FreeBSD systems this morning. I downloaded the 12.2-RELEASE installer (memstick), copied it to a USB drive and then tried to boot from it. That's where the problems began...

In general, this sounds very similar to the following thread but I'm not seeing the 'Can't find /etc/hostid' line that they mentioned:

Starting up I see the "Welcome to FreeBSD" screen, wait for it to timeout and then continue booting up. But things stop at the line "masks" with some hex values (the following was transcribed so hopefully no typos):

Code:
EFI framebuffer information:
addr, size    0xd0000000, 0x3ff0000
dimensions    800 x 600
stride    800
masks    0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000

It'll either sit there forever or it will reboot and then fail again (and then start looping).

Not sure why but after a number of restarts I AM occasionally able to boot from the USB installer and then proceed with installation. But restarting from the freshly installed system does the same thing, I'm stuck at the "masks" line again.

Similarly, after a number of reboots it DID eventually boot to the freshly installed OS and I was able to start configuring and installing more some packages. But restarting isn't reliable, most of the time it'll get stuck again on startup and only occasionally it'll go ahead and boot up.

I see the same behavior when I try to boot from the 12.1-RELEASE or even the 11.4-RELEASE memsticks as well.

Ideas? The system was starting up just fine with 12.2 before I tried a fresh install this morning and now it's very unreliable.
 
OP
beans10001

beans10001

New Member

Reaction score: 3
Messages: 11

Ooohhh, it does sound like that. Many thanks. I think I'm reinstalling in legacy mode now... will update again with results.
 
OP
beans10001

beans10001

New Member

Reaction score: 3
Messages: 11

Yup, that seems to have done it. The system is booting reliably now, thanks again!
 

Snurg

Daemon

Reaction score: 577
Messages: 1,349

I wonder what is the reason why vt was made obligatory, at the cost of potentially making FreeBSD unusable on computers that do no longer have a CSM/BIOS mode.

I do not believe that it would be difficult to just change video mode to text, to use sc, completely avoiding the hassles with that horridly bugged vt.

If there is no actual blocking reason I have missed, I guess the first thing I'll do as soon I get my first UEFI mobo will be to insert such a video mode change as very first action of the kernel bootstrap and add an option in the bootloader to choose sc instead of vt.
 

vigole

Daemon

Reaction score: 1,182
Messages: 1,098

In sc(4) days, we had problem/error with changing mode/resolution.
vt(4) solved that problems. But I still use it in few places, e.g. inside virtual machine.
 

Snurg

Daemon

Reaction score: 577
Messages: 1,349

Yes, I observed all that.
The graphics mode of sc was never more than experimental, as far as I can see.
I guess it is some thing "ahh graphics mode console is fancy and shiny, we must have such thing, because Linux has, too".

I watched how vt was hyped for years and finally pushed through, while (for unknown, but guessable reasons) not making that simple change necessary for booting UEFI with sc.

The issues vt had/has are severe, and these many PRs open since vt has been made non-optional, which apparently nobody can/wants to fix, suggest that the vt code base is possibly/potentially botched beyond repair.

I feel at loss why apparently nobody had the idea of having vt not to hang, but just switch to text mode if it cannot find a matching graphics mode. This would at least allow FreeBSD to run on UEFI machines without CSM/BIOS boot.
 

jardows

Member

Reaction score: 47
Messages: 90

Yes, I observed all that.
The graphics mode of sc was never more than experimental, as far as I can see.
I guess it is some thing "ahh graphics mode console is fancy and shiny, we must have such thing, because Linux has, too".

I watched how vt was hyped for years and finally pushed through, while (for unknown, but guessable reasons) not making that simple change necessary for booting UEFI with sc.

The issues vt had/has are severe, and these many PRs open since vt has been made non-optional, which apparently nobody can/wants to fix, suggest that the vt code base is possibly/potentially botched beyond repair.

I feel at loss why apparently nobody had the idea of having vt not to hang, but just switch to text mode if it cannot find a matching graphics mode. This would at least allow FreeBSD to run on UEFI machines without CSM/BIOS boot.
My question then becomes, for a text-only environment, can I use sc at all in a UEFI environment? I know in some previous versions it you could switch, but is it vt only for 13.0?
 
Top