| From: Mark Davies <m...@ecs.vuw.ac.nz>
| Subject: Re: disk numbering
| So to do this I need to go to current? getfsspecname() doesn't appear to
| be in 6.1_STABLE.
Yes, currently anything related to NAME= (wedges or otherwise) requires current,
the 6 versions are missing the translation - it would be really nice for that
to get pulled up - or after the lunacy that causes ...
onyx$ dump -W
DUMP: no match for `Buf2-Storage' (No such process)Last dump(s) done (Dump
'>' file systems):
[...]
gets fixed (in dump and other places) - that is, in my fstab, one of
the entries is:
NAME=Buf2-Storage /local/storage ffs rw,log,noauto 1 0
That wedge is on an external USB drive that is off site at present
(backups get done to it from time to time - last was yesterday...).
In earlier configs, it would have been something like
/dev/sd0e /local/storage ffs rw,log,noauto 1 0
which simply hopes that the USB drive in question becomes sd0 when connected
but which otherwise works fine (nothing objects that it isn't connected,
unless an attempt is made to mount it, of course). Wedges with names
that don't (currently) exist should be silently ignored unless they
are explicitly required for whatever operation is being attempted.
That aside, there's nothing aside from the missing library routine,
and calls to it, that won't work in NetBSD 6, and this naming method
makes wedges actually useful (and named disklabels, I guess) so
pulling it up for 6.2 (and perhaps 6.1.4, perhaps not 6.0.5 but
others can decide) would be a really nice thing to happen.
The GPT stuff is all pretty easy to use (aside from this naming issue
in 6 - and NetBSD 6 (I think) still also needs wedge autodiscovery
enabled). The only slightly tricky parts I have found, is that if
you want wedges on a raid, and to autoconfigure root on a wedge on
a raid, the root wedge name must be of the form "raidNa", as in...
NAME=raid7a / ffs rw,log 1 1
from my fstab, where root is on a wedge on raid7 (it is not what would
be the "a" wedge in any sense, that's just the name it has to have...)
And second, when making a GPT drive bootable ("gpt biosboot") you need
to start from a drive that has had a bootable MBR on it first (using
fdisk to install the primary boot block) and then convert that to a
PMBR using "gtp create" (or the conversion process if you want to
keep the partitions) - the boot code in the MBR is required, and the
conversion will keep it, but once the MBR becomes a PMBR there's no
rational way of installing it (fdisk will refuse, and there is no
other tool that does that job - you could play with dd, but....)
kre
