cannot run latest FreeBSD on a 15 year old PC

C

cyranno

The specifications of the PC can be found here; it's an amd64 motherboard. I did install FreeBSD on it successfully many years ago, version 12 or 13, I don't remember exactly. I decided to revive it by installing the latest version, 15.1. The installation goes well but after rebooting when the installation has completed I see message Loaded only 545k in a loop on the screen. I tried installing version 14.5 but the result is the same.

Please let me know if you want me to provide more detailed information on the hardware, for example the output of program dmidecode that I can run from a Linux installation flash drive.

Thanks in advance.
 
this looks like an error from the pmbr code from the gpt boot. how large is your freebsd-boot partition (you can reboot the installer and inspect)
also did the installer booted gpt or efi ?
 
covacat said:
this looks like an error from the pmbr code from the gpt boot. how large is your freebsd-boot partition (you can reboot the installer and inspect)
also did the installer booted gpt or efi ?
Click to expand...
The error is in /usr/src/stand/i386/pmbr/pmbr.S. Literally, including the 545K boundary of something.That must cause it but the lines containing 545 don't explain a lot to me. What stops loading and fills up reserved space on a 32-bit system?
 
MG said:
That must cause it but the lines containing 545 don't explain a lot to me. What stops loading and fills up reserved space on a 32-bit system?
Click to expand...
As far as I know, it's a BIOS limitation. It simply cannot be bigger, the installer creates a 512K partition for freebsd-boot due to this limitation.
 
covacat said:
try to shrink the partition with gpart from the installer live cd or shell. 512 KB will do
Click to expand...
A how-to for this (replace md0 with ada0 in your case):

Code: 
root@freebsd:~ # gpart show md0
=>     40  2097072  md0  GPT  (1G)
       40   131072    1  freebsd-boot  (64M)
   131112  1966000       - free -  (960M)

root@freebsd:~ # gpart resize -i 1 -s 512k md0
md0p1 resized
root@freebsd:~ # gpart show md0
=>     40  2097072  md0  GPT  (1G)
       40     1024    1  freebsd-boot  (512K)
     1064  2096048       - free -  (1023M)

But I don't know if the bootcode needs to be reinstalled after the resize.
 
covacat said:
try to shrink the partition with gpart from the installer live cd or shell. 512 KB will do
Click to expand...
I've kept 1MiB when I've last used legacy BIOS boot.

Yes, it's overkill, but as far as I've experienced, recent drives generats unusable gaps between partitions if partitions are NOT aligned with 1MiB boundary. And gpt{zfs}boot is allowed to be 545KiB as you've noted (possbily used for new read-incompatible ZFS feature supports in the future).

And pmbr reads upto whichever smaller of 545KiB or freebsd-boot partition size on GPT scheme, and mbr (boot0) reads upto 545KiB from slice boot record (aka partition boot record) for MBR scheme if I understand the code precisely.

In both cases, simply reads into specific address of conventional memory area and jumps to specific address for execution (possibly move first, as I'm not re-reading the source now).
 
nxjoseph@ said:
But I don't know if the bootcode needs to be reinstalled after the resize.
Click to expand...
Basically, no need to reinstall bootcode on resize (shrink) to 512KiB for current boot code sizes at least on spinning rusts.
gpart bootcode -p simply "dumps" specified bootcode (partcode) file into specified partition. And pmbr just read the partition from its start as "memory image starting from specific conventional memory address".

But to be paranoid, reinstalling would be preferred for spinning rusts, as recorded data could be "demagnetized" as time goes by, so reinstalling for reinforcing recorded data sometime helps.
 
T-Aoki said:
The leftmost numbers are in 512 bytes sectors. Leftmost one is start position (from the very first sector that mbr / pmbr exists) and the next one is the end position. So your freebsd-boot partition is "approx" 64MiB (minus 20Kib), which is clearly overkill.
Click to expand...
I agree but could it be causing the issue I'm having?
 
well, if i understand the code correctly it should not per se. but if the bios keeps some data somewhere in the ram which is overwritten because the partition is to large it might.
didal says it works for him, so the stuff that gets overwritten is just between 512k-545k (it could be)
the code reads the partition sector by sector starting with 0x7c00 address. everything that would get past 0x90000 is read at 0x90000-0x200.
 
You must log in or register to reply here.
Back
Top