r324353: boot failure: failed with error 19

Fri Oct 6 20:35:07 UTC 2017

Am Fri, 6 Oct 2017 15:27:52 +0200 (CEST)
Trond Endrestøl <Trond.Endrestol at fagskolen.gjovik.no> schrieb:

> On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote:
> 
> > I run a small appliance on an APU from PCengines. This box is bootet via SD card, the
> > image is created by a modified NanoBSD, which creates GPT/UEFI partitioning and
> > booting images.
> > 
> > That worked until two days ago (I do not track the revision numer) when I wrote (via
> > dd) the last image out. Today, I tried to boot r324353 and it fails at tthe boot
> > loader:
> > 
> > 
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> > 
> > 
> > I can proceed by manually issuing at the loader propmpt
> > 
> > ufs:/dev/gpt/dsks1a
> > 
> > and booting proceeds as expected.  
> > 
> > 
> > Something seems wrong with the UFS labeling lately.
> >   
> 
> > The gpt layout looks like this:
> > 
> > gpart show -l:
> >   
> > =>      40  60751792  mmcsd0  GPT  (29G)  
> >         40       130       1  boot  (65K)
> >        170         6          - free -  (3.0K)
> >        176   2057288       2  dsks1a  [bootme]  (1.0G)
> >    2057464   2061725       3  dsks2a  (1.0G)
> >    4119189   1048576       4  dsks3  (512M)
> >    5167765  55584067          - free -  (27G)  
> 
> For one, these are the GPT labels.
> 
> Can you verify the UFS labels (volnames)?
> 
> Try: dumpfs /dev/gpt/dsks1a
> 
> > From dmesg. I can provide this last output:
> > 
> > [...]
> > mmcsd0: 31GB <SDHC SD32G 3.0 SN 01801299 MFG 09/2015 by 39 PH> at mmc0
> > 50.0MHz/4bit/65535-block Trying to mount root from ufs:/dev/ufs/dsks1a [ro]...
> > uhub0: 4 ports with 4 removable, self powered
> > Root mount waiting for: usbus1
> > uhub1: 2 ports with 2 removable, self powered
> > Root mount waiting for: usbus1
> > ugen1.2: <vendor 0x0438 product 0x7900> at usbus1
> > uhub2 on uhub1
> > uhub2: <vendor 0x0438 product 0x7900, class 9/0, rev 2.00/0.18, addr 2> on usbus1
> > uhub2: 4 ports with 4 removable, self powered
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> > 
> > Loader variables:
> >   vfs.root.mountfrom=ufs:/dev/ufs/dsks1a
> >   vfs.root.mountfrom.options=ro
> > 
> > Manual root filesystem specification:
> >   <fstype>:<device> [options]
> >       Mount <device> using filesystem <fstype>
> >       and with the specified (optional) option list.
> > 
> >     eg. ufs:/dev/da0s1a
> >         zfs:tank
> >         cd9660:/dev/cd0 ro
> >           (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> > 
> >   ?               List valid disk boot devices
> >   .               Yield 1 second (for background tasks)
> >   <empty line>    Abort manual input
> >   
> > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs []...  
> > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs...
> > random: unblocking device.
> > arc4random: no preloaded entropy cache  
> 
> > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error 19.  

This is because me stupid hit the backspace key in the boot loader console :-(

> 
> This surely indicates a mangled UFS volname.
> 
> Maybe you should rewrite the volname:
> 
> tunefs -L dsk1a /dev/gpt/dsks1a

NanoBSD, the original one, defines a "NANO_DRIVE", which is the expansion
of /ufs/"NANO_LABEL". When creating the memory backed filesystem via gpart, the label is
given by the option "-l ${NANO_LABEL}${NANO_CFG_LBL}". NANO_LABEL is set to "dsk".
NANO_CFG_LBL is an extension of my own - I needed for a project GPT/UEFI booting NanoBSD
images and I wanted to stay compatible with the code given by Kamp et al., so
NANO_CFG_LBL is set to s3. This should then provide the fstab entry "/dev/ufs/dsks3" for
the cfg partition. Accordingly, the primary boot partition has "/dev/ufs/dsks1a". It is a
bit messy, since I was in a hurry and had to deal with this crappy MBR slice style s1a
through s1h.

This is what I setup in "defaults-add.sh", just to give the impression, what I intended
to do:

[...]
# Set NANO_LABEL to non-blank to form the basis for using /dev/ufs/label
# in preference to /dev/${NANO_DRIVE}
# Root partition will be ${NANO_LABEL}s{1,2}
# /cfg partition will be ${NANO_LABEL}s3
# /data partition will be ${NANO_LABEL}s4
: ${NANO_LABEL="dsk"}
#
# Labels for the boot and EFI boot partitions
: ${NANO_BOOT_LBL="boot0"}
: ${NANO_EFI_LBL="efiboot0"}
#
# Label extensions: form, i.e., ${NANO_LABEL}${NANO_ROOT_LBL}
: ${NANO_ROOT_LBL="s1a"}
: ${NANO_ALTROOT_LBL="s2a"}
: ${NANO_CFG_LBL="s3"}
: ${NANO_DATA_LBL="s4"}
#
: ${NANO_SLICE_ROOT="s1"}
: ${NANO_SLICE_ALTROOT="s2"}
: ${NANO_SLICE_CFG="s3"}
: ${NANO_SLICE_DATA="s4"}
[...]

The file "defaults-add.sh" is read by "nanobsd.sh" before "defaults.sh" is read. In
"defaults.sh" I altered also all initially set variables to be of the form 
": $VARIABLE=Setting}" so my own settings aren't overwritten by accident and later, when
the driver script of nanobsd is setup, one can set his own variables like
VARIABLE=Setting to overwrite the initial settings. The above should give in case of a
vacant NANO_LABEL the device (like da0) with the propper slice settings - in
case of ancient MBR usage.

I use then a switch, NANO_GPT. In case its true, NANO_SLICE_XXX is then hardcoded set to
p1 - p4.

If NANO_LABEL is vacant

First of all, I think something has changed, since /dev/ufs doesn't get populated anymore
by usage of "gpart label" command. Second, there is a high chance that I messed up
NanoBSD a bit, a couple of days ago I tried to sync with the code base changes and I made
most changes effectively what is now "legacy.sh". 
> 
> Or is the volname misspelled?
> 
> tunefs -L dsks1a /dev/gpt/dsks1a
> 
> Or is /etc/fstab on the SD card corrupted?
> 
> > mountroot> Invalid file system specification.  
> >   
> > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []...  
> > arc4random: no preloaded entropy cache
> > GEOM_ELI: Device gpt/swap.eli created.
> > GEOM_ELI: Encryption: AES-XTS 128
> > GEOM_ELI:     Crypto: hardware
> > Link state changed to up
> > 
> > [...]
> > 
> > 
> > Can someone look into this?
> > 
> > Kind regards,
> > 
> > Oliver  
> 

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 313 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20171006/d2a2f333/attachment.sig>