Installing onto a predefined disk configuration (slice/partitions)

Having been away from FBSD since 2.1R (NBSD being my home for the intervening decade+), I thought it would be a good time to see how FBSD has evolved. Having one FBSD box would also save me the trouble of porting some applications to NBSD. I rescued a small server (6 core Xeon, 8x1TB, 256G RAM) to host the system.

My intention was to mimic the same disk layout as my NBSD boxes -- MBR (yes, it MUST be MBR and not GPT) with a BSD labeled slice. But, FBSD's disklabel() doesn't support more than 8 partitions (I have previously reported that bug).

Dropping into a shell, I convinced gpart() to let me mimic the layout by sneakerneting it from a NBSD host after previously wiping the first ~GB of the target drive..

But, no matter how I try to coax the installer to accept my layout, I can't get a bootable system. If I let it do the work, the system boots but ends up with a whopping huge 1TB partition and a tiny swap. Because the installer hides its actions (hint: why not route a copy of stdout and stderr to vty1?), I can't figure out what it is doing in one case (Auto layout) and NOT doing in the other (Manual).

[And, the installer has a bug that effectively means each failure requires a reboot (hint: try to RESTART after a failure in the file extraction and watch the dialogs carefully!). Also, the slice/size and mountpoint columns in the partition editor don't line up because the width of the "size" column isn't "fixed".]

Is there a trick to getting the installer to "take my word for it" and still have it install the various boot loader stages? (i.e., is this another bug?)

[And why is hw.mfi.mrsas_enable set to 0, by default? Should I be wary of that driver?]
 

Attachments

Install media (DVD iso) present on USB thumb drive.
H730 (mini) in HBA mode, drive 0 as boot device

A blow by blow of my process (hopefully I haven't missed any pertinent notes):

Powerup machine
Enter "Boot Manager" (F11)
Select "One time boot manager"
Select USB thumb drive

Interrupt boot process (option 3):
set hw.mfi.mrsas_enable=1
boot


At initial dialog, select SHELL
Wipe boot sector and MBR of boot volume
dd if=/dev/zero of=/dev/da0 bs=1024k count=1000

Restore desired disk partitioning scheme
gpart restore da0 < backup_of_da0
gpart show da0 # verify as intended
gpart restore da0s1 < backup_of_da0s1
gpart show da0s1 # verify as intended

REBOOT


[repeat the above steps to boot off the thumb drive]

Select INSTALL
Accept default keymap
Specify hostname (with domain???)
[Is that REALLY so important that it has to be done before we even know that the host will boot to FreeBSD????]
Accept default distributions
Specify MANUAL partitioning
Verify the disk structure represents the restored configuration from above (why isn't this sorted??)
Assign mount points for da0s1[aefgh] leaving the others unspecified (for now)
FINISH
COMMIT


Ignore warning about preexisting filesystem on / (how could there be?)
[N.B. If you heed the warning and answer 'No', delete the offending partition and recreate it, it gets placed at the END of the volume with a hole left where it was initially located]

Error: mount: /dev/da0s1a no such file or directory
Yet ls -al /dev/da0* reveals all of the expected entries (s1, s1[abefgh])
Build filesystems on each (in case THAT is what the error is claiming)
for p in a e f g h ; do ; newfs /dev/da0s1$p; done

REBOOT


[repeat the above steps to boot off the thumb drive]

Repeat the above through the partition editor steps
Again, ignore warning of existing filesystem on /

Checksum verification proceeds correctly
Archive extraction proceeds correctly
Set root password
Configure first network interface with static parameters
Configure DNS
Select timezone
Confirm timezone
Skip date and time setting (both appear OK)
Accept default services
Accept default security features
Decline offer to add users
EXIT

Decline offer to open a shell for manual configuration
REBOOT

Now, select the targeted disk drive as the boot volume.
The BIOS doesn't find anything and moves on to the next boot source

If I again boot and drop into a shell, I can find everything on the targeted drive; it just won't boot (or even complain of "Missing Operating System" -- so maybe the MBR boot code doesn't get installed?)
 
1. You fail to specify which version of FreeBSD you are trying to install. This is a rookie mistake.
2. The command 'gpart create -s BSD -n 20 da0s1' should allow you to create a BSD disklabel with 20 partitions.
3. Is this server booting in Legacy BIOS mode or in EFI (UEFI) mode?
4. At the end of the installation you are offered the option to enter a shell. You can use that to inspect the partitions and the boot sectors and make changes (if needed) before rebooting.
5. You don't need to create all partitions during installation. You can create the most important ones during installation and add the rest once the system is operational.
6. You can boot from the dvd1 install .iso to a rescue shell and do all the installation steps manually: create partitions, create filesystems, extract tarballs, edit files in /etc, install boot blocks and reboot. This is a way to completely avoid the installer and have 100% control of the process.
7. Boot problems may be caused by firmware bugs so try updating the BIOS and the storage controller's firmware.
 
1. You fail to specify which version of FreeBSD you are trying to install. This is a rookie mistake.
Sorry, in the 2.1R days, there was only one platform. The most recent release -- seems like it would be the obvious assumption, given the context I'd provided:
"Having been away from FBSD since 2.1R (NBSD being my home for the intervening decade+), I thought it would be a good time to see how FBSD has evolved."​
2. The command 'gpart create -s BSD -n 20 da0s1' should allow you to create a BSD disklabel with 20 partitions.
No problem there, as I indicated:
"Dropping into a shell, I convinced gpart() to let me mimic the layout by sneakerneting it from a NBSD host after previously wiping the first ~GB of the target drive.."​
this also drags in the actual sizes of each partition
3. Is this server booting in Legacy BIOS mode or in EFI (UEFI) mode?
BIOS as the "requirement" for an MBR should suggest.
4. At the end of the installation you are offered the option to enter a shell. You can use that to inspect the partitions and the boot sectors and make changes (if needed) before rebooting.
Yes, as I can also do at the start of the process (or from LiveFS) -- which is obviously how I was able to wipe the first GB of the target drive, create the partitions and verify their existence. But, I don't see where the boot blocks are installed and the second stage wired in.
5. You don't need to create all partitions during installation. You can create the most important ones during installation and add the rest once the system is operational.
Yes:
for p in a e f g h ; do ; newfs /dev/da0s1$p; done
These to cover the mount points that a system historically requires (so I don't have to have an oversized / and move the various other parts of the filesystem onto their own mounts AFTER unpacking)
6. You can boot from the dvd1 install .iso to a rescue shell and do all the installation steps manually: create partitions, create filesystems, extract tarballs, edit files in /etc, install boot blocks and reboot. This is a way to completely avoid the installer and have 100% control of the process.
I can just select "SHELL" at the first dialog (as stated above). Note that I can examine the unpacked tarballs and filesystems (mounting on /tmp/tmp as the install media is RO) so I know the storage controller works and the "right" drive is being accessed in all cases.

What's missing is an explanation of the steps to install the boot blocks -- assuming the installer is NOT installing when given a preset partition scheme.
7. Boot problems may be caused by firmware bugs so try updating the BIOS and the storage controller's firmware.
Did that before starting. Along with the firmware for the NICs, iDRAC and secondary storage controller.

I plan on installing ESXi on the box, tonight. That will provide some reassurance as to whether or not the hardware wants to take on an OS. (I have to decide if I want to scrap the box, tomorrow morning -- there's a shortage of space to pile up kit that will take any effort to bring online) :(
 
The FreeBSD boot process is described in the Handbook: https://docs.freebsd.org/en/books/handbook/boot/

I have a hypothesis about where the problem could be. While the kernel and userland utilities can handle FreeBSD disklabels with more than 8 partitions, the FreeBSD loader (the component that loads the kernel) and the boot blocks maybe can't. See src/sys/sys/disklabel.h where the MAXPARTITIONS macro defaults to BSD_NPARTS_MIN which is equal to 8. The loader and the boot blocks use this default. If this is the culprit, as a workaround you can use a partitioning scheme with two slices — da0s1 would contain a disklabel with 8 partitions, the root filesystem will be in da0s1a, and da0s2 will contain all the other partitions. The disklabel in da0s2 will have more than 8 partitions but that won't affect booting.
 
Back
Top