From owner-freebsd-arm@freebsd.org Fri Jul 15 14:53:31 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 EF447B9A701 for ; Fri, 15 Jul 2016 14:53:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD602132D for ; Fri, 15 Jul 2016 14:53:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id q83so106605261iod.1 for ; Fri, 15 Jul 2016 07:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=huH/mNxjK+YnNLpFi8H0WB//O+q9s3l6Xm1guckOifk=; b=Bez2ftUdqTIKsCA4JQEE49cjfE54v6dgP470V2+mRvkQ1YiD9ptsu0dRHRZiy46z1l wPjLDzUwcG4DnQzzvGnmmqe1dv59FZHbEszZZacaBre0ygXFJ+qfUjUCvCezlQ4XQ6DP 04Aeb3NQ/FOiC6UgLoIx5XMTUQvoYXelpExf6WRYlAJ5PbssXmFDt4iLTiv9rFZoYen3 KMthgYEm0kn54r+3fNBEDf7Xb71B/GH9ipo23Oy8gs+2Z3pAUccUeDyMx5hWaU7FR4IX n9u7XGqnbUGgNH25a/l+5xPVdafnlHlqKir/Tu4ahobakp1Rzvi+UOaNXk98DBorx0KC BnaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=huH/mNxjK+YnNLpFi8H0WB//O+q9s3l6Xm1guckOifk=; b=aCh6JaVPXclUEVsMT3hfwmPiqORrR8IJ3smnD2Tc7piY8C04T45jA6q5Dope/gpO2r GbiPRa8M6UXEHOasg/plMFN1bz8gYZyNlFwWW3ALaZ/19E4d8LQq4g8OJjmsEKZSY4RN PsB2zexbicytOnjQIK65CPttPdm9sgbB96A7v6OVetE65oj/5lkNnLKes7AEiOoC3j3l mVB9Ga1r32EBdFA1ywwjgF02J1Uj7jR64W5fBLayPv7jql9w1WD+w8MivQ1is3jEfuW7 UQAigt/DTkIa0wpdTdcXQ2pD/bEnj7W7PAvY2FWluFfQip9rlw97dipa9jeQGrmlHRJZ 1N9w== X-Gm-Message-State: ALyK8tI9GN3TOGH9ymcOgGarVG+e6bZHzgGSSezPTKxvLBMI8/WCzNzV76KoFBga/ZPfXh3Wwth+BJ+Efc+xGA== X-Received: by 10.107.133.93 with SMTP id h90mr21233006iod.16.1468594410894; Fri, 15 Jul 2016 07:53:30 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.137.131 with HTTP; Fri, 15 Jul 2016 07:53:30 -0700 (PDT) X-Originating-IP: [69.53.245.200] In-Reply-To: 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> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> From: Warner Losh Date: Fri, 15 Jul 2016 08:53:30 -0600 X-Google-Sender-Auth: qJAJpCDhQDIPISrYOF7R2gn8raU Message-ID: Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... To: Karl Denninger Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:53:32 -0000 I saw your failok PR. That's a good idea. A better idea, though, is to implement true dual-console mode where both the kernel *AND* /etc/rc run on both the serial and the video consoles. I've poked at this in the past, but have never had time to fully implement it due to other things being more pressing. Warner On Fri, Jul 15, 2016 at 8:44 AM, Karl Denninger wrote: > On 7/15/2016 09:22, Paul Mather wrote: > >> 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 wrot= e: >>>> >>>>> Found it. >>>>> >>>>> 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 should= n't >>>>> matter post-boot as the loader is supposed to pass the dtb file, it i= s >>>>> specified in the config file without any sort of path prefix, and thu= s >>>>> 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! >>>>> >>>>> So, you must do newfs_msdos -L MSDOSBOOT -F 16 {device} >>>>> >>>>> If the "-L" is missing you're hosed; the system facially appears to b= e >>>>> just fine but while the loader comes up and so does the kernel, it ha= ngs >>>>> without ever proceeding -- and without any sort of error message >>>>> indicating that it is unable to mount something it needs. >>>> You have to do that because the device entry in the stock /etc/fstab i= s /dev/msdosfs/MSDOSBOOT. The /dev/msdosfs part indicates it's using ms-do= s labels. In other words, this is just the same sort of failure you were g= etting when you weren't labelling the UFS partition as "rootfs". Labelling= the file system properly "fixes" the issue, as you would expect. >>>> >>>> It's a misnomer to say the code "requires" labels. It's just that's t= he way the distribution images are currently set up. I have an older Pi th= at predates the current distribution images that just uses /dev/mmcsd0... d= evice names in /etc/fstab. Both approaches work fine. You just need to ma= ke sure the devices you specify in /etc/fstab will actually exist when it c= omes 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 rece= ntly when I cloned an SD card I got an error displayed on the serial consol= e. I didn't get an error on the HDMI screen console. > You get an error if rootfs is not labelled on the HDMI screen (as root > fails to mount.) There is *no* error on an HDMI screen if the msdosfs is > not labeled. >> As I've mentioned before directly, FreeBSD/arm acts like console=3D"comc= onsole,vidconsole" is in effect. This means that during /etc/rc boot proce= ssing, you'll only get output on comconsole (except for kernel messages, wh= ich 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/supp= ort USB keyboards, so there's not really much you can do to fix it interact= ively 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 suppor= ted by U-Boot. > Well, that's not true if the kernel is loaded. Once the kernel loads a > usb keyboard works. >> >> I'm not sure comparisons with Intel architecture machines is entirely ap= propriate as they use a different boot environment/mechanism. Still, I sta= nd 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/load= er.conf to avoid the system dropping into single-user mode when doing a reb= oot.) >> >> >>>> If you stop using labels in your /etc/fstab then you won't have proble= ms when those labels are missing. If the labels are missing, the /dev/{msd= osfs,ufs} devices will not be present and the system will drop to single-us= er mode because none-late, non-noauto file systems can't be accessed via th= eir 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. >>>> >>>> If a file system is not needed to mount as part of booting (as you sug= gest for /boot/msdos) then you should probably flag it with the "noauto" op= tion in /etc/fstab or remove it from /etc/fstab entirely. >>>> >>>> I think the problem you were having is not copying all the required at= tributes 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 filesyste= m >>> was failing to mount, which was discernible from the console output. >>> >>> 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? >>> >>> 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 fo= rgot to label a UFS file system as "something" when you made it. :-) >> >> Cheers, >> >> Paul. > > Understood, but the issue here is that there's no indication without a > serial console that you have anything wrong -- the system appears to > have simply hung. > > The quick fix is to put "failok" (or noauto) in the default /etc/fstab > entry for the dos filesystem, since it is not necessary for that > filesystem to be mounted at all on a running machine. If there is a > policy reason to leave it accessible (and there's a fairly-clean > argument that there is) then "failok" might be preferable to "noauto", > but either way forcing a filesystem that is not necessary to be > accessible or the system fails to come up and does not give any > indication of same on what many users will have accessible to them is > facially wrong. > > These devices are thought of as "appliances" by many and as such the > model of USB keyboard + HDMI (e.g. TV or monitor) is entirely > reasonable, and IMHO FreeBSD ought to, when possible, make that a viable > option. It both is and can be provided the kernel loads, but the > defaults in pre-built configurations right now preclude that. > > -- > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/