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?
 
When attempting to install FreeBSD or GhostBSD on a desktop system equipped with an AMD Ryzen 9 9900X, Gigabyte B850 EAGLE WIFI6E motherboard, and 32 GB of DDR5 RAM, the installer freezes after displaying pixel format mask errors related to 0x00ff0000, 0x0000ff00, 0x000000ff, and 0xff000000. Attempts to work around the freeze by switching to Legacy Boot, enabling CSM (Compatibility Support Module), and disabling integrated graphics have been unsuccessful.

The system uses a modern AM5 platform with UEFI firmware (AMI F8), which may lack full FreeBSD driver support for its chipset or framebuffer subsystem at this time. That's what I'm thinking. Any ideas?

- System: AMD Ryzen 9 9900X (12-core, up to 5.6 GHz), 32 GB DDR5 @ 4800 MT/s (2x16 GB), Gigabyte B850 EAGLE WIFI6E (UEFI AMI F8).
 
try serial console with this in loader.conf:
Code: 
console=comconsole

On our platform we have to specify other options to make it use the correct (COM2 in DOS terms) port:
Code: 
comconsole_speed=115200
comconsole_port=0x2f8
hint.uart.0.flags=0
hint.uart.1.flags=0x10
console=comconsole
 
You must log in or register to reply here.
Back
Top