Re: Attachment order of scsibus*

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

    Date:        Fri, 11 Apr 2025 11:05:19 +0200
    From:        =?utf-8?Q?Edgar_Fu=C3=9F?= <ef%math.uni-bonn.de@localhost>
    Message-ID:  <29DAB6A5-F4B2-45D7-B596-3D9ED1A8CB08%math.uni-bonn.de@localhost>

  | But how in this case?
  | There’s some magic
  |         scsibus* at scsi*
  | but no scsi at anything.

Valery (uwe@) explained that, and you can go hunting in all
those files for the details, but the easier way to achieve
what you want is to translate the autoconf messages from the
kernel when it boots, into the configuration that you want.

So if you get
	scsibus0 at mpii0
and you want
	scsibus1 at mpii0

you just put that in your config file (and you also must
config scsibus0 if you want it).

That won't be sufficient however, if you reference mpii0
in the config, you need to config that one as well (or
used to, perhaps that has been improved over the years)
and so forth up to the root bus.

Further, this just defines the names that will be assigned,
not the order the busses are scanned, so you'd still not
get the sdN numbering you're desiring, so you need to
explicitly configure those as well.

The good news is that you can test what you're doing just
by running config(8) over the proposed config file, when
that is happy with what you have configured, and you're
happy that you have configured everything you need wired
down, it should just work when compiled (successfully,
sometimes that can also fail if you have omitted something
necessary), and booted.

But as Michael said earlier, you'd really be better off
using GPT and wedges (I'm not sure that disklabel generated
wedge names would help a lot in your case though).   The
only real issues with converting, usually, are that you need
some empty space at the end of the drive (if you're happy
with the max of 16 partitions that disklabel allows, then
you need 5 blocks free at the end ... also 6 (one extra for
the PMBR) blocks free at the start of the drive (before the
first partition) but most systems allow a full "track" at
least there, 63 blocks, or more typically more, so that's
not usually a problem).   To allow > 16 paritions, you need
1 extra block for each 4 patitions you want to permit.

If you're not converting a boot drive, and you can make those
few blocks free at the end, then "gpt migrate XXn" should be
all you need, followed by a bunch of "gpt label  ..." commands
to put sane labels on the partitions.

Boot drives need a bit more work, though you can still use
legacy BIOS booting = UEFI booting would require an ESP
partition to be created somewhere on the drive (~100 - 200 MB)

I do everything using wedges (been using them since NetBSD 6,
though that system was mixed old & new) these days, and device
numbering wavers around all over the place and I just don't
notice (once, after doing some rearranging, I plugged the
wrong SATA cables into 2 drives when putting it back together,
that swapped wd2 and wd3 I think it was - but I didn't even
notice for months, not until looking at some SMART data and
seeing the the drive I expected to be wd2 was something
completely different - to normal operations it simply didn't
matter.

kre