From owner-freebsd-arm@freebsd.org Tue Jan 1 20:49:55 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 91E1D142A5C3 for ; Tue, 1 Jan 2019 20:49:54 +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 18FF48AEDB for ; Tue, 1 Jan 2019 20:47:39 +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 x01KlRH5070559; Tue, 1 Jan 2019 12:47:27 -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 x01KlQVj070558; Tue, 1 Jan 2019 12:47:26 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201901012047.x01KlQVj070558@pdx.rh.CN85.dnsmgr.net> Subject: Re: [BBB] nanobsd boot stuck In-Reply-To: <20190101104319.GA89465@freebsd-t450.fritz.box> To: =?iso-8859-15?Q?Manuel_St=FChn?= Date: Tue, 1 Jan 2019 12:47:26 -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: 18FF48AEDB X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.982,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: Tue, 01 Jan 2019 20:49:56 -0000 > 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. > 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? > 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. > Thanks > > -- > Manuel > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org