Date: Fri, 15 Jul 2016 12:03:14 -0600 From: Ian Lepore <ian@freebsd.org> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.ChatUSA.com>, Paul Mather <paul@gromit.dlib.vt.edu> Cc: freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <1468605794.72182.320.camel@freebsd.org> In-Reply-To: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com>
index | next in thread | previous in thread | raw e-mail
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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1468605794.72182.320.camel>