Date: Fri, 15 Jul 2016 16:00:18 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.ChatUSA.com> Cc: Ian Lepore <ian@freebsd.org>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <151CAE3A-CAA6-49FB-A150-7AAA8981E013@gromit.dlib.vt.edu> In-Reply-To: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com> References: <201607151729.u6FHT9PT068989@pdx.rh.CN85.ChatUSA.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Jul 15, 2016, at 1:29 PM, Rodney W. Grimes = <freebsd-rwg@pdx.rh.CN85.ChatUSA.com> 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." >>>=20 >>> 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.=20= >>> It doesn't mean there is anything wrong about the way the = downloadable >>> images are generated. >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >>=20 >> Maybe it should be filed as a "feature request" rather than a "bug." = Does Bugzilla support the distinction? >>=20 >> 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. >=20 > 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. If you are being pedantic, I guess it is a sort of bug, of the class = PEBKAC. I don't believe FreeBSD can fix those. ;-) Note that what you said is not really what I said. I never said it = isn't a bug because you can't trigger it at install time. I said it's = not a bug because you can't trigger it on your install media. "Install = media" was probably a bad choice of words on my part. I should probably = have written "installed media." To clarify, I mean if you install via = the distribution image to an SD card then the resultant installed system = on that SD card will never trigger this "bug." Someone managed to have a problem because when they devised their own = method to make their own SD card that still used the stock distribution = /etc/fstab they omitted a vitally important step that caused the system = not to boot. I'm not sure how that makes it a bug with the distribution = images. If it is, I imagine the "How to reproduce" section would run = something like this: 1. Unlabel the MS-DOS file system on the MS-DOS partition of the SD card 2. Reboot your system 3. Become angry at your computer because it refuses to mount the MS-DOS = file system by its file system label ;-) >=20 >> 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. >>=20 >=20 > And that is, IMHO, a bug, and a PR should be opened for it as well. I agree, and because I also appear to have the same problem on my = FreeBSD/amd64 systems, I'm not holding my breath for a speedy = resolution. :-) (I've never managed to get "multicons" to work across all consoles = during /etc/rc.) >=20 >> Incidentally, does setting console=3D"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.) >=20 > 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. >=20 > Having console=3D"vidconsole,comconsole" again is a robustness feature = and makes handing > install time, or any time later easier to deal with. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > The tools that try to access this partition from userland well = gravefully > report errors that the user can easily address. I agree with most everything you say above. AFAIK, FreeBSD/arm = officially becomes "Tier 1" with 11.0-RELEASE. When that happens, I = figure "robustness" will be more at the forefront of development as it = becomes more mainstream due to that appellation. For me, all I can say is my hat is off to the FreeBSD/arm developers who = have improved the stability and usability of FreeBSD/arm just over the = last year. It has improved immensely. Thank you one and all! Cheers, Paul.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?151CAE3A-CAA6-49FB-A150-7AAA8981E013>