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

beans10001

beans10001

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:
forums.freebsd.org

FreeBSD startup freezes after first install

Sorry for my English... I've installed FreeBSD (FreeBSD-12.1-RELEASE-amd64-disc1.iso) on a multiboot PC (Legacy, GPT, sda3). All seems well, only the DHCP confiuration doesn't work. I added some static values, and hope to correct DHCP later. In Grub I added: menuentry "FreeBSD Loader" {...
forums.freebsd.org forums.freebsd.org

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.
 
Ooohhh, it does sound like that. Many thanks. I think I'm reinstalling in legacy mode now... will update again with results.
 
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.
 
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.
 
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.
 
Snurg said:
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.
Click to expand...
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?
 
You must log in or register to reply here.
Back
Top