On Tue, Sep 15, 2015 at 7:18 PM, Ryan Stone <ryst...@gmail.com> wrote:
> On Tue, Sep 15, 2015 at 9:53 PM, Julian Elischer <jul...@freebsd.org> wrote:
>> one possibility is to use  gpart label to describe the device.
>> possibly it woudl hav ehte same result in both cases, but I don't know for
>> sure that
>> it works for root device.. you'd have to test.
> I would recommend a UFS label instead.  gpart labels are kind of fragile
> and easy to mess up.  My previous employer has been shipping systems where
> the root fs is specified in fstab via a UFS label for years and it never
> gave us a problems.


And FWIW as Stefano discovered later, NANO_LABEL does just that (use
UFS labels).

The only unfortunate thing is that nanobsd uses a NUL string by default:

grep NANO_LABEL tools/tools/nanobsd/defaults.sh
tools/tools/nanobsd/defaults.sh:       echo newfs ${NANO_NEWFS}
${NANO_LABEL:+-L${NANO_LABEL}${lbl}} ${dev}
tools/tools/nanobsd/defaults.sh:       newfs ${NANO_NEWFS}
${NANO_LABEL:+-L${NANO_LABEL}${lbl}} ${dev}
tools/tools/nanobsd/defaults.sh:               if [ ! -z ${NANO_LABEL} ]; then
tools/tools/nanobsd/defaults.sh:                       tunefs -L
${NANO_LABEL}"s2a" /dev/${MD}s2a
tools/tools/nanobsd/defaults.sh:       # Override user's NANO_DRIVE if
they specified a NANO_LABEL
tools/tools/nanobsd/defaults.sh:       [ ! -z "${NANO_LABEL}" ] &&

The default NANO_DRIVE is useless though -- the old ata(4) stack is dead:

 95 # The drive name of the media at runtime
 96 NANO_DRIVE=ad0

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to