Bizarre clone attempt failures on Raspberry Pi2...

[Russell Haley]

Isn't putting an non-functioning embedded system on a serial console
to debug standard procedure with ALL operating systems? It sure is
with our embedded GNU/Linux products (even the ones with touch
displays). I've pooched my SD cards lots of times (freebsd and GNU)
and it's never generated this much interest.

As far as continuing after a mount failure, my experience with lots of
types of software (server, windows, embedded) is when a developer
tries to handle exceptions he/she can't prevent, the whole thing just
gets more messy. I sure want to know that the system ignored my u-boot
variables when it booted and/or I can't use them to control the boot
processes. Arm systems are embedded systems. In my experience they
should halt and report an error to the lowest common denominator. In
this case a serial console. While this is fast changing, the majority
of arm deployments will not have a video console.

Is there a can somewhere for my two bits?

Russ

On Fri, Jul 15, 2016 at 1:00 PM, Paul Mather <paul at gromit.dlib.vt.edu> wrote:
> On Jul 15, 2016, at 1:29 PM, Rodney W. Grimes <freebsd-rwg at 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."
>>>>
>>>> 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.
>
>
> 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
>
> ;-)
>
>>
>>> 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.
>
>
> 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.)
>
>
>>
>>> 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.
>
>
> 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.
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"