Bizarre clone attempt failures on Raspberry Pi2...

[Karl Denninger]

On 7/15/2016 10:51, Ian Lepore wrote:
> On Fri, 2016-07-15 at 09:44 -0500, Karl Denninger wrote:
>>
>> These devices are thought of as "appliances" by many and as such the
>> model of USB keyboard + HDMI (e.g. TV or monitor) is entirely
>> reasonable, and IMHO FreeBSD ought to, when possible, make that a
>> viable
>> option.  It both is and can be provided the kernel loads, but the
>> defaults in pre-built configurations right now preclude that.
>>
> 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."
ERROR means, well, ERROR.

A filesystem that is not necessary to be mounted for system operation
should not prevent the system from starting normally.  Thus, the PR.

> 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.
>
> -- Ian
It is only appropriate to halt startup if starting in the presence of
the condition in question would in some way be harmful to normal
operation.  Since the contents of the msdos partition are *never*
referenced by the running system once the kernel loads, and the kernel
has loaded before it tries mounting the partition that winds up denying
startup if the mount fails this is a demonstrably incorrect entry in
/etc/fstab.

You're not papering over anything in this instance; "failok" results in
the non-necessary mount's failure not causing startup to fail, which is
the obvious and analytically correct choice.  Whether the failure to
mount is caused by later modification of the filesystem's label or a
misconfiguration is immaterial since that particular aspect of the
configuration (the label and its use in /etc/fstab) *is not necessary*
for the system to boot and run correctly.

Declaring something critical to operation that is not in fact necessary
for normal operation is nonsense and harmful; the present situation is
akin to declaring the absence of the aesni.ko module in /boot/kernel to
be a valid reason to prevent startup even though the processor on which
you just booted doesn't have AESNI instructions!

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20160715/d551053c/attachment.bin>