installer fails to boot on x86_64 board

[covacat]

try mfsbsd. that will get you a built it memory rootfs
if you get to shell you may find out more

 

[Keve]

Today I tried booting FreeBSD from the SATA DOM instead of the USB installer.
When connected to my daily-use PC, this SATA DOM was da0. So I did ...

gpart destroy -F da0
dd if=/dev/zero of=/dev/da0 bs=1m count=20
gpart create -s mbr da0
gpart add -t freebsd -i 1 da0
gpart create -s bsd da0s1
gpart add -t freebsd-ufs -i 1 -b 16 da0s1
gpart bootcode -b /boot/mbr da0
gpart set -a active -i 1 da0
gpart bootcode -b /boot/boot da0s1
newfs -Uj -L "FBSDsataDOM" /dev/da0s1a

Then rebooted my daily-use PC off a FreeBSD 13.2R-amd64 USB installer, connected the SATA DOM (through an USB-SATA dongle) with now became da1, and installed FreeBSD to da1 with da1s1a being /. At the end I dropped to a shell and modified /etc/fstab on da1s1a so that it tries to mount root from ada0s1a instead of da1s1a.

On the mini-PC I enabled everything back on in the BIOS, connected the prepared SATA DOM, disconnected all USB peripherals, connected a PS/2 keyboard and gave this a go to see if it now boots FreeBSD to a login prompt. I did stop at the Beastie screen to hit [3], set kern.vty to sc, and try lsdev and ls before entering boot -s. I also took a video recording of the boot process, so that I can slow-motion play that back to see what scrolls through the display. I grabbed still images off the video to show relevant pieces below.

FreeBSD boot still hangs on the mini-PC. Despite now being booted off of the SATA DOM. At the Beastie prompt lsdev and ls does confirm proper disk access. And does so too when I boot off of the USB installer.
Conclusion: UART, USB, AHCI and disklabels are now excluded as possible causes for the failure to completely boot FreeBSD on this mini-PC, and I still don't know what is wrong. Plus I ran out of ideas on what to try, again.

 

[Keve]

 

[Phishfry]

Well carrying the disk to another box was another good attempt.

I am afraid that maybe something with the Via Eden is not compatible with FreeBSD? You have exhausted most avenues.

Old Versions time...I would try 10.4 first. Maybe mfsbsd would give you something..

 

[Phishfry]

Scratching the bottom of the barrel here but VIA Padlock is bothering me.
Note AESNI is trying to use it. Maybe for entropy.
Maybe you can disable AESNI.
boot/loader.conf
aesni_load="NO"

 

[Keve]

ahci devices for disks, and uhci and ehci for usb are displayed, but quickly run out of sight.

 

[Charlie_]

I am afraid that maybe something with the Via Eden is not compatible with FreeBSD?

Eden itself seems to work.

VIA Eden X2 U4200 @ 1.0+ GHz

A database of all the hardware that works under bsd

bsd-hardware.info

HW probe of HP 158Ch (t510 Thin Client) #76fe88223e

A database of all the hardware that works under bsd

bsd-hardware.info

 

[Keve]

And the boot process still freezes exactly where it did before.
What concerns me is that I am pretty sure that I should see a couple of lines in there starting with ada0, but I don't see any. So it is not a big wonder that it chokes on trying to mount root from ada0s1a if it knows no ada0. No line in the scrolling screen output mentioned the SATA DOM being detected.
I have a feeling that something similar happens when I boot off of the USB installer. I should see a da0 line there, and my guess is that there isn't any. So, another screen-recording time.

 

[Keve]

Yep, as I suspected, no da0 line in the screen output of the mini-PC when I boot the USB installer.

If I boot this very same USB installer on my normal daily-use PC, the screen output does include about 4 lines beginning with da0, the second such line even identifying the brand, model, storage capacity of the flash drive.
Similar thing happens when a SATA disk is booted, lines beginning with ada0 are printed, among them one that prints the brand, make, model, capacity.

THESE da0 or ada0 lines are not there in the screen output on the mini-PC. So the disks are visible and accessible from the loader prompt - I believe that is still BIOS supported at that point. But the disks are not visible by the time the system is trying to mount root from them. Which is odd, because the output shows that both USB controllers and AHCI controllers are detected. But not the disks connected to these.

 

[T-Aoki]

So the disks are visible and accessible from the loader prompt - I believe that is still BIOS supported at that point.

Exactly.

But the disks are not visible by the time the system is trying to mount root from them. Which is odd, because the output shows that both USB controllers and AHCI controllers are detected. But not the disks connected to these.

Your screenshot shows multiple controllers both for USB and SATA.
Especially, USB seems to have both uhci (USB1.x) and ehci (USB2.x), but now you have SATA drive to be booted, so put USB aside here.

What happenes if you move the drive to different SATA port which is controlled under another SATA controller? If your miniPC has more SATA controller than displayed (but BIOS knows) and your drive is currently attached to any of ports it controlls, moving to another could help.

And I usually specify partitions by labels in /etc/fstab like
/dev/msdosfs/ESP /boot/efi msdosfs rw 0 0
when I want to mount ESP (uEfi System Partition) labelled as "ESP" on creating partition. For UFS partitions,/dev/ufs/<partition label> should be used. This way, you're not bothered where the drive is connected.

 

[Phishfry]

This way, you're not bothered where the drive is connected.

I want to be bothered. What if you have two sticks installed. Same label?
Blah. Give me raw inputs.

I have to sign off here on this task. Good Luck Keve

If I think of anything I will shout.

One thing kicking in the back of my head is both these devices are dependant on camcontrol and geom.
Have you tried i386 with sc ?

 

[T-Aoki]

What if you have two sticks installed. Same label?

I never assume so, except for something like official installer images and optical medias which I mutually cannot manage.

My previous example of ESP is just an example. I manage EVERY partitions I can manage to have unique partition labels. It is prerequisite.

And this is based on my old and fatal experiences (mostly at early ISA PnP era, though, but happened even on non-PnP ISA era).

Some motherboards and disk (ATA/SCSI/...) controllers could fix the order how the attached drives are recognized. But some wasn't. On worst one (I already forgot its manufacturer and model and don't even want to recall, as it was a nightmare), it was quite racy and shuffled on every boot (I always had to go BIOS setup every reboots to check how driver are recognized. Of course, I purchased different motherboard as soon as possible, with my budget).

This experiences with nightmares made me strongly, strongly and strongy want the very feature that FreeBSD currently have, per-label mounts.
And which geom provider curently has which label can be checked via gpart list.

 

[Phishfry]

Everybody has thier own choices. On devices where name may change I like device.hints with serial number.

I am working on the poudriere image.sh script and device labels make that process much easier. So I see the utility.