From owner-freebsd-current@freebsd.org Fri Oct 6 20:35:07 2017 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 56E37E412BB for ; Fri, 6 Oct 2017 20:35:07 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C8F5B6EEFC for ; Fri, 6 Oct 2017 20:35:06 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([92.226.90.251]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LdYdG-1dZRyJ3rn8-00inSi; Fri, 06 Oct 2017 22:33:34 +0200 Date: Fri, 6 Oct 2017 22:33:01 +0200 From: "O. Hartmann" To: Trond =?ISO-8859-1?Q?Endrest=F8l?= Cc: "O. Hartmann" , FreeBSD CURRENT , Warner Losh Subject: Re: r324353: boot failure: failed with error 19 Message-ID: <20171006223214.580eb09c@thor.intern.walstatt.dynvpn.de> In-Reply-To: References: <20171006151008.04af417d@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/hneFoi0X9NH0+veIBqaGqvL"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:3olNJUFhelRb/tyMplPn6V39qV71fJG2Q3WIHB9eDpgqb92+NQg Hj4RGatWu1Pf22p2bhXNwj9z0WEc2JDHyqsw4G/TX6VBHLOd1rRX3Av7IFtFIw5E41mBlVg BWPpLcM0d3M5mOH2Xf5ldcfclaFI/cS1kGMFBaesB966ACVwQRSIxImqfKRxX8ofHtzXAeJ bjKWq84qlBeF6QO/awZ3A== X-UI-Out-Filterresults: notjunk:1;V01:K0:FqlK288F1j0=:7sZ/OSRN3lQUNqB+wwMbb/ Ut+tbqeZ3kw5ARSvtY3mLJLYT8cMjijO0GrwKbFb+grHlK+EH8XNF4Sv3vP1PpOacoFwRGzty MvEGi0Fg3FaocMdMvngZT/ea0HFLd5WgDV9uXNksDBnfHHyMNYPh/bgpR+5PmRg2xtzlIPv/2 mdm7F8yl7tj8EkGsFQUdrNUyZpotQXz8oYdVroKLqw8NzO6+zW1KD+9AjSa7WgJx7PQXv49rN 8Fs8JrPudGAUhorQ47iYC1f6McnpqKHm3AkUfZarAstp87YYIzi8TVCpguxObedUjrA4U/2Y2 yuIdjN9eWs4HCuPv7hK/HU8h79UtgpauKF6UrMBA7EPveUlvG5q2scvEX69p+E/ufZOLB+T9M y5JjAJE1227pDQCod9AU03x3/1+wMjf9DKHhJk0n/t2xhTJDfiA4kCwn6KFPT0uOkvw7SNo5D 8anRVUwtfKQda16HmgDpPCyIUiu92YLn/ARSydLmLaD/PwrSTdZ1QmsjzARrWnJryD8YgN5qF quKhwtPMkvKjcrwrJjnYd4vCbUcst2okFsIVNMKxNNbIKadKkSl8TUdCkYEaDnjx8MfOBMCaP xddtcWnrjAz5aQIiXSXkaPYlGLRiljSDmbbi6uyzZPbS3qV1D94Z87wlVRzpwfdOFz4PxnozR xfwkh8l2JhteSf1PB1A29Ii8SZc5PkCHa0t9mJPZjqOFoHj2l/VCxHcLkWR7PQsexmphYBuj+ /QN0vTDYSRIGDQMhHfTE9hCyBbDrDMr13Yul17mGJF4EQ5lBiSW+Fu5iUA8dhQkQRH0VnE1ZV a+HeScVT1nrFTbF96LTtgnn5oizAQ== X-Mailman-Approved-At: Fri, 06 Oct 2017 23:23:34 +0000 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Oct 2017 20:35:07 -0000 --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 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 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: at usbus1 > > uhub2 on uhub1 > > uhub2: = 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: > > : [options] > > Mount using filesystem > > 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) > > 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--