System Update froze - UbuntuMATE 16-04

Fri Jun 22 18:38:53 UTC 2018

On 22/06/2018, Colin Watson <cjwatson at ubuntu.com> wrote:
> On Fri, Jun 22, 2018 at 01:26:50AM +0800, Bret Busby wrote:
>> On 22/06/2018, Colin Law <clanlaw at gmail.com> wrote:
>> > On 21 June 2018 at 16:46, Bret Busby <bret.busby at gmail.com> wrote:
>> >> So, this "feature" that was apparently included in 16.04.2, in all of
>> >> the circumstances, probably, instead of changing Ubuntu 16.04 to the
>> >> status of Debian sid, appears to have turned Ubuntu 16.04 and 18.04,
>> >> into the nature of Debian experimental, with all data at risk.
>> >
>> > It is the disc causing the update to hang, not the update causing the
>> > disc problem.
>>
>> So, this is now a dead parrott scenario?
>>
>> With the bug having been identified, and the effects conforming to the
>> specified effects of the bug, as experienced by other people, you now
>> claim the confirmed bug to be imaginary?
>
> I've said this before in different words, but let me say it again.
>
> The evidence is that there are two problems at work here.
>
>  1) Your hardware is apparently failing.
>
>  2) Ubuntu is not as robust against this particular kind of failure
>     during upgrade as it ought to be.
>
> Pointing out that the first of these problems is the most important one
> here does not deny the existence of the second.
>
> You're spinning this into hyperbolic scenarios:
>
>  * 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?

A point releaese occurs, and, then, within a week of that, the bug
report is made...

>    and really your
>    problems seem highly unlikely to have anything to do with any
>    particular version of Ubuntu given that you've posted kernel logs
>    indicating hardware errors, which should pretty much always be the
>    first port of call when diagnosing a problem.  Get your hardware into
>    a stable state before worrying about anything else.  (For what it's
>    worth, the "sync" in update-initramfs was introduced before 16.04(.0)
>    was released, in response to Debian bug #783620.)
>

I note that we have, at

https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1667512

"
Colin Watson (cjwatson) wrote 18 hours ago: 	 #16

 I've posted a merge request upstream:

  https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/6
"

->

"
  Opened Jun 21, 2018 by Colin Watson at cjwatson 1

Only sync the filesystem containing the initramfs

This avoids update-initramfs taking an unnecessarily long time if
there is lots of activity on a different filesystem, or even hanging
in cases such as a stale NFS mount.

Based on a patch by Jukka Tastula poltsy at gmail.com.

Closes: #882380 LP: #1667512 Signed-off-by: Colin Watson cjwatson at debian.org
"

Now, here's a suggestion...

When I had tried to do the system update on my souper dooper computer,
it woiuld not allow it - apparently, the Ubuntu base part of the
update, required about 500MB of free disk space, which was not
available, so (thankfully, in the circumstances) the system update did
not proceed, and, so, I proceeded to apply the system update, in
parts, excluding the part that is the Ubuntu base part.

Now, the point here, is that the software update facility checked for
sufficient free space, and, provided an explanatory error message,
with suggested correction, instead of proceeding.

So, the question arises; given that

 "
Bug #1667512 reported by tbenst on 2017-02-23
"

and that bug has not been fixed, and

"
azizLIGHT (azizlight) wrote on 2018-04-09:

atom's suggestion to stop all disk operations was the key to fixing this
"

and

"
Colin Watson (cjwatson) wrote on 2018-06-20"

Re comment #7, coreutils 8.24 added the ability to do "sync -f
FILENAME" to sync only the file system containing FILENAME. I think
update-initramfs should probably be changed to use that in xenial and
newer.
"

and

"
Colin Watson (cjwatson) wrote on 2018-06-20:

(A versioned Depends or versioned Breaks as appropriate on coreutils
would probably be a good idea, at least in xenial to avoid upgrade
problems from trusty.)
"

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?

As examples, in this case, if no other way of dealing with the
external HDD I/O errors, is available, to cease the disk operations, a
system reboot, before the update procedure, proceeding, could have
allowed the update process to complete, with (possibly?) following the
post-update system reboot (or, the system reboot before the update),
with running fsck on the external HDD? Also, in the case of a firefox
update, the software update software checking whether an instance of
firefox is running, and, if so, requiring it to be closed (and,
extinguished from processes that are running).

It may also be that, depending on possible contraindications of
software updates, it is worthwhile to require a system reboot, with no
new tasks opened, before allowing a software update to proceed.

These suggestiions should, I expect, have averted this problem that
has arisen with my system.

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?

Tha seems like simple commonsense, to me, to use the term of Judge
Bullingham, of the Old Bailey.

>  * You're accusing other people of claiming that there is no bug in
>    initramfs-tools, when all they've done is correctly identified the
>    chain of events as a hardware error without which you wouldn't have
>    run into update-initramfs's somewhat overly-aggressive "sync" call in
>    the first place

**** (note that this does *not* mean that it isn't a bug;
>    it just substantially changes its importance in a root-cause
>    analysis).
****

> Please slow down, read more carefully, stop attributing malice where
> none exists, and don't panic.
>

I believe that I have not alleged malice, in this topic.

As for panic, remember, it is ME who stands to lose data. No-one else
in this discussion, in this instance. Only me. So, people can suggest
that I stick the computer in a bath full of water, to clean out the
problem, with no risk to their data. But, in this case, it is MY data
that is at risk. No-one else's.

-- 

Bret Busby
Armadale
West Australia

..............

"So once you do know what the question actually is,
 you'll know what the answer means."
- Deep Thought,
 Chapter 28 of Book 1 of
 "The Hitchhiker's Guide to the Galaxy:
 A Trilogy In Four Parts",
 written by Douglas Adams,
 published by Pan Books, 1992

....................................................