System Update froze - UbuntuMATE 16-04

[Colin Watson]

On Sat, Jun 23, 2018 at 02:38:53AM +0800, Bret Busby wrote:
> On 22/06/2018, Colin Watson <cjwatson at ubuntu.com> wrote:
> >  * You suggest that it is a new antifeature of some kind introduced in
> >    16.04.2: you have next to no evidence of that,
> 
> As I previously posted, the documentary evidence shows that
> 
> "
> Bug #1667512 reported by tbenst on 2017-02-23
> "
> 
> less than a week after
> 
> "
>  Release of Ubuntu 16.04.2 was delayed a number of times, but it was
> eventually released on 17 February 2017
> "
> 
> Interesting coinceidence, no?

Coincidence and nothing more.  I tracked down the actual change in git
and it reached Ubuntu before the original release of 16.04.  Don't
confuse correlation with causation.

> would it not be a wothwhile idea, to, where a contraindication is
> found, for the updating software (the software doing the updating
> process, not the software being updated), to check the applicable
> conditions at the time of the software update request, and to halt the
> update process, and display an error window listing conditions from
> which problems are likely to arise, with the update process beinbg
> applied with those conditions existing, and, suggested actions the
> clear the conflicting conditions, so as to allow the update process to
> proceed without problems?

In general we always try to make upgrades as reliable as possible, but
piling more software upon software to try to detect and report when bugs
might affect you can easily end up being rather less reliable than just
fixing the bugs in the first place ...

> And, whilst I/O problems may be shown with my external HDD, in this
> case, which, you contend, resulted in the initramfs problem, causing
> the system to become unstable and, apparently, not rebootable, if, as
> you appear to indicate, "the "sync" in update-initramfs was introduced
> before 16.04(.0)  was released", and, that, the presence of ongoing
> disk operations, was KNOWN to cause this critical problem, why was a
> check for disk operations, not mandatorily included in the update
> procedure, requiring an absence of contraindicatory disk operations,
> to avert this critical system failure scenario?

(Is there any chance you could consider being just a *little* bit less
verbose?  Please?)

Personally I hadn't even noticed this bug before this thread (seeing as
these days I mostly work on Launchpad and other infrastructure rather
than Ubuntu itself), so I can't speak for what other people may or may
not have considered doing.  It is quite possible that it simply did not
affect enough users to have attracted notice.

-- 
Colin Watson                                       [cjwatson at ubuntu.com]