Re: booting from gpt/raid?

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Sun, 1 Jul 2018 23:16:24 -0400 (EDT)
    From:        mlh%goathill.org@localhost (MLH)
    Message-ID:  <20180702031624.9247212AAD%chopper.goathill.org@localhost>

  | Thanks. I lost you regarding how to do the 2nd-stage boot.

It is no different than if you were doing it on disklabel/mbr
partitions (except the device name will be different).

  | I see that it is wrong, but just for practice... that is what I
  | have so far:

It isn't so wrong really.

  | (Good thing about gpt partitioning is that it is easily scriptable).

Yes.  But so are the others, they're just less often used that
way instead of interactively.

  | I did note that if I didn't specify a size, when creating the raid
  | type partition, if I didn't specify a size, it tried to put it up
  | front, starting at 34, labelled Unused.

If there's no size, gpt just finds the first empty space and uses
all of it.   If you specify a size, it will find the first big enough
empty space.   You could also specify the starting block number.

  | I'm wondering if gpt wants
  | to put a 2nd-stage bootable raid partition there.

No, gpt knows nothing at all about booting, or raid
(other than having a partition type "raid", but all gpt
knows is the mapping between the name and the numeric
value stored in the partition table - which is as much
as disklabel knows when you set one of its partitions
to raid.)

  | # gpt create wd2
  | # gpt add -b 1024 -l boot_0 -t ffs -s 1g wd2

That is largely doing it the way I suggested, before you
could have seen my earlier reply.   1g is a bit big, probably,
but not outlandishly so.

  | # gpt add -s 5243112 -t swap -i 2 wd2

That's fine too (I omitted swap partitions from my earlier
list, but you can do it that way.)   [You don't normally
need to specify -i incidentally.]

  | # gpt label -i 1 -l swap_0 wd2

I know you know this could have been combined with the
previous command.

  | # gpt biosboot -L boot_0 wd2

That marks it bootable, and installs gptmbr.bin in the PMBR
This is for BIOS (legacy) booting.

Incidentally, that is what Greg was referring to when he
said ...

>   the 2nd-stage boot, blocks 2-15, are in the partition that is labeled
>   bootable

You got that right, when you did the installboot - that is
installing the 2nd stage boot, and you put it on that
partition (dk0 as it was configured for you).

  | #  newfs dk0
  | # installboot /dev/rdk0 /usr/mdec/bootxx_ffsv2

It would be a good idea to be explicit on the newfs
command which FFS version you want it to use, here
obviously FFSv2 as that's the boot version you installed.

Just add -O2 to the newfs and be certain.

  | # mount /dev/dk0 /mnt
  | # cp /usr/mdec/boot /mnt

Don't forget a boot.cfg as well (it isn't absolutely required
but really is useful to have.)

  | # gpt add -i 3 -s 7806695847 -l raid_0 -t raid wd2

That's fine.

  | Does the boot stuff look ok there?

Aside from the missing boot.cfg and the question of
whether newfs actually made a FFSv2 or not

You will probably also want to copy a kernel (/netbsd)
to /mnt as well (I don't think /boot knows anything about
raid partitions, so it wouldn't be able to find ./netbsd on
there).

  | That brings up the question of whether swap should be type swap or
  | type raid and make a raid swap partition.

That depends what you want to achieve,  if you want swap redundancy,
so your system will just keep working if a drive dies, then you want swap
on raid.   But if you'd prefer more swap space with less disk space used
and you can tolerate the system perhaps crashing and rebooting if a
drive dies (I quite like that, it brings the situation to my attention, I have
had situations where a drive has died and I haven't noticed for ages...)

But if you decide on raid swap, you might just as well put it on a partition
in your big raid filesystem, rather than a separate one, so make a raid,
disklabel or set up gpt on that, and then make a swap partition there
(along with whatever others you want).

You haven't gotten as far as configuring your raid yet in that test run
I see...

Ans, as in the earlier message, I'd still suggest an EFI partition
as well (the unused space from blocks 34..1023 is probably not
really big enough, but it might almost work.)

kre