Bizarre clone attempt failures on Raspberry Pi2...

[Rodney W. Grimes]

> 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.

That only proves a tiny fraction of the caseses, again as I said if
this proves that things are not a bug then lets go close 80% of our
PR's cause this case does not trigger them.  

> 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? 

Yes, abosolutely, because the system failed in a way that appeared silent
to the user, IE, the error message went to someplace other than where
the user is going to be looking for it.  As I said, we also need to
create a PR that we dont tell the user to go hook a serial console up
and look for failures when boot does not seem to be working.  Spitting
out most of boot time to vidconsole, then having /etc/rc output go
someplace else is not an expected behavior.  

It ALSO failed for no real good solid compelling must have reason,
just because a user MAY want to access the msdos after booting, it
is NOT mandatory.  Again robustness here.

> A bug that should be fixed by changing fstab in our distributed
> images to ignore failures to mount the filesystems contained in the
> image?

Certainly, if the system well operate without that file system, making
it easier to repair what has gone wrong.   Saving someone else from the
hours of debug that Karl has spent tracking down what went wrong that
would be what I would call an priceless improvement to the system.

> 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.
> _______________________________________________
> 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"
> 

-- 
Rod Grimes                                                 rgrimes at freebsd.org