[opensuse] zypper dup to 15.1 hanging
I started an upgrade from 15.0 to 15.1 following the instructions on this page: https://en.opensuse.org/SDB:System_upgrade All packages were download and the installation proceeded, but about half an hour ago, it appears to have gotten hung up at this point: (3814/4940) Installing: zypper-needs-restarting-1.14.27-lp151.1.2.noarch ............................................[done] (3815/4940) Installing: zypper-lifecycle-plugin-0.6.1490613702.a925823-lp151.3.1.noarch .............................[done] Additional rpm output: Updating /etc/sysconfig/lifecycle-report ... (3816/4940) Installing: zypper-aptitude-1.14.27-lp151.1.2.noarch ....................................................[done] (3817/4940) Installing: libzypp-plugin-appdata-1.0.1+git.20180426-lp151.3.1.noarch ..................................[done] (3818/4940) Installing: SUSEConnect-0.3.16-lp151.1.1.x86_64 .........................................................[done] (3819/4940) Installing: yast2-4.1.69-lp151.1.1.x86_64 ...............................................................[done] Additional rpm output: Updating /etc/sysconfig/yast2 ... (3820/4940) Installing: snapper-zypp-plugin-0.8.3-lp151.1.1.noarch ..................................................[done] (3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-] The last messages in /var/log/zypper.log are these: 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp] RpmHeader.cc(readPackage):252 ReferenceCounted(@0x561efd2e2830<=1){0x561efd2f3ed0}{snapper-zypp-plugin-0.8.3-lp151.1.1} from /var/cache/zypp/packages/repo-oss/noarch/snapper-zypp-plugin-0.8.3-lp151.1.1.noarch.rpm 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp] RpmDb.cc(doInstallPackage):1992 RpmDb::installPackage(/var/cache/zypp/packages/repo-oss/noarch/snapper-zypp-plugin-0.8.3-lp151.1.1.noarch.rpm,0x0000000c) 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp::exec++] ExternalProgram.cc(start_program):259 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--noglob' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-oss/noarch/snapper-zypp-plugin-0.8.3-lp151.1.1.noarch.rpm' 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp::exec++] ExternalProgram.cc(start_program):424 pid 18710 launched 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp::exec++] ExternalProgram.cc(checkStatus):528 Pid 18710 successfully completed 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [Progress++] ProgressData.cc(report):88 {#8748|Installing: snapper-zypp-plugin-0.8.3-lp151.1.1.noarch}END 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp] PathInfo.cc(unlink):659 unlink /var/cache/zypp/packages/repo-oss/noarch/snapper-zypp-plugin-0.8.3-lp151.1.1.noarch.rpm 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp] RpmHeader.cc(readPackage):252 ReferenceCounted(@0x561efd2e2830<=1){0x561efd2f5db0}{btrfsmaintenance-0.4.2-lp151.1.1} from /var/cache/zypp/packages/repo-oss/noarch/btrfsmaintenance-0.4.2-lp151.1.1.noarch.rpm 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp] RpmDb.cc(doInstallPackage):1992 RpmDb::installPackage(/var/cache/zypp/packages/repo-oss/noarch/btrfsmaintenance-0.4.2-lp151.1.1.noarch.rpm,0x0000000c) 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp::exec++] ExternalProgram.cc(start_program):259 Executing 'rpm' '--root' '/' '--dbpath' '/var/lib/rpm' '-U' '--percent' '--noglob' '--force' '--nodeps' '--' '/var/cache/zypp/packages/repo-oss/noarch/btrfsmaintenance-0.4.2-lp151.1.1.noarch.rpm' 2019-05-23 12:41:43 <1> linux-tuxedo(7810) [zypp::exec++] ExternalProgram.cc(start_program):424 pid 18711 launched Nothing since and no other relevant messages that I can find. What should I do? Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23/05/2019 13.14, Stephen Berman wrote:
I started an upgrade from 15.0 to 15.1 following the instructions on
...
(3820/4940) Installing: snapper-zypp-plugin-0.8.3-lp151.1.1.noarch ..................................................[done] (3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
Are you using btrfs? If not, there is a btrfs related process that you can kill. Have a look with "top" or "ps afxu | less -S" If you are using btrfs I think you have to wait it out. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Thu, 23 May 2019 13:18:43 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 23/05/2019 13.14, Stephen Berman wrote:
I started an upgrade from 15.0 to 15.1 following the instructions on
...
(3820/4940) Installing: snapper-zypp-plugin-0.8.3-lp151.1.1.noarch ..................................................[done] (3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
Are you using btrfs? If not, there is a btrfs related process that you can kill. Have a look with "top" or "ps afxu | less -S"
If you are using btrfs I think you have to wait it out.
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: root 8265 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-worker] root 8267 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-worker-hi] root 8268 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-delalloc] root 8269 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-flush_del] root 8270 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-cache] root 8271 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-submit] root 8272 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-fixup] root 8273 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-endio] root 8274 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-endio-met] root 8275 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-endio-met] root 8276 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-endio-rai] root 8277 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-endio-rep] root 8278 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-rmw] root 8279 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-endio-wri] root 8280 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-freespace] root 8281 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-delayed-m] root 8282 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-readahead] root 8283 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-qgroup-re] root 8284 0.0 0.0 0 0 ? S< 10:59 0:00 \_ [btrfs-extent-re] root 8285 0.0 0.0 0 0 ? S 10:59 0:00 \_ [btrfs-cleaner] root 8286 0.0 0.0 0 0 ? S 10:59 0:00 \_ [btrfs-transacti] steve 20012 0.0 0.0 8688 812 pts/1 S+ 13:23 0:00 | \_ grep --color=auto -i btrfs root 7855 0.2 0.0 32984 10268 pts/3 S+ 10:49 0:25 \_ /usr/bin/python3 /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py root 18711 0.0 0.0 57432 9840 pts/3 S+ 12:41 0:00 \_ rpm --root / --dbpath /var/lib/rpm -U --percent --noglob --force --nodeps -- /var/cache/zypp/packages/repo-oss/noarch/btrfsmaintenance-0.4.2-lp151.1.1.noarch.rpm root 18786 0.0 0.0 60620 6816 pts/3 S+ 12:41 0:00 \_ /usr/bin/systemctl try-restart btrfsmaintenance-refresh.service btrfsmaintenance-refresh.path btrfs-balance.service btrfs-balance.timer btrfs-defrag.service btrfs-defrag.timer btrfs-scrub.service btrfs-scrub.timer btrfs-trim.service btrfs-trim.timer On Thu, 23 May 2019 14:21:07 +0300 Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Thu, May 23, 2019 at 2:14 PM Stephen Berman <stephen.berman@gmx.net> wrote:
(3820/4940) Installing: snapper-zypp-plugin-0.8.3-lp151.1.1.noarch ..................................................[done] (3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
https://bugzilla.opensuse.org/show_bug.cgi?id=1110259 https://bugzilla.opensuse.org/show_bug.cgi?id=1130702
Ah, so I should do 'kill -9 18786' ? Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23/05/2019 13.33, Stephen Berman wrote:
On Thu, 23 May 2019 13:18:43 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 23/05/2019 13.14, Stephen Berman wrote:
I started an upgrade from 15.0 to 15.1 following the instructions on
...
(3820/4940) Installing: snapper-zypp-plugin-0.8.3-lp151.1.1.noarch ..................................................[done] (3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
Are you using btrfs? If not, there is a btrfs related process that you can kill. Have a look with "top" or "ps afxu | less -S"
If you are using btrfs I think you have to wait it out.
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.
root 8286 0.0 0.0 0 0 ? S 10:59 0:00 \_ [btrfs-transacti] steve 20012 0.0 0.0 8688 812 pts/1 S+ 13:23 0:00 | \_ grep --color=auto -i btrfs root 7855 0.2 0.0 32984 10268 pts/3 S+ 10:49 0:25 \_ /usr/bin/python3 /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py root 18711 0.0 0.0 57432 9840 pts/3 S+ 12:41 0:00 \_ rpm --root / --dbpath /var/lib/rpm -U --percent --noglob --force --nodeps -- /var/cache/zypp/packages/repo-oss/noarch/btrfsmaintenance-0.4.2-lp151.1.1.noarch.rpm root 18786 0.0 0.0 60620 6816 pts/3 S+ 12:41 0:00 \_ /usr/bin/systemctl try-restart btrfsmaintenance-refresh.service btrfsmaintenance-refresh.path btrfs-balance.service btrfs-balance.timer btrfs-defrag.service btrfs-defrag.timer btrfs-scrub.service btrfs-scrub.timer btrfs-trim.service btrfs-trim.timer
It is the "btrfs-defrag-plugin.py" that is hung, I think. Check cpu load with "top". But having btrfs installed, I have my doubts. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Thu, 23 May 2019 13:40:06 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 23/05/2019 13.33, Stephen Berman wrote:
On Thu, 23 May 2019 13:18:43 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 23/05/2019 13.14, Stephen Berman wrote:
I started an upgrade from 15.0 to 15.1 following the instructions on
...
(3820/4940) Installing: snapper-zypp-plugin-0.8.3-lp151.1.1.noarch ..................................................[done] (3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
Are you using btrfs? If not, there is a btrfs related process that you can kill. Have a look with "top" or "ps afxu | less -S"
If you are using btrfs I think you have to wait it out.
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.
root 8286 0.0 0.0 0 0 ? S 10:59 0:00 \_ [btrfs-transacti] steve 20012 0.0 0.0 8688 812 pts/1 S+ 13:23 0:00 | \_ grep --color=auto -i btrfs root 7855 0.2 0.0 32984 10268 pts/3 S+ 10:49 0:25 \_ /usr/bin/python3 /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py root 18711 0.0 0.0 57432 9840 pts/3 S+ 12:41 0:00 \_ rpm --root / --dbpath /var/lib/rpm -U --percent --noglob --force --nodeps -- /var/cache/zypp/packages/repo-oss/noarch/btrfsmaintenance-0.4.2-lp151.1.1.noarch.rpm root 18786 0.0 0.0 60620 6816 pts/3 S+ 12:41 0:00 \_ /usr/bin/systemctl try-restart btrfsmaintenance-refresh.service btrfsmaintenance-refresh.path btrfs-balance.service btrfs-balance.timer btrfs-defrag.service btrfs-defrag.timer btrfs-scrub.service btrfs-scrub.timer btrfs-trim.service btrfs-trim.timer
It is the "btrfs-defrag-plugin.py" that is hung, I think. Check cpu load with "top".
Do you mean this: top - 13:47:06 up 4:50, 5 users, load average: 1.40, 1.39, 1.37 Tasks: 309 total, 1 running, 308 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.7 us, 1.7 sy, 0.0 ni, 95.5 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st KiB Mem : 16277548 total, 4992968 free, 1674488 used, 9610092 buff/cache KiB Swap: 8391680 total, 8391680 free, 0 used. 13953376 avail Mem
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? And what about killing 'try-restart btrfsmaintenance-refresh.service'? What if I try to unmount the btrfs partition now? Or is it too late? Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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. ...
It is the "btrfs-defrag-plugin.py" that is hung, I think. Check cpu load with "top".
Do you mean this:
top - 13:47:06 up 4:50, 5 users, load average: 1.40, 1.39, 1.37 Tasks: 309 total, 1 running, 308 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.7 us, 1.7 sy, 0.0 ni, 95.5 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st KiB Mem : 16277548 total, 4992968 free, 1674488 used, 9610092 buff/cache KiB Swap: 8391680 total, 8391680 free, 0 used. 13953376 avail Mem
CPU load is almost nil, so it that tells us nothing this time. But it maybe it would be interesting to see a few more lines. Maybe, as mentioned by Aaron there is a lot of i/o, but I have my doubts because you have "0.0 wa", ie, cpu waiting on i/o. To make sure, you could use "iotop" instead, but this command is not typically installed - and with rpm stuck you can not install anything else.
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. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
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.
It is the "btrfs-defrag-plugin.py" that is hung, I think. Check cpu load with "top".
Do you mean this:
top - 13:47:06 up 4:50, 5 users, load average: 1.40, 1.39, 1.37 Tasks: 309 total, 1 running, 308 sleeping, 0 stopped, 0 zombie %Cpu(s): 2.7 us, 1.7 sy, 0.0 ni, 95.5 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st KiB Mem : 16277548 total, 4992968 free, 1674488 used, 9610092 buff/cache KiB Swap: 8391680 total, 8391680 free, 0 used. 13953376 avail Mem
CPU load is almost nil, so it that tells us nothing this time. But it maybe it would be interesting to see a few more lines.
Maybe, as mentioned by Aaron there is a lot of i/o, but I have my doubts because you have "0.0 wa", ie, cpu waiting on i/o. To make sure, you could use "iotop" instead, but this command is not typically installed - and with rpm stuck you can not install anything else.
Right, iotop is not (yet) installed here.
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. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
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)
On Thu, 23 May 2019 22:28:41 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
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.
Since the issue has been known for so long, even if it's not reliably reproducible, and still wasn't deemed worth mentioning on the upgrade page, I doubt opening a bug it will change that. But maybe I'll try anyway.
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.
Thanks. Live and learn. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23/05/2019 23.23, Stephen Berman wrote:
On Thu, 23 May 2019 22:28:41 +0200 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 23/05/2019 22.05, Stephen Berman wrote:
On Thu, 23 May 2019 18:49:13 +0200 "Carlos E. R." <> 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.
Since the issue has been known for so long, even if it's not reliably reproducible, and still wasn't deemed worth mentioning on the upgrade page, I doubt opening a bug it will change that. But maybe I'll try anyway.
Yes, someone has to ask the note to be written. I could have been me, but I forgot. The thing is, you can do it a thousand times and it doesn't happen, so you think it has disappeared, and then another person says it happened to him :-(
Next time, umount it with the option "--lazy", then wait patiently.
"lsof" may tell you what program is using it.
Thanks. Live and learn.
Welcome. Yes, it is called experience. I have experienced a bunch of disasters. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On Thu, May 23, 2019 at 2:14 PM Stephen Berman <stephen.berman@gmx.net> wrote:
(3820/4940) Installing: snapper-zypp-plugin-0.8.3-lp151.1.1.noarch ..................................................[done] (3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
https://bugzilla.opensuse.org/show_bug.cgi?id=1110259 https://bugzilla.opensuse.org/show_bug.cgi?id=1130702 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thursday, May 23, 2019 13:14 CEST, Stephen Berman <stephen.berman@gmx.net> wrote:
(3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
Check which processes are running. It's quite possible that the installer script has started some btrfs maintenance (balancing and scrubbing). Depending on many factors, this can take half an hour or more. In the mean time, you should see a lot of I/O to your disks. Regards, -- Aaron "Optimizer" Digulla a.k.a. Philmann Dark "It's not the universe that's limited, it's our imagination. Follow me and I'll show you something beyond the limits." http://blog.pdark.de/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 23 May 2019 13:58:39 +0200 "Aaron Digulla" <digulla@hepe.com> wrote:
On Thursday, May 23, 2019 13:14 CEST, Stephen Berman <stephen.berman@gmx.net> wrote:
(3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
Check which processes are running. It's quite possible that the installer script has started some btrfs maintenance (balancing and scrubbing).
Does that apply to a non-root partition? As I mentioned in another reply, Leap is on ext4 but I also have TW on btfs and it's mounted under Leap.
Depending on many factors, this can take half an hour or more. In the mean time, you should see a lot of I/O to your disks.
I don't think there is a lot of I/O, going by the top info I posted in another reply. And the hangup is now more than 90 minutes. Can I safely kill the btrfs-maintenance process? Should I first unmount the btrfs partition? And if I can't? Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Stephen Berman <stephen.berman@gmx.net> [05-23-19 08:16]:
On Thu, 23 May 2019 13:58:39 +0200 "Aaron Digulla" <digulla@hepe.com> wrote:
On Thursday, May 23, 2019 13:14 CEST, Stephen Berman <stephen.berman@gmx.net> wrote:
(3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
Check which processes are running. It's quite possible that the installer script has started some btrfs maintenance (balancing and scrubbing).
Does that apply to a non-root partition? As I mentioned in another reply, Leap is on ext4 but I also have TW on btfs and it's mounted under Leap.
Depending on many factors, this can take half an hour or more. In the mean time, you should see a lot of I/O to your disks.
I don't think there is a lot of I/O, going by the top info I posted in another reply. And the hangup is now more than 90 minutes. Can I safely kill the btrfs-maintenance process? Should I first unmount the btrfs partition? And if I can't?
you probably cannot umount the partition as it will be busy. a reboot would be the only solution. but do you really need that drastic a solution? is the process causing you that much difficulty that you cannot allow it to continue for an hour or two? next time you do an "install", leave any not absolutely required processes to be added after the install is completed when you can revert changes safely and easily w/o harm, ie: mounting a partition not necessary for the install (easy to add after install completed). -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Thu, 23 May 2019 09:39:50 -0400 Patrick Shanahan <paka@opensuse.org> wrote:
* Stephen Berman <stephen.berman@gmx.net> [05-23-19 08:16]:
On Thu, 23 May 2019 13:58:39 +0200 "Aaron Digulla" <digulla@hepe.com> wrote:
On Thursday, May 23, 2019 13:14 CEST, Stephen Berman <stephen.berman@gmx.net> wrote:
(3821/4940) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .....................<48%>==============================[-]
Check which processes are running. It's quite possible that the installer script has started some btrfs maintenance (balancing and scrubbing).
Does that apply to a non-root partition? As I mentioned in another reply, Leap is on ext4 but I also have TW on btfs and it's mounted under Leap.
Depending on many factors, this can take half an hour or more. In the mean time, you should see a lot of I/O to your disks.
I don't think there is a lot of I/O, going by the top info I posted in another reply. And the hangup is now more than 90 minutes. Can I safely kill the btrfs-maintenance process? Should I first unmount the btrfs partition? And if I can't?
you probably cannot umount the partition as it will be busy. a reboot would be the only solution. but do you really need that drastic a solution? is the process causing you that much difficulty that you cannot allow it to continue for an hour or two?
I waited 2.5 hours and, since programs in the running system were becoming unusable due to the incomplete installation, decided to kill the btrfs-maintenance process, and immediately the installation proceeded and finished, and I rebooted into Leap 15.1 and it seems to be fine. However,...
next time you do an "install", leave any not absolutely required processes to be added after the install is completed when you can revert changes safely and easily w/o harm, ie: mounting a partition not necessary for the install (easy to add after install completed).
Yes this was a mistake. I've done online upgrades of previous openSUSE installations and if memory serves other systems were mounted and there were no problems, so it didn't occur to me to do otherwise now. But I've also never had a system on btrfs before. After the upgrade to 15.1 completed, I decided to remove the TW mount point, but the YaST partitioner wouldn't let me do it, saying the partition is busy. In my ignorance of btrfs I thought deleting the subvolumes might help, since these are also listed in /etc/fstab. And indeed, after deleting them, I could unmount the partition. But trying to boot TW failed with the error "file `/@/.snapshots/1/snapshot/boot/vmlinuz-5.1.3-1-default' not found." Evidently, deleting the subvolumes in the YaST partitioner blew TW away: I can mount the partition in Leap, but it is virtually empty (it contains the directories /boot, /etc and /usr, but the only nondirectory file is /etc/snapper/configs/root), and running btrfs restore on the unmounted partition saves these files and nothing else. So I have to reinstall TW. Steve Berman -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
What a lot of people have been asking in the past over and over again, pretty much ever since these btrfs and scripts started coming into existence, is, that why are they being executed and even used on non btrfs situations and machines? Please suse folks, what a shame, why are you wasting my cpu for exactly one minute on a zypper dup towards the end when i have nowhere on this machine anything with btrfs or even half a mile around this place. How come there is btrfsdefrag .pl something and some second related script? why oh why is btrfs trying to mess with stuff when there is no btrfs at all? :( -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 24/05/2019 09.46, cagsm wrote:
What a lot of people have been asking in the past over and over again, pretty much ever since these btrfs and scripts started coming into existence, is, that why are they being executed and even used on non btrfs situations and machines?
Please suse folks, what a shame, why are you wasting my cpu for exactly one minute on a zypper dup towards the end when i have nowhere on this machine anything with btrfs or even half a mile around this place.
How come there is btrfsdefrag .pl something and some second related script? why oh why is btrfs trying to mess with stuff when there is no btrfs at all? :(
Yes, they should detect the situation and exit. Maybe this script crashes while verifying the situation. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
cagsm wrote:
What a lot of people have been asking in the past over and over again, pretty much ever since these btrfs and scripts started coming into existence, is, that why are they being executed and even used on non btrfs situations and machines?
Please suse folks, what a shame, why are you wasting my cpu for exactly one minute on a zypper dup towards the end when i have nowhere on this machine anything with btrfs or even half a mile around this place.
FYI, it is easy to prevent - just deselect the btrfs stuff when you install. -- Per Jessen, Zürich (14.9°C) member, openSUSE Heroes -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 24/05/2019 10.11, Per Jessen wrote:
cagsm wrote:
What a lot of people have been asking in the past over and over again, pretty much ever since these btrfs and scripts started coming into existence, is, that why are they being executed and even used on non btrfs situations and machines?
Please suse folks, what a shame, why are you wasting my cpu for exactly one minute on a zypper dup towards the end when i have nowhere on this machine anything with btrfs or even half a mile around this place.
FYI, it is easy to prevent - just deselect the btrfs stuff when you install.
Well, it is one more task to add to the list; and some, like me, want the btrfs things installed just in case I some time connect an external partition with it, or install another linux in the same machine using btrfs - which is the case of the OP here. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
* cagsm <cumandgets0mem00f@gmail.com> [05-24-19 03:49]:
What a lot of people have been asking in the past over and over again, pretty much ever since these btrfs and scripts started coming into existence, is, that why are they being executed and even used on non btrfs situations and machines?
Please suse folks, what a shame, why are you wasting my cpu for exactly one minute on a zypper dup towards the end when i have nowhere on this machine anything with btrfs or even half a mile around this place.
How come there is btrfsdefrag .pl something and some second related script? why oh why is btrfs trying to mess with stuff when there is no btrfs at all? :(
yet you have lots of other unused filesystem particular packages installed and you don't complain about them, only btrfs, ie: fat/cramfs/minix/ext3/jfs/reiserfs/xfs if none of them were installed, you would also be complaining. how is anyone to determine which particular apps you want installed. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 24/05/2019 13.43, Patrick Shanahan wrote:
* cagsm <cumandgets0mem00f@gmail.com> [05-24-19 03:49]:
What a lot of people have been asking in the past over and over again, pretty much ever since these btrfs and scripts started coming into existence, is, that why are they being executed and even used on non btrfs situations and machines?
Please suse folks, what a shame, why are you wasting my cpu for exactly one minute on a zypper dup towards the end when i have nowhere on this machine anything with btrfs or even half a mile around this place.
How come there is btrfsdefrag .pl something and some second related script? why oh why is btrfs trying to mess with stuff when there is no btrfs at all? :(
yet you have lots of other unused filesystem particular packages installed and you don't complain about them, only btrfs, ie: fat/cramfs/minix/ext3/jfs/reiserfs/xfs
because none of them cause problems. None of them insist on running specific filesystem scripts on the filesystem that does not exist, and crashes. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
* Carlos E. R. <robin.listas@telefonica.net> [05-24-19 08:23]:
On 24/05/2019 13.43, Patrick Shanahan wrote:
* cagsm <cumandgets0mem00f@gmail.com> [05-24-19 03:49]:
What a lot of people have been asking in the past over and over again, pretty much ever since these btrfs and scripts started coming into existence, is, that why are they being executed and even used on non btrfs situations and machines?
Please suse folks, what a shame, why are you wasting my cpu for exactly one minute on a zypper dup towards the end when i have nowhere on this machine anything with btrfs or even half a mile around this place.
How come there is btrfsdefrag .pl something and some second related script? why oh why is btrfs trying to mess with stuff when there is no btrfs at all? :(
yet you have lots of other unused filesystem particular packages installed and you don't complain about them, only btrfs, ie: fat/cramfs/minix/ext3/jfs/reiserfs/xfs
because none of them cause problems. None of them insist on running specific filesystem scripts on the filesystem that does not exist, and crashes.
yet I have not experienced that on *any* of my non-btrfs systems. and you have explained multiple time that it is a bug which has yet to be definied as it is difficult or impossible to deliberately repeate. in this case why is btrfs being "singled out" for action different that other app's which have similar problems? just because it is a filesystem that appears to be greatly mis-understood? or a covert effort to defeate bfrtfs? -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 24/05/2019 14.30, Patrick Shanahan wrote:
* Carlos E. R. <> [05-24-19 08:23]:
On 24/05/2019 13.43, Patrick Shanahan wrote:
* cagsm <> [05-24-19 03:49]:
What a lot of people have been asking in the past over and over again, pretty much ever since these btrfs and scripts started coming into existence, is, that why are they being executed and even used on non btrfs situations and machines?
Please suse folks, what a shame, why are you wasting my cpu for exactly one minute on a zypper dup towards the end when i have nowhere on this machine anything with btrfs or even half a mile around this place.
How come there is btrfsdefrag .pl something and some second related script? why oh why is btrfs trying to mess with stuff when there is no btrfs at all? :(
yet you have lots of other unused filesystem particular packages installed and you don't complain about them, only btrfs, ie: fat/cramfs/minix/ext3/jfs/reiserfs/xfs
because none of them cause problems. None of them insist on running specific filesystem scripts on the filesystem that does not exist, and crashes.
yet I have not experienced that on *any* of my non-btrfs systems. and you have explained multiple time that it is a bug which has yet to be definied as it is difficult or impossible to deliberately repeate. in this case why is btrfs being "singled out" for action different that other app's which have similar problems? just because it is a filesystem that appears to be greatly mis-understood? or a covert effort to defeate bfrtfs?
Well, it happened to me. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 05/24/2019 07:30 AM, Patrick Shanahan wrote:
yet I have not experienced that on *any* of my non-btrfs systems. and you have explained multiple time that it is a bug which has yet to be definied as it is difficult or impossible to deliberately repeate. in this case why is btrfs being "singled out" for action different that other app's which have similar problems? just because it is a filesystem that appears to be greatly mis-understood? or a covert effort to defeate bfrtfs?
Patrick, Did you install without "Install Recommends"? What I noticed when I unchecked "Install Recommends" with the ext4 was all the snapper, and other brtfs related packages were then deselected -- which would help explain a lack of a btrfs related hang. You may have mentioned it earlier and I missed it. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* David C. Rankin <drankinatty@suddenlinkmail.com> [05-24-19 19:32]:
On 05/24/2019 07:30 AM, Patrick Shanahan wrote:
yet I have not experienced that on *any* of my non-btrfs systems. and you have explained multiple time that it is a bug which has yet to be definied as it is difficult or impossible to deliberately repeate. in this case why is btrfs being "singled out" for action different that other app's which have similar problems? just because it is a filesystem that appears to be greatly mis-understood? or a covert effort to defeate bfrtfs?
Patrick,
Did you install without "Install Recommends"? What I noticed when I unchecked "Install Recommends" with the ext4 was all the snapper, and other brtfs related packages were then deselected -- which would help explain a lack of a btrfs related hang.
You may have mentioned it earlier and I missed it.
zypper -v ref;zypper -v dup --no-r -d;zypper -v dup --no-r -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Patrick Shanahan <paka@opensuse.org> [05-24-19 19:48]:
* David C. Rankin <drankinatty@suddenlinkmail.com> [05-24-19 19:32]:
On 05/24/2019 07:30 AM, Patrick Shanahan wrote:
yet I have not experienced that on *any* of my non-btrfs systems. and you have explained multiple time that it is a bug which has yet to be definied as it is difficult or impossible to deliberately repeate. in this case why is btrfs being "singled out" for action different that other app's which have similar problems? just because it is a filesystem that appears to be greatly mis-understood? or a covert effort to defeate bfrtfs?
Patrick,
Did you install without "Install Recommends"? What I noticed when I unchecked "Install Recommends" with the ext4 was all the snapper, and other brtfs related packages were then deselected -- which would help explain a lack of a btrfs related hang.
You may have mentioned it earlier and I missed it.
zypper -v ref;zypper -v dup --no-r -d;zypper -v dup --no-r
following were installed but have not caused any problem: S | Name | Type | Version | Arch | Repository --+-----------------------+---------+------------------+--------+----------------------- i | btrfsmaintenance | package | 0.4.2-lp151.1.1 | noarch | openSUSE-Leap-15.1-Oss i | btrfsprogs | package | 4.19.1-lp151.3.1 | x86_64 | openSUSE-Leap-15.1-Oss i | btrfsprogs-udev-rules | package | 4.19.1-lp151.3.1 | noarch | openSUSE-Leap-15.1-Oss i | libbtrfs0 | package | 4.19.1-lp151.3.1 | x86_64 | openSUSE-Leap-15.1-Oss -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Registered Linux User #207535 @ http://linuxcounter.net Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (8)
-
Aaron Digulla -
Andrei Borzenkov -
cagsm -
Carlos E. R. -
David C. Rankin -
Patrick Shanahan -
Per Jessen -
Stephen Berman