Bizarre clone attempt failures on Raspberry Pi2...

[Paul Mather]

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.