How to clean up full /boot safely?

[Colin Watson]

On Mon, Feb 12, 2018 at 09:31:36PM +0100, Liam Proven wrote:
> On 12 February 2018 at 19:52, Colin Watson <cjwatson at ubuntu.com> wrote:
> > On Mon, Feb 12, 2018 at 06:57:09PM +0100, Liam Proven wrote:
> >> On 12 February 2018 at 18:16, Colin Watson <cjwatson at ubuntu.com> wrote:
> >> > But if you claim that something flat-out doesn't work when it does -
> >> > even if there are caveats - then I'll still point out the error.
> >>
> >> My words were:
> >>
> >> "Things GRUB might have problems with"
> >>
> >> As I have emphasised before: *MIGHT*
> >
> > Your words were also "the kernel must be on something GRUB can read,
> > i.e. a straightforward Linux filesystem", and that was what I considered
> > to be the main substance of what I was objecting to.  Do you see how
> > that reads as a claim that other configurations flat-out don't work?
> 
> No. It is not and it does not.
> 
> It follows the word "might" and is thus _conditional_.

Huh?  Please could you go back and check, because we seem to be arguing
past each other?

  https://lists.ubuntu.com/archives/ubuntu-users/2018-February/293434.html

Specifically this paragraph:

  The kernel can access anything it likes, once the drivers are loaded
  -- but the kernel must be on something GRUB can read, i.e. a
  straightforward Linux filesystem.

That paragraph is the one and only thing I was referring to in the
innermost-quoted comment above.  That paragraph did not follow the word
"might", and was not in any other kind of conditional construction that
I could see.  The word "might" doesn't appear until the sentence *after*
that.

I have no issues with you saying that GRUB might have problems with
such-and-such a thing.  Sure, I filled in some detail there in my reply,
but to me, "might have problems" is barely even falsifiable, and I
certainly wouldn't try to refute it (for any piece of software at all,
really - I mean, I found a bug in strchr(3) once).

> > [This is my understanding of the design, but it's a very long time since
> > I've personally tried it.  Anyone relying on this should test it on an
> > unimportant system first.]
> 
> And that uncertainty is what I am getting at, _not_ some subtle
> linguistic quibble.

I'm sure I'm uncertain about lots of things that are absolutely safe and
reliable.  Nobody should deduce anything from my uncertainty.

> I'm saying that in the situation of trying to give general comments
> about hypothetical situations in online advice -- which is what
> technical writers must do, and that is what I am -- being careful and
> general is essential and far more important than restrictive literal
> statements about one software component can or can't do, which are not
> generalisable to all systems in all cases.

Right.  But when technical writers make statements that come across as a
careful and general statement that such-and-such a thing *doesn't* work,
then this can make users flail around trying to avoid something because
they were told it didn't work, when it would actually have been their
easiest path to a working system.

That's all I'm getting at here.  I really am not going to argue with you
saying that something is unreliable and should be avoided (I may
disagree in some cases, will probably agree in others, and perhaps I can
supply some extra factual information for the benefit of others, but I'm
obviously not going to persuade you in any case and life is generally
too short).

-- 
Colin Watson                                       [cjwatson at ubuntu.com]