Bizarre clone attempt failures on Raspberry Pi2...

[Ian Lepore]

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.