Date: Fri, 6 Oct 2017 22:33:01 +0200 From: "O. Hartmann" <o.hartmann@walstatt.org> To: Trond =?ISO-8859-1?Q?Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> Cc: "O. Hartmann" <ohartmann@walstatt.org>, FreeBSD CURRENT <freebsd-current@freebsd.org>, Warner Losh <imp@bsdimp.com> Subject: Re: r324353: boot failure: failed with error 19 Message-ID: <20171006223214.580eb09c@thor.intern.walstatt.dynvpn.de> In-Reply-To: <alpine.BSF.2.21.1710061520240.44721@mail.fig.ol.no> References: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> <alpine.BSF.2.21.1710061520240.44721@mail.fig.ol.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/hneFoi0X9NH0+veIBqaGqvL
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Am Fri, 6 Oct 2017 15:27:52 +0200 (CEST)
Trond Endrest=C3=B8l <Trond.Endrestol@fagskolen.gjovik.no> schrieb:
> On Fri, 6 Oct 2017 15:10+0200, O. Hartmann wrote:
>=20
> > I run a small appliance on an APU from PCengines. This box is bootet vi=
a SD card, the
> > image is created by a modified NanoBSD, which creates GPT/UEFI partitio=
ning and
> > booting images.
> >=20
> > 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:
> >=20
> >=20
> > mountroot: waiting for device /dev/ufs/dsks1a...
> > Mounting from ufs:/dev/ufs/dsks1a failed with error 19.
> >=20
> >=20
> > I can proceed by manually issuing at the loader propmpt
> >=20
> > ufs:/dev/gpt/dsks1a
> >=20
> > and booting proceeds as expected. =20
> >=20
> >=20
> > Something seems wrong with the UFS labeling lately.
> > =20
>=20
> > The gpt layout looks like this:
> >=20
> > gpart show -l:
> > =20
> > =3D> 40 60751792 mmcsd0 GPT (29G) =20
> > 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) =20
>=20
> For one, these are the GPT labels.
>=20
> Can you verify the UFS labels (volnames)?
>=20
> Try: dumpfs /dev/gpt/dsks1a
>=20
> > From dmesg. I can provide this last output:
> >=20
> > [...]
> > 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.
> >=20
> > Loader variables:
> > vfs.root.mountfrom=3Dufs:/dev/ufs/dsks1a
> > vfs.root.mountfrom.options=3Dro
> >=20
> > Manual root filesystem specification:
> > <fstype>:<device> [options]
> > Mount <device> using filesystem <fstype>
> > and with the specified (optional) option list.
> >=20
> > eg. ufs:/dev/da0s1a
> > zfs:tank
> > cd9660:/dev/cd0 ro
> > (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /)
> >=20
> > ? List valid disk boot devices
> > . Yield 1 second (for background tasks)
> > <empty line> Abort manual input
> > =20
> > mountroot> Trying to mount root from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\=
^[[Cs []... =20
> > mountroot: waiting for device /dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs...
> > random: unblocking device.
> > arc4random: no preloaded entropy cache =20
>=20
> > Mounting from ufs:/dev/ufs/dsk1a\^[[D\^[[D\^[[D\^[[Cs failed with error=
19. =20
This is because me stupid hit the backspace key in the boot loader console =
:-(
>=20
> This surely indicates a mangled UFS volname.
>=20
> Maybe you should rewrite the volname:
>=20
> 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 bo=
oting 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/u=
fs/dsks3" for
the cfg partition. Accordingly, the primary boot partition has "/dev/ufs/ds=
ks1a". It is a
bit messy, since I was in a hurry and had to deal with this crappy MBR slic=
e style s1a
through s1h.
This is what I setup in "defaults-add.sh", just to give the impression, wha=
t 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=3D"dsk"}
#
# Labels for the boot and EFI boot partitions
: ${NANO_BOOT_LBL=3D"boot0"}
: ${NANO_EFI_LBL=3D"efiboot0"}
#
# Label extensions: form, i.e., ${NANO_LABEL}${NANO_ROOT_LBL}
: ${NANO_ROOT_LBL=3D"s1a"}
: ${NANO_ALTROOT_LBL=3D"s2a"}
: ${NANO_CFG_LBL=3D"s3"}
: ${NANO_DATA_LBL=3D"s4"}
#
: ${NANO_SLICE_ROOT=3D"s1"}
: ${NANO_SLICE_ALTROOT=3D"s2"}
: ${NANO_SLICE_CFG=3D"s3"}
: ${NANO_SLICE_DATA=3D"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=
=20
": $VARIABLE=3DSetting}" 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=3DSetting 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 har=
dcoded set to
p1 - p4.
If NANO_LABEL is vacant
First of all, I think something has changed, since /dev/ufs doesn't get pop=
ulated anymore
by usage of "gpart label" command. Second, there is a high chance that I me=
ssed up
NanoBSD a bit, a couple of days ago I tried to sync with the code base chan=
ges and I made
most changes effectively what is now "legacy.sh".=20
>=20
> Or is the volname misspelled?
>=20
> tunefs -L dsks1a /dev/gpt/dsks1a
>=20
> Or is /etc/fstab on the SD card corrupted?
>=20
> > mountroot> Invalid file system specification. =20
> > =20
> > mountroot> Trying to mount root from ufs:/dev/gpt/dsks1a []... =20
> > 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
> >=20
> > [...]
> >=20
> >=20
> > Can someone look into this?
> >=20
> > Kind regards,
> >=20
> > Oliver =20
>=20
--=20
O. Hartmann
Ich widerspreche der Nutzung oder =C3=9Cbermittlung meiner Daten f=C3=BCr
Werbezwecke oder f=C3=BCr die Markt- oder Meinungsforschung (=C2=A7 28 Abs.=
4 BDSG).
--Sig_/hneFoi0X9NH0+veIBqaGqvL
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature
-----BEGIN PGP SIGNATURE-----
iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWdfofQAKCRDS528fyFhY
lA84Af9nL+w0lhqjNiceKFypjh9QpBtsxm8x/Mw46H6E7rJhZehbACjz1eGYcq+b
Zno0XKD3N1mvC2TBRQW21qfSY0IIAf9lhIbzBzZC1jSN+Xr2A+XP1NsYt7lq5rTO
Nu30B7ZKZjFc+ubqbG/do4VXyApuLP2N0Xbz0qBLkRMvw3Bpwt7x
=hbAw
-----END PGP SIGNATURE-----
--Sig_/hneFoi0X9NH0+veIBqaGqvL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171006223214.580eb09c>