Date: Fri, 15 Jul 2016 10:31:26 -0600 From: Ian Lepore <ian@freebsd.org> To: Karl Denninger <karl@denninger.net>, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: Bizarre clone attempt failures on Raspberry Pi2... Message-ID: <1468600286.72182.311.camel@freebsd.org> In-Reply-To: <b17fc2c2-3edc-63a5-f243-1a7a4a3bfc54@denninger.net> References: <548783e1-9047-68f7-5f50-449db684d602@denninger.net> <d2eb4035-e494-1a7b-98e5-2aa87efe0763@denninger.net> <EDE65B12-4961-4CEF-8AE9-BFDA4FD508A5@gromit.dlib.vt.edu> <5475ea53-ae22-2634-6f2a-5737d1b0e308@denninger.net> <398ae56c-8893-f188-c210-cf7f19ccf433@denninger.net> <1468518953.72182.219.camel@freebsd.org> <7a91fc79-1c85-fac8-aa3f-db90592f3f44@denninger.net> <bec46aff-a4d5-9c4d-49d0-78534b13f719@denninger.net> <E01579F5-9562-4E51-9CFB-EA510460A4C8@gromit.dlib.vt.edu> <60b6e156-981e-9fbd-b68c-0daae1961286@denninger.net> <04391154-A38E-46CD-B570-B2BECFD19022@gromit.dlib.vt.edu> <d1aba096-e645-04df-dfda-5a9284250960@denninger.net> <1468597885.72182.286.camel@freebsd.org> <b17fc2c2-3edc-63a5-f243-1a7a4a3bfc54@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2016-07-15 at 11:02 -0500, Karl Denninger wrote: > 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. > Exactly. Which is why hiding the error by adding "nofail" to the mount for it is, well, the wrong thing to do. > A filesystem that is not necessary to be mounted for system operation > should not prevent the system from starting normally. Thus, the PR. > Why do you think that this is "not necessary" just because you don't happen to use it? There are configuration files on that filesystem (su ch as uEnv.txt) which are there specifically so that userland software has the ability to control the u-boot environment. -- Ian > > 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! >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1468600286.72182.311.camel>