From owner-freebsd-arm@freebsd.org Wed Jan 2 18:39:30 2019 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E00B2142C4A3 for ; Wed, 2 Jan 2019 18:39:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D1866AEBA for ; Wed, 2 Jan 2019 18:39:29 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x02IdObU075061; Wed, 2 Jan 2019 10:39:24 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id x02IdOSH075060; Wed, 2 Jan 2019 10:39:24 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201901021839.x02IdOSH075060@pdx.rh.CN85.dnsmgr.net> Subject: Re: [BBB] nanobsd boot stuck In-Reply-To: <20190102140045.GA57656@freebsd-t450.fritz.box> To: =?iso-8859-15?Q?Manuel_St=FChn?= Date: Wed, 2 Jan 2019 10:39:24 -0800 (PST) CC: freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 6D1866AEBA X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.97 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.973,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 18:39:30 -0000 > On Tue, Jan 01, 2019 at 12:47:26PM -0800, Rodney W. Grimes wrote: > >> Hi, > >> a freshly built nanobsd RELEASE-12.0-p1 for Beaglebone Black does not > >> boot further than the line > >> "Trying to mount root from ufs:/dev/mmcsd0s2a [ro]" > >> > >> I've tried to track this further down and the findings are > >> > >> > >> 1. booting into single user mode works. When I boot into single user > >> mode and exit from there, the BBB continues its boot into multiuser > >> without any further problems. I'm able to login and have all my programs > >> working. > >> > >> 2. setting "set -x" in /etc/rc to extend verbosity. After setting, i can > >> see that the boot stops at line 62 of rc which says: > >> > >> dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` > > > >Hum, is /dev not getting mounted for some reason > >causing an issue here. > >Right before this line try adding: > >#Lets see what file systems are here now > >/bin/df > >#Lets see if we have a /dev/null to use > >/bin/ls -lag /dev/null > >#Lets see what this command returns > >/sbin/sysctl -n vfs.nfs.diskless_valid > >> > >> I altered this line to > >> > >> dlv=`/bin/echo "0"` > >Uh, ah, I see it, this is NOT what happens when you run: > >dlv=`/sbin/sysctl -n vfs.nfs.diskless_valid 2> /dev/null` > >set | grep dlv > >dlv='' > >To get past try: > >dlv='' > >> > >> but it still stops at that line. Using the builtin sh-echo instead of > >> the binary one ( dlv=`echo "0"` ) the boot continues until: > > > >This is starting to sound like it is having issues accessing > >the root device, like your sd card is toast. > >> > >> sh /etc/rc.initdiskless > >> > >Why did it wonder down the diskless path, you specifically > >set dlv.. oh gone back and editied.. I see it, dlv=0, not same as dlv='';. > >dlv gets null of vfs.nfs.dikless_valid does not exist as an oid: > ># /sbin/sysctl -n vfs.nfs.diskless_valid > >sysctl: unknown oid 'vfs.nfs.diskless_valid' > >not 0 as you forced. > > hmm, on all my machines (amd64 and armv7, 12.0-p1 and 11.2-STABLE) there > exists an oid named vfs.nfs.diskless_valid: > > # sysctl -n vfs.nfs.diskless_valid > 0 > > That was the reason why i've set dlv to 0 in the first place. Argh, ok, I went down the wrong rabbit hole, teach me for not doing a uname before I run stuff in an xterm to see what the values are. 11.1 does not have this oid. > > >> After commenting this whole "diskless" section out, the boot continues > >> by sourcing rc.subr and stops in the function load_rc_config() executing > >> this line: > > > >> > >> [ -r /etc/defaults/rc.conf ] > >> > >> 3. using different SD-Cards containing the nanobsd image makes no > >> difference. All cards show same behavior described above. > > > >sd card socket, bad sd code in the kernel image your using? > > I've managed to organize another Beaglebone Black board, and on this one > the image does boot without issues. > It seems that the beaglebone i was developing on the whole time is > defect somehow! I wonder if it is the sd card socket wore out from usage? These are not really high duty cycle things, and why I prefer to actually netboot these types of devices over fooling with sd cards. Though many have crappy network performance, so that leads to other issues :-(. > >> 4. regular FreeBSD Image (non-nanobsd) does boot correctly. > >> > >> I do not have a clue how to further debug this. Since the > >> single-user-mode works, it seems to me that the installation as such is > >> not entirely broken, but there is some hickup in the init procedure. > >> > >> Any ideas? > > > >Well a few corrections above might get you closer, since > >you forced it down the diskless path, which is incorrect. > > Thank you for your tips! Just glad its been found! -- Rod Grimes rgrimes@freebsd.org