On 23/05/2019 22.05, Stephen Berman wrote:
On Thu, 23 May 2019 18:49:13 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 23/05/2019 13.53, Stephen Berman wrote:
On Thu, 23 May 2019 13:40:06 +0200 "Carlos E. R." <> wrote:
On 23/05/2019 13.33, Stephen Berman wrote:
On Thu, 23 May 2019 13:18:43 +0200 "Carlos E. R." <> wrote:>>> The root file system for Leap is ext4 (on the same machine I also installed TW on btrfs). ps afxu | grep -i btrfs shows this:
...
And apparently, you have it mounted.
Yes.
Unlucky.
Yes, me would have, perhaps, umounted it before starting the procedure, because /I/ knew about this possible problem. I reported it months ago on a virtual machine, but we could not reproduce it and find out what caused it (it happens randomly, and so far, not to the people that can study it).
Why would a normal person umount other partitions, there is no reason really. And the install procedure /might/ install things appropriate for those mounts or apply configs or who knows.
Yes, as I wrote in my followup to Patrick Shanahan, I've done online upgrades with other mounted partitions, but never btrfs partitions. After I looked through the bug reports, I thought it was rather irresponsible that no mention of this is on the upgrade web page, which I was following.
Yes, there should be a note; maybe few people have seen this problem and the people writing them were not aware. You could open a bugzilla on that documentation or release notes issue.
But having btrfs installed, I have my doubts.
I don't follow. You doubt it will help to kill the btrfs-defrag-plugin.py process, but it's ok to try? Or do you think it could do damage to the btrfs system or cause some other problem?
I fear that it could be problematic to kill it, I'm unsure.
And what about killing 'try-restart btrfsmaintenance-refresh.service'? What if I try to unmount the btrfs partition now? Or is it too late?
I don't know.
Till now, all occurrences of this problem was to people with no btrfs partition.
Maybe, there being no CPU activity, and little disk activity, you could kill the processes affected. First defrag (it is a guess), and last the systemctl service. I'm hopping here that the service then continues and the rpm script thinks things succeeded and continues with next part.
As I wrote in my other followup, I did kill the process and the installation then completed and Leap 15.1 seems to be fine. But as I also wrote, my ill-informed attempt to unmount the TW partition resulted in blowing it away, so I have to reinstall it.
Gosh :-( Next time, umount it with the option "--lazy", then wait patiently. "lsof" may tell you what program is using it. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)