Booting freezes at EFI FrameBuffer

Rand0m

Rand0m

Hi there,
(not sure if this is the right category)
I have freeBSD 13.2 and was applying the latest security patches to the system. And when I tried to boot afterwards, the system hangs , forever, at the EFI framebuffer. It does the same with single user mode.

I tested the SSD and memory using the booting tools and both seem fine.

I wonder what that would be and what possibly I can do to fix it.

Thanks

Please check the photo below
 
Adding images of the booting screen
 

Attachments

  • IMG_8433.jpeg
    IMG_8433.jpeg
    827.8 KB · Views: 118
It is HP Prodesk v3e69pc#abg
- Intel core i7 6700
- SSD Samsung 870 EVO
- Basic Nvidia

Sorry the computer doesn’t start so I can’t get the detailed hardware for you. But it’s been running freebsd for 4/5 years without a problem.
 
It doesn't hang. It's just not showing anything on the console, I'm betting the console has been redirected to the serial port. I'm also betting you can login remotely (if you have sshd enabled). On the loader menu check if "5. Cons" is actually set to "Video".
 
SirDice said:
It doesn't hang. It's just not showing anything on the console, I'm betting the console has been redirected to the serial port. I'm also betting you can login remotely (if you have sshd enabled). On the loader menu check if "5. Cons" is actually set to "Video".
Click to expand...
Yes 5 is set to video. Should I change it to serial?

Couldn’t ssh to it though
 

Attachments

  • IMG_8436.jpeg
    IMG_8436.jpeg
    438.4 KB · Views: 68
No, it should be set to Video. I have a few mainboards that don't expose a ConOut or ConOutDev in EFI. Which results in the kernel not booting on the 'video' console, even though there's a working videocard. Quite annoying.
 
SirDice said:
No, it should be set to Video. I have a few mainboards that don't expose a ConOut or ConOutDev in EFI. Which results in the kernel not booting on the 'video' console, even though there's a working videocard. Quite annoying.
Click to expand...
But this been working fine till today when I installed the security updates :-(
Is there anything I can run from option 3 loader prompt to help diagnose the problem?
 
Do you recall if you are loading nvidia kmods from rc.conf or from loader.conf?
I'm going by fuzzy memory but I think there was a thread or two having issues with loading nvidia kmod from loader.conf when booting EFI, root cause was related to a size somewhere.
Have you tried to boot to single user mode?
 
mer said:
Do you recall if you are loading nvidia kmods from rc.conf or from loader.conf?
I'm going by fuzzy memory but I think there was a thread or two having issues with loading nvidia kmod from loader.conf when booting EFI, root cause was related to a size somewhere.
Have you tried to boot to single user mode?
Click to expand...
Yes Nvidia is being loaded in both
rc.conf
Code: 
kld_list="nvidia-modeset ext2fs"

and in /boot/loader.conf
Code: 
# Nvidia GPU
nvidia_load="YES"
nvidia-modeset_load="YES"

Yes, I did single user option but got the same issue
 
Rand0m said:
Adding images of the booting screen
Click to expand...
What's going on with all the snd_ modules being loaded ?

For test purposes can you just boot it manually ? Enter boot prompt (press option 3) and do:
Code: 
unload all
load /boot/kernel/kernel
boot
to see if you get further into the boot.
 
Managed to boot it by choosing the “F4” option from the attached screenshot. I’m not sure what is this option. It worked for now but I still would like to understand what is this and what I can do to get working normally like it used to.

I don't think this CIRA option is correct but for some reason the system boots!
 

Attachments

  • IMG_8437.jpeg
    IMG_8437.jpeg
    817.5 KB · Views: 166
Here is some reading material from Klara Systems related to Rescue Booting. Martin in post #15 gave you a great answer and is also listed here in this Klara Systems article:
https://klarasystems.com/articles/manipulating-a-pool-from-the-rescue-system/
https://klarasystems.com/articles/tag/boot/
https://klarasystems.com/articles/the-freebsd-boot-process/

Hope this helps you. I am booting from a USB flash drive image for Raspberry Pi 4B. I had to mount my ZFS file system on a 1 TB sata SSD. Then chroot into that 1TB,
chroot /mnt/arm64zfs /bin/sh
mount -t devfs dev /mnt/arm64zfs/dev Mount the devfs file system to inside the chroot mount point, for the /dev/null function used by make buildworld. Now to reinstall the kernel with make installkernel
https://klarasystems.com/articles/building-customized-freebsd-images/ Here is document I am reading
 
SirDice said:
No, it should be set to Video. I have a few mainboards that don't expose a ConOut or ConOutDev in EFI. Which results in the kernel not booting on the 'video' console, even though there's a working videocard. Quite annoying.
Click to expand...
It's interesting that even though the firmwares of those motherboards don't set ConOut or ConOutDev variables, code such as SystemTable->ConOut->OutputString(SystemTable->ConOut, L"hi"); executes just fine in EFI programs running on computers with those motherboards... Anyway, nowadays, the FreeBSD EFI loader is capable of relying on ConIn for the proper detection of the Video console, so the previous issues seem to have been gone.
 
Oleg_NYC said:
It's interesting that even though the firmwares of those motherboards don't set ConOut or ConOutDev variables, code such as SystemTable->ConOut->OutputString(SystemTable->ConOut, L"hi"); executes just fine in EFI programs running on computers with those motherboards... Anyway, nowadays, the FreeBSD EFI loader is capable of relying on ConIn for the proper detection of the Video console, so the previous issues seem to have been gone.
Click to expand...
Recently, fix for loader.efi that use ConIn if ConOut is not available.
It is MFC'ed to stable/14, stable/13 but not yet MFS'ed to 13.2 and upcoming 13.3.
 
You must log in or register to reply here.
Back
Top