Date: Fri, 15 Jul 2016 10:29:09 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.ChatUSA.com> To: Paul Mather <paul@gromit.dlib.vt.edu> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> In-Reply-To: <D9A9D485-4564-4F58-8B6D-564D4C86229E@gromit.dlib.vt.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
[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. > 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. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201607151729.u6FHT9PT068989>