[opensuse-factory] Leap 15.1 Build 468.7 released!
Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here. Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&version=15.1&build=468.7&groupid=50 https://bugzilla.opensuse.org/buglist.cgi?product=openSUSE%20Distribution&query_format=advanced&resolution=---&version=Leap%2015.1 When you reply to discuss some issues, make sure to change the subject. Please use the test plan at https://docs.google.com/spreadsheets/d/1AGKijKpKiJCB616-bHVoNQuhWHpQLHPWCb3m... to record your testing efforts and use bugzilla to report bugs. Packages changed: kmail yast2-country (4.1.11 -> 4.1.12) === Details === ==== kmail ==== Subpackages: kmail-application-icons kmail-lang ktnef - Add upstream patches to fix "Move to Trash" action in the scam detection menu permanently deleting the mails instead of moving them to the trash (kde#406324): * Fix-bug-406324-move-really-to-trash.patch * Fix-bug-406324-fix-connect-signal_slot-error.patch ==== yast2-country ==== Version update (4.1.11 -> 4.1.12) Subpackages: yast2-country-data - Fix: Keyboard language cannot be changed in textmode (bsc#1120957). - 4.1.12 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 11.05.19 um 13:00 schrieb Ludwig Nussel:
Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here.
Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&version=15.1&build=468.7&groupid=50 https://bugzilla.opensuse.org/buglist.cgi?product=openSUSE%20Distribution&query_format=advanced&resolution=---&version=Leap%2015.1
I just tried 'zypper dup' for an existing Leap 15.0 system. No extra repos, just OSS and OSS Updates for Leap 15.1. The original 15.0 system was rather small (~ 800 RPMs). 'zypper dup' went okay up to --- snip ---- (761/898) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .......<100%>[\] --- snap --- where it hung indefinitely at trying to restart some BTRFS related services. The machine in question, however, does not use BTRFS at all: --- snip --- box:~ # grep btr /etc/fstab box:~ # mount | grep btr box:~ # --- snap --- To me it appears as if /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 was waiting (indefinitely) for input on a pipe. After killing that systemctl, installation moved on, w/o any apparent problem. Below is a bit more of my ad-hoc analysis. A quick Bugzilla search did not give me any hits. Is this worth pursuing? HTH -- Till --- snip --- (761/898) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .............................................<100%>[\] box:~ # ps auxwww [...] root 8446 0.0 0.1 57256 9332 pts/1 S+ 13:44 0:00 rpm --root / --dbpath /var/lib/rpm -U --percent --noglob --force --nodeps -- /var/cache/zypp/packages/deflektor_oss/noarch/btrfsmaintenance-0.4.2-lp151.1.1.noarch.rpm root 8496 0.0 0.0 11980 2816 pts/1 S+ 13:44 0:00 /bin/sh /var/tmp/rpm-tmp.WnJcBQ 1 root 8531 0.0 0.0 11980 1904 pts/1 S+ 13:44 0:00 /bin/sh /var/tmp/rpm-tmp.WnJcBQ 1 root 8532 0.0 0.0 60224 6164 pts/1 S+ 13:44 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 box:~ # lsof -p 8532 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME systemctl 8532 root cwd DIR 254,2 4096 2 / systemctl 8532 root rtd DIR 254,2 4096 2 / systemctl 8532 root txt REG 254,2 182416 531004 /usr/bin/systemctl systemctl 8532 root mem REG 254,2 1356080 3932198 /lib64/libm-2.26.so systemctl 8532 root mem REG 254,2 141560 533143 /usr/lib64/libudev.so.1.6.6 systemctl 8532 root mem REG 254,2 64208 530729 /usr/lib64/libjson-c.so.3.0.1 systemctl 8532 root mem REG 254,2 30896 525373 /usr/lib64/libargon2.so.1 systemctl 8532 root mem REG 254,2 354144 528070 /usr/lib64/libdevmapper.so.1.03 systemctl 8532 root mem REG 254,2 30840 524568 /usr/lib64/libuuid.so.1.3.0 systemctl 8532 root mem REG 254,2 18824 3932195 /lib64/libattr.so.1.1.0 systemctl 8532 root mem REG 254,2 575808 524531 /usr/lib64/libpcre.so.1.2.9 systemctl 8532 root mem REG 254,2 337224 530647 /usr/lib64/libcryptsetup.so.12.3.0 systemctl 8532 root mem REG 254,2 338976 525529 /usr/lib64/libblkid.so.1.1.0 systemctl 8532 root mem REG 254,2 268576 524634 /usr/lib64/libseccomp.so.2.3.2 systemctl 8532 root mem REG 254,2 35424 3932224 /lib64/libacl.so.1.1.2253 systemctl 8532 root mem REG 254,2 130208 530939 /usr/lib64/libgpg-error.so.0.24.0 systemctl 8532 root mem REG 254,2 18616 3932192 /lib64/libdl-2.26.so systemctl 8532 root mem REG 254,2 1164832 529454 /usr/lib64/libgcrypt.so.20.2.2 systemctl 8532 root mem REG 254,2 84352 525302 /usr/lib64/liblz4.so.1.8.0 systemctl 8532 root mem REG 254,2 235576 525270 /usr/lib64/liblzma.so.5.2.3 systemctl 8532 root mem REG 254,2 97200 3932312 /lib64/libresolv-2.26.so systemctl 8532 root mem REG 254,2 42120 3934078 /lib64/librt-2.26.so systemctl 8532 root mem REG 254,2 18984 526567 /usr/lib64/libcap.so.2.25 systemctl 8532 root mem REG 254,2 159456 3934083 /lib64/libselinux.so.1 systemctl 8532 root mem REG 254,2 2034848 3932178 /lib64/libc-2.26.so systemctl 8532 root mem REG 254,2 140688 3932289 /lib64/libpthread-2.26.so systemctl 8532 root mem REG 254,2 2302168 531028 /usr/lib/systemd/libsystemd-shared-234.so systemctl 8532 root mem REG 254,2 180056 3934066 /lib64/ld-2.26.so systemctl 8532 root 0r FIFO 0,12 0t0 50830 pipe systemctl 8532 root 1w FIFO 0,12 0t0 52546 pipe systemctl 8532 root 2w FIFO 0,12 0t0 52546 pipe systemctl 8532 root 3u unix 0xffff8801f5e10400 0t0 50858 type=STREAM box:~ # strace -p 8532 strace: Process 8532 attached ppoll([{fd=3, events=POLLIN}], 1, NULL, NULL, 8 box:~ # ps -elf | head -1; ps -elf | egrep 'bt[r]|853[1]' F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 0 S root 3255 3225 0 80 0 - 8210 - 13:25 pts/1 00:00:00 /usr/bin/python3 /usr/lib/zypp/plugins/commit/btrfs-defrag-plugin.py 4 S root 8446 3225 0 80 0 - 14314 - 13:44 pts/1 00:00:00 rpm --root / --dbpath /var/lib/rpm -U --percent --noglob --force --nodeps -- /var/cache/zypp/packages/deflektor_oss/noarch/btrfsmaintenance-0.4.2-lp151.1.1.noarch.rpm 1 S root 8531 8496 0 80 0 - 2995 - 13:44 pts/1 00:00:00 /bin/sh /var/tmp/rpm-tmp.WnJcBQ 1 0 S root 8532 8531 0 80 0 - 15056 SyS_pp 13:44 pts/1 00:00: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 box:~ # systemctl | head -1; systemctl | grep btr UNIT LOAD ACTIVE SUB DESCRIPTION btrfsmaintenance-refresh.path loaded active waiting Watch /etc/sysconfig/btrfsmaintenance btrfs-balance.timer loaded active waiting Balance block groups on a btrfs filesystem btrfs-scrub.timer loaded active waiting Scrub btrfs filesystem, verify block checksums btrfs-trim.timer loaded active waiting Discard unused blocks on a mounted filesystem box:~ # cat /var/tmp/rpm-tmp.WnJcBQ test -n "$FIRST_ARG" || FIRST_ARG="$1" if [ "$FIRST_ARG" -ge 1 ]; then # Package upgrade, not uninstall if [ -x /usr/bin/systemctl ]; then /usr/bin/systemctl daemon-reload || : ( test "$YAST_IS_RUNNING" = instsys && exit 0 test -f /etc/sysconfig/services -a \ -z "$DISABLE_RESTART_ON_UPDATE" && . /etc/sysconfig/services test "$DISABLE_RESTART_ON_UPDATE" = yes -o \ "$DISABLE_RESTART_ON_UPDATE" = 1 && exit 0 /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 ) || : fi else # package uninstall for service in 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 ; do sysv_service="${service%.*}" rm -f "/var/lib/systemd/migrated/$sysv_service" || : done if [ -x /usr/bin/systemctl ]; then /usr/bin/systemctl daemon-reload || : fi fi # did not terminate process box:~ # kill 8532 # did work box:~ # kill -9 8532 --- snap --- -- Dipl.-Inform. Till Dörges doerges@pre-sense.de Tel. +49 - 40 - 244 2407 - 0 Fax +49 - 40 - 244 2407 - 24 PRESENSE Technologies GmbH Sachsenstr. 5, D-20097 HH Geschäftsführer/Managing Directors AG Hamburg, HRB 107844 Till Dörges, Jürgen Sander USt-IdNr.: DE263765024 Wir sind wieder auf dem BSI IT-Sicherheitskongress 21.-23. Mai 2019 – Bonn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 5/13/19 2:49 PM, Till Dörges wrote:
Am 11.05.19 um 13:00 schrieb Ludwig Nussel:
Please note that this mail was generated by a script. The described changes are computed based on the x86_64 DVD. The full online repo contains too many changes to be listed here.
Please check the known defects of this snapshot before upgrading: https://openqa.opensuse.org/tests/overview?distri=opensuse&version=15.1&build=468.7&groupid=50 https://bugzilla.opensuse.org/buglist.cgi?product=openSUSE%20Distribution&query_format=advanced&resolution=---&version=Leap%2015.1
I just tried 'zypper dup' for an existing Leap 15.0 system. No extra repos, just OSS and OSS Updates for Leap 15.1. The original 15.0 system was rather small (~ 800 RPMs).
'zypper dup' went okay up to
--- snip ---- (761/898) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .......<100%>[\] --- snap ---
Yes, there is some type of a race condition there or maybe some corner case. It was noticed last year already, but it's difficult to get reproducer, https://bugzilla.suse.com/show_bug.cgi?id=1110259
To me it appears as if
/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
was waiting (indefinitely) for input on a pipe. After killing that systemctl, installation moved on, w/o any apparent problem.
Exactly. I've had this occur exactly 1 time in a VM and I've tried reproducing the issue and was unsuccessful. I also do not use btrfs.
Below is a bit more of my ad-hoc analysis. A quick Bugzilla search did not give me any hits.
Is this worth pursuing?
Yes :D - Adam -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Mon, May 13, 2019 at 4:09 PM Adam Majer <amajer@suse.de> wrote:
Yes, there is some type of a race condition there or maybe some corner case. It was noticed last year already, but it's difficult to get reproducer,
Access denied. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 5/13/19 3:30 PM, Andrei Borzenkov wrote:
On Mon, May 13, 2019 at 4:09 PM Adam Majer <amajer@suse.de> wrote:
Yes, there is some type of a race condition there or maybe some corner case. It was noticed last year already, but it's difficult to get reproducer,
Access denied.
Moved it back to openSUSE so it's open again. - Adam -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Am 13.05.19 um 15:09 schrieb Adam Majer:
Yes, there is some type of a race condition there or maybe some corner case. It was noticed last year already, but it's difficult to get reproducer,
Exactly. I've had this occur exactly 1 time in a VM and I've tried reproducing the issue and was unsuccessful. I also do not use btrfs.
Okay, it was in a VM here, too. I still have the snapshot I started 'zypper dup' from. I can try to reproduce.
Below is a bit more of my ad-hoc analysis. A quick Bugzilla search did not give me any hits.
Is this worth pursuing?
Yes :D
I updated the bug with my bits. Assuming I manage to reproduce it: What kind of information do you need for debugging this further? TIA -- Till -- Dipl.-Inform. Till Dörges doerges@pre-sense.de Tel. +49 - 40 - 244 2407 - 0 Fax +49 - 40 - 244 2407 - 24 PRESENSE Technologies GmbH Sachsenstr. 5, D-20097 HH Geschäftsführer/Managing Directors AG Hamburg, HRB 107844 Till Dörges, Jürgen Sander USt-IdNr.: DE263765024 Wir sind wieder auf dem BSI IT-Sicherheitskongress 21.-23. Mai 2019 – Bonn -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 5/13/19 4:19 PM, Till Dörges wrote:
Assuming I manage to reproduce it: What kind of information do you need for debugging this further?
A minimal (-ish) reproducer. If you can have something like, 1. install this 2. do that and then you get 10% or 50% or 100% of the time the problem, it would allow us or others to pinpoint the cause. A problem that occurs in isolation is not so good. If you can reproduce it, run supportconfig and attach the rpm.txt of report tarball before and also after update (from the supportconfig generated) to the bug report. - Adam -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 13/05/2019 15.09, Adam Majer wrote:
On 5/13/19 2:49 PM, Till Dörges wrote:
I just tried 'zypper dup' for an existing Leap 15.0 system. No extra repos, just OSS and OSS Updates for Leap 15.1. The original 15.0 system was rather small (~ 800 RPMs).
'zypper dup' went okay up to
--- snip ---- (761/898) Installing: btrfsmaintenance-0.4.2-lp151.1.1.noarch .......<100%>[\] --- snap ---
Yes, there is some type of a race condition there or maybe some corner case. It was noticed last year already, but it's difficult to get reproducer,
It happened to me as well last year. I also wrote a bugzilla. It was a VM, I tried several times to repeat the procedure to capture more data, but it did not happen :-( -- Cheers / Saludos, Carlos E. R. (from openSUSE, Leap 15.1 x86_64 (ssd-test)) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Adam Majer
-
Andrei Borzenkov
-
Carlos E. R.
-
Ludwig Nussel
-
Till Dörges