From owner-freebsd-arm@freebsd.org Fri Jul 15 18:03:22 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 EBD29B99199 for ; Fri, 15 Jul 2016 18:03:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B6F51C04 for ; Fri, 15 Jul 2016 18:03:21 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6ebbfee7-4ab6-11e6-ac92-3142cfe117f2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.eu.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 15 Jul 2016 18:03:27 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u6FI3EXW009477; Fri, 15 Jul 2016 12:03:15 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1468605794.72182.320.camel@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... From: Ian Lepore To: "Rodney W. Grimes" , Paul Mather Cc: freebsd-arm Date: Fri, 15 Jul 2016 12:03:14 -0600 In-Reply-To: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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 18:03:23 -0000 On Fri, 2016-07-15 at 10:29 -0700, Rodney W. Grimes wrote: > [trimmed]] > > > I'm having a hard time understanding how a problem report got > > > generated > > > about all this, or how any of it is anything other than "Karl > > > misconfigured his system." > > > > > > The downloadable system images work correctly. You made a local > > > change > > > (formatted new media) and depending on how you want to look at > > > it, > > > either you didn't format correctly or you didn't make your config > > > files > > > match the way you formatted, and that made your system stop > > > working. > > > It doesn't mean there is anything wrong about the way the > > > downloadable > > > images are generated. > > > > > > Changing fstab in the distributed images so that a failure to > > > mount a > > > filesystem becomes a non-error seems like a bad idea to me. The > > > only > > > way that problem happens with a downloaded image is if the image > > > wasn't > > > burned successfully, and that doesn't seem like something that > > > needs to > > > just get papered over just because in your use-case you don't > > > really > > > need the filesystem that failed to mount. > > > > > > A PR about the fact that it hung without visibly reporting an > > > error may > > > be appropriate. A PR that says we should just paper over the > > > error > > > because you don't care about it doesn't seem appropriate. > > > > > > Maybe it should be filed as a "feature request" rather than a > > "bug." Does Bugzilla support the distinction? > > > > I agree with Ian that this is not a bug in the sense that anyone > > installing from the distributed images will never trigger it on > > their install media. > > So its not a bug because it doesnt happen at install time? Thanks, > we can > now go close 80% of the PR's as non bugs cause they dont happen in > the > install image. > Excuse me? It's not a bug because: It's not a bug. Go download one of the rpi snapshot or release images. Burn it. Boot it. It works. Now go randomly change something. For example, reformat and repopulate the card in a way that conflicts with what's in /etc/fstab, but don't change fstab to match. Now it doesn't work. In your mind, that's a bug? A bug that should be fixed by changing fstab in our distributed images to ignore failures to mount the filesystems contained in the image? I feel like I've woken up in bizzaro world today. -- Ian > > It is reasonable to file a feature request to omit /boot/msdos as a > > mandatory mount. I think when I first was using FreeBSD/arm on my > > Raspberry Pi it wasn't mounted, but then that predates the current > > distribution images. Now it is. I can see arguments either way > > and the current setting makes sense to me. I think Warner and Ian > > hit the nail on the head that the real issue is the lack of output > > on the video console during /etc/rc processing. > > > > And that is, IMHO, a bug, and a PR should be opened for it as well. > > > Incidentally, does setting console="vidconsole" in > > /boot/loader.conf fix the problem of a lack of /etc/rc messages for > > those who are using an HDMI monitor as their primary/only console? > > If so, there may also be a case for making that the default if the > > assumption is that a minority of people will be using a serial > > console. (Not a fair assumption right now, IMHO, but perhaps a > > fair one going forward as FreeBSD/arm becomes Tier 1.) > > I think the issue of robustness inspite of problems is being ignored > on these issues for > some reason. Adding nofail to /etc/fstab makes the system far more > robust in lite of > things that may go wrong. This is a GOOD thing. > > Having console="vidconsole,comconsole" again is a robustness feature > and makes handing > install time, or any time later easier to deal with. > > Documenting that the output of /etc/rc.d/* does not appear on the vid > console and > that you should look on a serial console if you are experiencing boot > time problems > would be another robustness feature. > > Putting noatime, or atleast giving the user an option to, at FreeBSD > install time > on all SD card mounted file systems would be yet another robustness > feature. I > know that this is hard to do as the SD images are pre rolled with a > hardcoded > /etc/fstab at build time. > > FreeBSD should always strive to be robust inspite of problems, any > problem, if > the cost to do so is minimal. Adding nofail to the msdos partition > fstab > entry on the built images is a minimal effort. > > The tools that try to access this partition from userland well > gravefully > report errors that the user can easily address. > > My bike shed is Royal Blue.