From owner-freebsd-arm@freebsd.org Fri Jul 15 14:22:28 2016 Return-Path: Delivered-To: freebsd-arm@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 97035B99E79 for ; Fri, 15 Jul 2016 14:22:28 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E9CD1211 for ; Fri, 15 Jul 2016 14:22:28 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id DF36E905; Fri, 15 Jul 2016 10:22:26 -0400 (EDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Paul Mather In-Reply-To: <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> Date: Fri, 15 Jul 2016 10:22:26 -0400 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> To: Karl Denninger X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jul 2016 14:22:28 -0000 On Jul 15, 2016, at 9:44 AM, Karl Denninger wrote: > On 7/15/2016 08:36, Paul Mather wrote: >> On Jul 14, 2016, at 11:36 PM, Karl Denninger = wrote: >>=20 >>> Found it. >>>=20 >>> Apparently the current code *requires* the label be set on the msdos >>> partition. If it's not then not only does it not mount (which = shouldn't >>> matter post-boot as the loader is supposed to pass the dtb file, it = is >>> specified in the config file without any sort of path prefix, and = thus >>> once the kernel has loaded it should not matter if the dos partition = if >>> actually mounted or not) *but* the boot process hangs without any >>> indication of why! >>>=20 >>> So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} >>>=20 >>> If the "-L" is missing you're hosed; the system facially appears to = be >>> just fine but while the loader comes up and so does the kernel, it = hangs >>> without ever proceeding -- and without any sort of error message >>> indicating that it is unable to mount something it needs. >>=20 >> You have to do that because the device entry in the stock /etc/fstab = is /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part indicates it's using = ms-dos labels. In other words, this is just the same sort of failure = you were getting when you weren't labelling the UFS partition as = "rootfs". Labelling the file system properly "fixes" the issue, as you = would expect. >>=20 >> It's a misnomer to say the code "requires" labels. It's just that's = the way the distribution images are currently set up. I have an older = Pi that predates the current distribution images that just uses = /dev/mmcsd0... device names in /etc/fstab. Both approaches work fine. = You just need to make sure the devices you specify in /etc/fstab will = actually exist when it comes time to mount the corresponding file = system. > Except that if the root filesystem doesn't mount you get an error, and > thus you can figure out what's going on. What excuse is there for not > printing an error message if a mount fails, and if something in > /etc/fstab fails to mount what's with hanging the machine? I've had > disks be unavailable before on Intel architecture machines (it happens > when disks fail) and the result is an error on the failure to mount = but, > unless it's the root volume, the system still comes up. Are you sure you don't get an error? When I forgot to label rootfs = recently when I cloned an SD card I got an error displayed on the serial = console. I didn't get an error on the HDMI screen console. As I've mentioned before directly, FreeBSD/arm acts like = console=3D"comconsole,vidconsole" is in effect. This means that during = /etc/rc boot processing, you'll only get output on comconsole (except = for kernel messages, which seem to go to both). That's been my = experience in FreeBSD in general. I dimly recall folks on here saying U-Boot doesn't currently = enable/support USB keyboards, so there's not really much you can do to = fix it interactively if you fail to boot the OS and hence enable USB = keyboard support via FreeBSD. That's not a problem if you use a serial = console, which is supported by U-Boot. I'm not sure comparisons with Intel architecture machines is entirely = appropriate as they use a different boot environment/mechanism. Still, = I stand by the fact that I've always got an error message on the serial = console when disks on my FreeBSD/arm system have failed to mount at = boot. (It used to happen regularly with an external USB drive I had = that took a long time to probe, and I ended up having to put a = kern.cam.boot_delay in /boot/loader.conf to avoid the system dropping = into single-user mode when doing a reboot.) >=20 >> If you stop using labels in your /etc/fstab then you won't have = problems when those labels are missing. If the labels are missing, the = /dev/{msdosfs,ufs} devices will not be present and the system will drop = to single-user mode because none-late, non-noauto file systems can't be = accessed via their device nodes when attempting to mount them. When = that happens and you don't have a serial console enabled then you have = problems remediating the situation. >>=20 >> If a file system is not needed to mount as part of booting (as you = suggest for /boot/msdos) then you should probably flag it with the = "noauto" option in /etc/fstab or remove it from /etc/fstab entirely. >>=20 >> I think the problem you were having is not copying all the required = attributes of the file systems in question when cloning your SD cards, = given your /etc/fstab setup. It sounds like you've fixed that, now. > Again, if it dropped to single user mode *and said it was doing so* or > if there was an error message on the console when the filesystem = failed > to mount I would have found this in a reasonable period of time. It > wasn't that rough to do so with the ufs label once I knew the = filesystem > was failing to mount, which was discernible from the console output. >=20 > Not printing an error when things error out is rude at best, and when > that error is going to prevent the system from coming up this darn = well > ought to show up where one with a monitor plugged in can see it, eh? >=20 > There was literally no indication at all as to what was going on and > since gpart does not show filesystem labels for *either* BSD labeled > slices OR msdos figuring out what was different between the two proved > to be a bit troublesome. IMHO at least the failure to display an = error > message in this circumstance ought to be corrected. See above re: serial console vs. video console. As for the labels, these are file system labels and not partition = labels. The big clue is in the device name in /etc/fstab. (The "-l" = option to "gpart show" will only show labels "[f]or partitioning schemes = that support partition labels". That's reasonable, IMHO, as partitions = are not the same as file systems and gpart is concerned with = partitions.) In my experience, complaints about not being able to = access /dev/ufs/something means you forgot to label a UFS file system as = "something" when you made it. :-) Cheers, Paul.=