missing boot loader while attempting BIOS/GPT partial-disk manual installation
Nacho Lariguet
lariguet at gmail.com
Mon Jan 7 13:02:41 PST 2019
I tried dragonFlyBSD 4.8 the past year but was unsuccessful even to
boot the installer due to a kernel panic on Dell PowerEdge R610/R710
uEFI servers. Now I am giving it a second try on a non-uEFI laptop
before even attempting the servers once again. The idea is to manually
configure as much as possible so I can learn how things get done in
the process.
I already managed a dragonFlyBSD 5.4.1 MBR+HAMMER#2 full-disk
installation without any major issues so far.
What I am failing at right now is a BIOS+GPT+HAMMER#2 partial-disk installation.
After booting the installer from a USB drive (and hitting 9 and
setting some non-relevant options like loading drm/radeonkms modules)
I logged-in as root to manually format the drive as following:
gpt create ad0;
gpt add -i 0 -b 2048 -s 409600 -t efi ad0; ### ie: ATA drive #
0 physical slice # 0 ... yes yes I know; I am not attempting the EFI
boot on a BIOS machine !
gpt add -i 1 -b 411648 -s 335544320 -t dfly ad0; ### ie: ATA drive #
0 physical slice # 1
gtp show ad0;
Which I guess should be doing the following:
eg: 0 ~ 1 - ( 1 sector * 512 bytes) =
512 bytes ... allocated
to PMBR
eg: 1 ~ 1 - ( 1 sector * 512 bytes) =
512 bytes ... allocated
to GPT header # 1
eg: 2 ~ 32 - ( 32 sectors * 512 bytes) /
1,024 bytes = 16 KiB ...
allocated to GPT table # 1
eg: 34 ~ 2,014 - ( 2,014 sectors * 512 bytes) /
1,024 bytes = 1,007 KiB ≈ 1 MiB ..
unallocated for alignment purposes only
eg: 2,048 ~ 409,600 = ( 409,600 sectors * 512 bytes) /
1,024 bytes = 204,800 KiB = 200 MiB ...
allocated to ad0s1; ie: ATA drive # 0 physical slice # 0 as GPT EFI
and reserved for future use
eg: 411,648 ~ 335,544,320 = (335,544,320 sectors * 512 bytes) /
1,024 bytes = 167,772,160 KiB = 163,840 MiB = 160.00 GiB ...
allocated to ad0s2; ie: ATA drive # 0 physical slice # 1 as GPT
dragonFlyBSD
eg: 335,955,968 ~ 15,695,887 - ( 15,695,887 sectors * 512 bytes) /
1,024 bytes ≈ 7,847,943 KiB ≈ 7,664 MiB ≈ 7.48 GiB ...
unallocated
eg: 351,651,855 ~ 32 - ( 32 sectors * 512 bytes) /
1,024 bytes = 16 KiB ...
allocated to GPT table # 2
eg: 351,651,887 ~ 1 - ( 1 sector * 512 bytes) =
512 bytes ... allocated
to GPT header # 2
eg: 351,651,888 sectors available on whole drive: Intel SSDSC2CW180A3
180 GB SATA SSD
So far so good: the EFI slice won't be of any use right now but it
will avoid me to recalculate everything when moving to the uEFI
servers.
Then I logged-out and logged-in once again with installer and then
followed the installation sequence and selected partial-disk
installation over GPT#1 (by then I guessed it was referring to ad0s1)
and installed it as following:
/boot = 1 MiB
/ = 40 GiB
/data = 100 GiB
/build = * (remaining space)
no swap
no bootblock since this is a dragonFlyBSD-only installation ... right ?
Then rebooted (without configuring the system) and got: missing boot loader.
So I booted once again with the USB drive to inspect the drive and got
the following:
gpt show ad0;
start size index contents
0 1 - MBR ... MBR
instead of PMBR ?
1 1 - Pri GPT header ... OK
2 32 - Pri GPT table ... OK
34 29 - ... so why
it is splitted ?
63 1985 - ... so why
it is splitted ?
2048 409600 0 GPT part - EFI System ... OK
411648 335544320 1 GPT part - DragonFly Label64 ... OK
335955968 15695887 0 ... so why
is it index=0 ... shouldn't be unallocated space ?
351651855 32 - Sec GPT table ... OK
351651887 1 - Sec GPT header ... OK
disklabel ad0s1;
# /dev/ad0s1:
#
# Calculated informational fields for the slice:
#
# boot space: 1012224 bytes
# data space: 175824896 blocks # 171704.00 MB (180044693504 bytes)
#
# NOTE: The partition data base and stop are physically
# aligned instead of slice-relative aligned.
#
# All byte equivalent offsets must be aligned.
#
diskid: 6146e148-12a4-11e9-90ae-0115c54bedad
label:
boot2 data base: 0x000000001000
partitions data base: 0x0000000f8200
partitions data stop: 0x0029eb8f8200
backup label: 0x0029eb8fd200
total size: 0x0029eb8fe200 # 171704.99 MB
alignment: 4096
display block size: 1024 # for partition display and edit only
16 partitions:
# size offset fstype fsuuid
a: 1048576 0 4.2BSD # 1024.000MB
d: 41943040 1048576 HAMMER2 # 40960.000MB
e: 104857600 42991616 HAMMER2 # 102400.000MB
f: 27975680 147849216 HAMMER2 # 27320.000MB
a-stor_uuid: f93358c1-12a4-11e9-90ae-0115c54bedad
d-stor_uuid: f93358de-12a4-11e9-90ae-0115c54bedad
e-stor_uuid: f93358f2-12a4-11e9-90ae-0115c54bedad
f-stor_uuid: f9335907-12a4-11e9-90ae-0115c54bedad
The gpt command is reporting that the drive is almost as intended
except for some unallocated space after the primary GPT table which is
now splitted and for the fact that the second unallocated block is
also denoted with index=0 which seems annoying since it index=0 was
intended for the EFI slice only and by the way another minor annoyance
with the (protective) PMBR changed now to MBR. And to my knowledge the
disklabel command shows everything as intended.
So I suppose I failed to make the slice # 1 (aka dragonFlyBSD slice)
active or something like that because the /boot (code) is within it
but it seems what fails is the transfer from the MBR to /boot in the
slice # 1 right ?
The handbook comes only with the procedure for a whole disk
installation, and, while dwelving once again in the man pages for gpt
and disklabel, I encountered many references to manually make the
installation bootable for a whole disk but not for a partial one.
I am aware of https://www.dragonflybsd.org/cgi/web-man?command=gpt§ion=ANY
gpt boot device ...
The boot command allows the user to create a small boot partition
in a freshly created GPT.
This command creates a small, 1GB boot partition as partition #0
and hacks in a special `slice 1' in the PMBR which aliases it.
The PMBR is further modified to add the necessary boot code. You
can then disklabel GPT partition #0 and mount it, placing the
contents of /boot directory within.
but I don't understand the purpose of it since I already have the boot
code in slice # 1 /boot ... right ?
And I am aware of:
gpt init -f [-B] [-E] device ...
The init command allows the user to create a new GPT similar to
the create command, but will also populate it with a boot slice
(s0) and a DragonFly slice (s1). The boot slice will be dos-for-
matted.
... and:
Boot Setup
To setup a disk using GPT for booting, the steps below can be used. Sys-
tem is copied from an already installed disk, e.g. a hard disk or an
install CD. This example will setup disk da1 with GPT for booting, using
the boot command.
But this way I cannot specify manual slice sizes etc ... I assume this
is what it is being used for whole disk installations right ?
And also I am aware of
https://www.dragonflybsd.org/cgi/web-man?command=disklabel§ion=8
Where the example in "Initializing/Formatting a bootable disk from
scratch" is of no use to me because:
gpt create da0
gpt add da0
disklabel64 -B -r -w da0s0 ... these two disklabel commands are
something I never did because I assumed was done by the installer
disklabel64 -e da0s0
it assumes the first slice (whole disk I guess).
Summarizing:
I managed to set the drive layout as I want it and I managed to
install dragonFlyBSD on it the way I want it.
What's not working and so what I am asking help with, if it is
possible, is how to link [P]MBR to /boot (code) in slice # 1 because
the documentation which I came across (mainly in the man pages) seems
to lack a manual partial-drive installation so far.
I am in the process of ditching Windows Server once and for all so for
some time I got hands-deep with arch-linux and so far I am happy with
it, but what I really want to run is some BSD, and, to no surprise,
what I really want to run is dragonFlyBSD, and yes, it will be a steep
curve, I know.
Thanks a lot !
More information about the Users
mailing list