New Tumbleweed snapshot 20210920 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&groupid=1&version=Tumbleweed&build=20210920
Please do not reply to this email to report issues, rather file a bug
on bugzilla.opensuse.org. For more information on filing bugs please
see https://en.opensuse.org/openSUSE:Submitting_bug_reports
Packages changed:
apache2-mod_php7
autofs
binutils (2.36 -> 2.37)
btrfsprogs (5.13.1 -> 5.14)
cronie
curl (7.78.0 -> 7.79.0)
drbd-utils
elfutils-debuginfod
ethtool (5.13 -> 5.14)
fwnn
gd (2.3.2 -> 2.3.3)
gimp
glibc (2.33 -> 2.34)
gnome-remote-desktop (40.0 -> 40.2)
gnome-video-effects
gstreamer (1.18.4 -> 1.18.5)
gstreamer-plugins-bad (1.18.4 -> 1.18.5)
gstreamer-plugins-base (1.18.4 -> 1.18.5)
gstreamer-plugins-good (1.18.4 -> 1.18.5)
gstreamer-plugins-libav (1.18.4 -> 1.18.5)
gstreamer-plugins-ugly (1.18.4 -> 1.18.5)
gthumb (3.10.4 -> 3.12.0)
guile
gzip (1.10 -> 1.11)
ibus-libpinyin (1.12.0 -> 1.12.1)
java-11-openjdk
kbd
kernel-source (5.14.2 -> 5.14.5)
kmod
less
libalternatives (1.1 -> 1.2+3.b848aad)
libgudev (234 -> 237)
libhugetlbfs
libinput (1.18.1 -> 1.19.0)
libpinyin (2.6.0 -> 2.6.1)
libvirt
mariadb (10.5.10 -> 10.6.4)
ncurses (6.2.20210814 -> 6.2.20210911)
nmap
ntfs-3g_ntfsprogs (2017.3.23 -> 2021.8.22)
pam (1.5.1 -> 1.5.2)
php7
pmdk (1.9 -> 1.11.0)
qca-qt5 (2.3.3 -> 2.3.4)
rygel (0.40.1 -> 0.40.2)
salt
supermin
suse-module-tools (16.0.9 -> 16.0.10+7)
vim (8.2.3360 -> 8.2.3408)
virt-manager
yast2 (4.4.17 -> 4.4.20)
yast2-bootloader (4.4.6 -> 4.4.7)
yast2-control-center (4.4.2 -> 4.4.3)
yast2-online-update (4.4.1 -> 4.4.3)
yast2-trans (84.87.20210828.fbeca8288d -> 84.87.20210914.a5d6b81b64)
=== Details ===
==== apache2-mod_php7 ====
- added patches
https://github.com/php/php-src/commit/b3646440b1808abf0874b6f89027ce53ec5da0...
+ php7-gd-removed-unused-constants.patch
==== autofs ====
- autofs-5.1.7-use-default-stack-size-for-threads.patch: Use default
stack size for threads (bsc#1189199)
==== binutils ====
Version update (2.36 -> 2.37)
Subpackages: libctf-nobfd0 libctf0
- Bump binutils-2.37-branch.diff: fixes PR28138.
- Use LTO & PGO build.
- Update to binutils 2.37:
* The GNU Binutils sources now requires a C99 compiler and library to
build.
* Support for the arm-symbianelf format has been removed.
* Support for Realm Management Extension (RME) for AArch64 has been
added.
* A new linker option '-z report-relative-reloc' for x86 ELF targets
has been added to report dynamic relative relocations.
* A new linker option '-z start-stop-gc' has been added to disable
special treatment of __start_*/__stop_* references when
- -gc-sections.
* A new linker options '-Bno-symbolic' has been added which will
cancel the '-Bsymbolic' and '-Bsymbolic-functions' options.
* The readelf tool has a new command line option which can be used to
specify how the numeric values of symbols are reported.
- -sym-base=0|8|10|16 tells readelf to display the values in base 8,
base 10 or base 16. A sym base of 0 represents the default action
of displaying values under 10000 in base 10 and values above that in
base 16.
* A new format has been added to the nm program. Specifying
'--format=just-symbols' (or just using -j) will tell the program to
only display symbol names and nothing else.
* A new command line option '--keep-section-symbols' has been added to
objcopy and strip. This stops the removal of unused section symbols
when the file is copied. Removing these symbols saves space, but
sometimes they are needed by other tools.
* The '--weaken', '--weaken-symbol' and '--weaken-symbols' options
supported by objcopy now make undefined symbols weak on targets that
support weak symbols.
* Readelf and objdump can now display and use the contents of .debug_sup
sections.
* Readelf and objdump will now follow links to separate debug info
files by default. This behaviour can be stopped via the use of the
new '-wN' or '--debug-dump=no-follow-links' options for readelf and
the '-WN' or '--dwarf=no-follow-links' options for objdump. Also
the old behaviour can be restored by the use of the
'--enable-follow-debug-links=no' configure time option.
The semantics of the =follow-links option have also been slightly
changed. When enabled, the option allows for the loading of symbol
tables and string tables from the separate files which can be used
to enhance the information displayed when dumping other sections,
but it does not automatically imply that information from the
separate files should be displayed.
If other debug section display options are also enabled (eg
'--debug-dump=info') then the contents of matching sections in both
the main file and the separate debuginfo file *will* be displayed.
This is because in most cases the debug section will only be present
in one of the files.
If however non-debug section display options are enabled (eg
'--sections') then the contents of matching parts of the separate
debuginfo file will *not* be displayed. This is because in most
cases the user probably only wanted to load the symbol information
from the separate debuginfo file. In order to change this behaviour
a new command line option --process-links can be used. This will
allow di0pslay options to applied to both the main file and any
separate debuginfo files.
* Nm has a new command line option: '--quiet'. This suppresses "no
symbols" diagnostic.
- Includes fixes for these CVEs:
bnc#1181452 aka CVE-2021-20197 aka PR26945
bnc#1183511 aka CVE-2021-20284 aka PR26931
bnc#1184620 aka CVE-2021-3487 aka PR26946
bnc#1184794 aka CVE-2020-35448 aka PR26574
- Rebased patches: binutils-build-as-needed.diff, binutils-fix-abierrormsg.diff,
binutils-fix-invalid-op-errata.diff, binutils-fix-relax.diff,
binutils-revert-nm-symversion.diff, binutils-revert-plt32-in-branches.diff
- Removed patches (are in upstream): ppc-ensure-undef-dynamic-weak-undefined.patch and
ppc-use-local-plt.patch.
- Add binutils-2.37-branch.diff.gz.
==== btrfsprogs ====
Version update (5.13.1 -> 5.14)
Subpackages: btrfsprogs-udev-rules libbtrfs0
- Update to 5.14
* convert:
* new option --uuid to copy, generate or set a given uuid
* improve output
* mkfs:
* allow to create degenerate raid0 (on 1 device) and raid10 (on 2 devices)
* image:
* improved error messages
* fix some alignment of restored image
* subvol delete: allow to delete by id when path is not resolvable
* check:
* require alignment of nodesize for 64k page systems
* detect and fix invalid block groups
* libbtrfs (deprecated):
* remove most exported symbols, leave only a few that are used by snapper
* no version change (still 0.1)
* remove btrfs-list.h, btrfsck.h
* fixes:
* reset generation of space v1 if v2 is used
* fi us: don't wrongly report missing device size when partition is not readable
* other:
* build: experimental features
* build: better detection of 64bit timestamp support for ext4
* corrupt-block: block group items
* new and updated tests
* refactoring
* experimental features:
* new image dump format, with data
==== cronie ====
Subpackages: cron
- Increase limit of allowed entries in crontab files to fix bsc#1187508
* cronie-1.5.7-increase_crontab_limit.patch
- Run spec-cleaner
- Remove cronie-rpmlintrc as the filter was unused
==== curl ====
Version update (7.78.0 -> 7.79.0)
Subpackages: libcurl4
- Temporarily disable flaky test 1184
* See https://github.com/curl/curl/issues/7725
- Update to 7.79.0: [bsc#1190213, CVE-2021-22945]
[bsc#1190373, CVE-2021-22946] [bsc#1190374, CVE-2021-22947]
* Changes:
- bearssl: support CURLOPT_CAINFO_BLOB
- http: consider cookies over localhost to be secure
- secure transport: support CURLINFO_CERTINFO
* Bugfixes:
- CVE-2021-22945: clear the leftovers pointer when sending succeeds
- CVE-2021-22946: do not ignore --ssl-reqd
- CVE-2021-22947: reject STARTTLS server response pipelining
- auth: do not append zero-terminator to authorisation id in kerberos
- auth: properly handle byte order in kerberos security message
- auth: use sasl authzid option in kerberos
- auth: we do not support a security layer after kerberos authentication
- c-hyper: deal with Expect: 100-continue combined with POSTFIELDS
- c-hyper: handle HTTP/1.1 => HTTP/1.0 downgrade on reused connection
- c-hyper: initial step for 100-continue support
- c-hyper: initial support for "dumping" 1xx HTTP responses
- curl-openssl.m4: show correct output for OpenSSL v3
- docs/MQTT: update state of username/password support
- docs: the security list is reached at security at curl.se now
- getparameter: fix the --local-port number parser
- hostip: Make Curl_ipv6works function independent of getaddrinfo
- http_proxy: fix the User-Agent inclusion in CONNECT
- http_proxy: fix user-agent and custom headers for CONNECT with hyper
- http_proxy: only wait for writable socket while sending request
- mailing lists: move from cool.haxx.se to lists.haxx.se
- mbedtls: avoid using a large buffer on the stack
- mbedTLS: initial 3.0.0 support
- ngtcp2: remove the acked_crypto_offset struct field init
- ngtcp2: replace deprecated functions with nghttp3_conn_shutdown_stream_read
- ngtcp2: reset the oustanding send buffer again when drained
- ngtcp2: rework the return value handling of ngtcp2_conn_writev_stream
- ngtcp2: stop buffering crypto data
- ngtcp2: utilize crypto API functions to simplify
- openssl: when creating a new context, there cannot be an old one
- scripts: invoke interpreters through /usr/bin/env
- tests/runtests.pl: cleanup copy&paste mistakes and unused code
- tests: be explicit about using 'python3' instead of 'python'
- tool/tests: fix potential year 2038 issues
- tool_operate: Fix --fail-early with parallel transfers
- x509asn1: fix heap over-read when parsing x509 certificates
* Rebase libcurl-ocloexec.patch
==== drbd-utils ====
- bsc#1190591, fail to start due to lack of /usr/var/run/drbd
==== elfutils-debuginfod ====
- Add harden_debuginfod.service.patch as
Automatic systemd hardening effort by the security team.
==== ethtool ====
Version update (5.13 -> 5.14)
- update to new upstream release 5.14
* Feature: do not silently ignore --json if unsupported
* Feature: support new message types in pretty print
==== fwnn ====
- Added hardening to systemd service(s) (bsc#1181400). Modified:
* fcwnn.service
* fkwnn.service
* ftwnn.service
* fwnn.service
==== gd ====
Version update (2.3.2 -> 2.3.3)
Subpackages: libgd3
- version update to 2.3.3 [bsc#1190400]
* update cmake to generate config.h in the build dir
* 2.3.3 release
* gdPutBuf return value check
* HEIF builds fail with latest distros
* segfault in heif tests due to missing label.heic
* Test failure avif/compare_avif_to_png with libavif-0.8.2
* imagecopyresampled() produce artifacts on transparent PNG
* Fixes to build v2.3.0 on Windows with MinGW-w64
* optimize option in gif animation causes segfault
* _gdContributionsCalc() always uses DEFAULT_BOX_RADIUS
* gdImageRotateInterpolated() converts the source image to truecolor
* CMake and Makefiles build broken on Windows
* gdImageScaleTwoPass() looses top row and left column
==== gimp ====
Subpackages: gimp-lang gimp-plugin-aa gimp-plugins-python libgimp-2_0-0 libgimpui-2_0-0
- Remove obsolete translation-update-upstream support
(jsc#SLE-21105).
==== glibc ====
Version update (2.33 -> 2.34)
Subpackages: glibc-32bit glibc-devel glibc-extra glibc-lang glibc-locale glibc-locale-base nscd
- Don't create separate debuginfo packages for cross packages
- ldconfig-leak-empty-paths.patch: ldconfig: avoid leak on empty paths in
config file
- gconv-parseconfdir-memory-leak.patch: gconv_parseconfdir: Fix memory leak
- gaiconf-init-double-free.patch: gaiconf_init: Avoid double-free in label
and precedence lists
- copy-and-spawn-sgid-double-close.patch: copy_and_spawn_sgid: Avoid
double calls to close()
- icon-charmap-close-output.patch: iconv_charmap: Close output file when
done
- fcntl-time-bits-64-redirect.patch: Linux: Fix fcntl, ioctl, prctl
redirects for _TIME_BITS=64 (BZ #28182)
- librt-null-pointer.patch: librt: fix NULL pointer dereference (BZ
[#28213])
- Add cross development packages for aarch64 and riscv64.
- Update to glibc 2.34
Major new features:
* When _DYNAMIC_STACK_SIZE_SOURCE or _GNU_SOURCE are defined,
PTHREAD_STACK_MIN is no longer constant and is redefined to
sysconf(_SC_THREAD_STACK_MIN)
* Add _SC_MINSIGSTKSZ and _SC_SIGSTKSZ
* The dynamic linker implements the --list-diagnostics option, printing
a dump of information related to IFUNC resolver operation and
glibc-hwcaps subdirectory selection
* On Linux, the function execveat has been added
* The ISO C2X function timespec_getres has been added
* The feature test macro __STDC_WANT_IEC_60559_EXT__, from draft ISO
C2X, is supported to enable declarations of functions defined in Annex F
of C2X
* Add support for 64-bit time_t on configurations like x86 where time_t
is traditionally 32-bit
* The main gconv-modules file in glibc now contains only a small set of
essential converter modules and the rest have been moved into a supplementary
configuration file gconv-modules-extra.conf in the gconv-modules.d directory
in the same GCONV_PATH
* On Linux, a new tunable, glibc.pthread.stack_cache_size, can be used
to configure the size of the thread stack cache
* The function _Fork has been added as an async-signal-safe fork replacement
since Austin Group issue 62 droped the async-signal-safe requirement for
fork (and it will be included in the future POSIX standard)
* On Linux, the close_range function has been added
* The function closefrom has been added
* The posix_spawn_file_actions_closefrom_np function has been added, enabling
posix_spawn and posix_spawnp to close all file descriptors great than or
equal to a giver integer
Deprecated and removed features, and other changes affecting compatibility:
* The function pthread_mutex_consistent_np has been deprecated
* The function pthread_mutexattr_getrobust_np has been deprecated
* The function pthread_mutexattr_setrobust_np has been deprecated
* The function pthread_yield has been deprecated
* The function inet_neta declared in
On 9/22/21 21:00, Dominique Leuenberger wrote:
Packages changed: mariadb (10.5.10 -> 10.6.4)
This seems to fail with Nextcloud. In nextcloud.log there's this exception: An exception occurred while executing a query: SQLSTATE[HY000]: General error: 4047 InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE. Ciao, Michael.
On 9/22/21 22:47, Michael Ströder wrote:
On 9/22/21 21:00, Dominique Leuenberger wrote:
Packages changed: mariadb (10.5.10 -> 10.6.4) This seems to fail with Nextcloud. In nextcloud.log there's this exception:
An exception occurred while executing a query: SQLSTATE[HY000]: General error: 4047 InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE.
Files as: https://bugzilla.opensuse.org/show_bug.cgi?id=1190803 Ciao, Michael.
On Wed, 22 Sep 2021 22:50:16 +0200
Michael Ströder
On 9/22/21 22:47, Michael Ströder wrote:
On 9/22/21 21:00, Dominique Leuenberger wrote:
Packages changed: mariadb (10.5.10 -> 10.6.4) This seems to fail with Nextcloud. In nextcloud.log there's this exception:
An exception occurred while executing a query: SQLSTATE[HY000]: General error: 4047 InnoDB refuses to write tables with ROW_FORMAT=COMPRESSED or KEY_BLOCK_SIZE.
Files as:
https://bugzilla.opensuse.org/show_bug.cgi?id=1190803
Ciao, Michael.
Hello Michael, Nextcloud do not support mariadb 10.6 yet. https://github.com/nextcloud/server/issues/27468#issuecomment-881000641
Nextcloud does not support MariaDB 10.6 for now. The reason is the compressed row format.
A possible solution is:
To stick with MariaDB 10.5 --innodb-read-only-compressed=OFF to make compressed tables writeable again.
#25436 is the issue to track the progress. It's on the roadmap. A solution requires a migration of the row format to something different. Don't expect this migration for Nextcloud 22 / 23.
Bye, Carsten -- What you end up with, after running an operating system concept through these many marketing coffee filters, is something not unlike plain hot water. -- Matt Welsh
Am 2021-09-22 21:00, schrieb Dominique Leuenberger:
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&groupid=1&version=Tumbleweed&build=20210920
After upgrading to 20210920 my laptop can't get an IPv4 address via dhcp anymore - it just times out. IPv6 adresses come in reliably via radvd, but I don't have a V6 resolver in my network... also, usbguard.service upgraeds to "disabled" which broke all my HID devices. Back to 20210916 for me for now. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am 2021-09-23 09:14, schrieb Mathias Homann:
Am 2021-09-22 21:00, schrieb Dominique Leuenberger:
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&groupid=1&version=Tumbleweed&build=20210920
After upgrading to 20210920 my laptop can't get an IPv4 address via dhcp anymore - it just times out. IPv6 adresses come in reliably via radvd, but I don't have a V6 resolver in my network...
There's definitely something wrong with dhclient or the likes - asd soon as I configure a connection with static adresses all is well. But of course that doesn't work with a laptop that is used while travelling. Cheers Mathias -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Thu, 2021-09-23 at 16:20 +0200, Mathias Homann wrote:
Am 2021-09-23 09:14, schrieb Mathias Homann:
Am 2021-09-22 21:00, schrieb Dominique Leuenberger:
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&groupid=1&version=Tumbleweed&build=20210920
After upgrading to 20210920 my laptop can't get an IPv4 address via dhcp anymore - it just times out. IPv6 adresses come in reliably via radvd, but I don't have a V6 resolver in my network...
There's definitely something wrong with dhclient or the likes - asd soon as I configure a connection with static adresses all is well. But of course that doesn't work with a laptop that is used while travelling.
Cheers Mathias
There definately isn't an issue with network on my 0920 laptop which has travelled across 4 different networks so far today, all but one with fresh DHCP leases.. So I think you'll need to ask yourself what differences your system must have from the default and/or every single (very DHCP heavy) test done on openQA. And then you might find that the issue is a local issue of your creation .In which case, please fix it on your system and only tell us here if you think a large majority would find it interesting (given no one else is reporting networking issues..I think this is unlikely) You may also find that, even if it is due to weird local issues, it does ultimately still represent a bugg - in which case, please report it properly and not create more noise here. Good luck, Richard
Am Donnerstag, 23. September 2021, 16:53:47 CEST schrieb Richard Brown:
On Thu, 2021-09-23 at 16:20 +0200, Mathias Homann wrote:
Am 2021-09-23 09:14, schrieb Mathias Homann:
Am 2021-09-22 21:00, schrieb Dominique Leuenberger:
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&groupid=1&v ersion=Tumbleweed&build=20210920> > After upgrading to 20210920 my laptop can't get an IPv4 address via dhcp anymore - it just times out. IPv6 adresses come in reliably via radvd, but I don't have a V6 resolver in my network...
There's definitely something wrong with dhclient or the likes - asd soon as I configure a connection with static adresses all is well. But of course that doesn't work with a laptop that is used while travelling.
Cheers Mathias
There definately isn't an issue with network on my 0920 laptop which has travelled across 4 different networks so far today, all but one with fresh DHCP leases..
what network card do you have?
So I think you'll need to ask yourself what differences your system must have from the default and/or every single (very DHCP heavy) test done on openQA.
is there a dhcp test in openQA that turns off the randomized mac adresses? because that is the only "special" bit about my network configuration that comes to mind - I need to be able to identify client computers by their true hardware mac address. cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Thu, 2021-09-23 at 17:14 +0200, Mathias Homann wrote:
Am Donnerstag, 23. September 2021, 16:53:47 CEST schrieb Richard Brown:
On Thu, 2021-09-23 at 16:20 +0200, Mathias Homann wrote:
Am 2021-09-23 09:14, schrieb Mathias Homann:
Am 2021-09-22 21:00, schrieb Dominique Leuenberger:
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&groupid=1&v ersion=Tumbleweed&build=20210920> > After upgrading to 20210920 my laptop can't get an IPv4 address via dhcp anymore - it just times out. IPv6 adresses come in reliably via radvd, but I don't have a V6 resolver in my network...
There's definitely something wrong with dhclient or the likes - asd soon as I configure a connection with static adresses all is well. But of course that doesn't work with a laptop that is used while travelling.
Cheers Mathias
There definately isn't an issue with network on my 0920 laptop which has travelled across 4 different networks so far today, all but one with fresh DHCP leases..
what network card do you have?
I can confirm DHCP works on the following cards Realtek rtl8153b Intel e1000e
So I think you'll need to ask yourself what differences your system must have from the default and/or every single (very DHCP heavy) test done on openQA.
is there a dhcp test in openQA that turns off the randomized mac adresses? because that is the only "special" bit about my network configuration that comes to mind - I need to be able to identify client computers by their true hardware mac address.
Yes, and not only that, my e1000e carded system doesn't use randomized mac addresses
Am Donnerstag, 23. September 2021, 17:33:43 CEST schrieb Richard Brown:
On Thu, 2021-09-23 at 17:14 +0200, Mathias Homann wrote:
Am Donnerstag, 23. September 2021, 16:53:47 CEST schrieb Richard
Brown:
On Thu, 2021-09-23 at 16:20 +0200, Mathias Homann wrote:
Am 2021-09-23 09:14, schrieb Mathias Homann:
Am 2021-09-22 21:00, schrieb Dominique Leuenberger:
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&groupid =1&v ersion=Tumbleweed&build=20210920> >
After upgrading to 20210920 my laptop can't get an IPv4 address via dhcp anymore - it just times out. IPv6 adresses come in reliably via radvd, but I don't have a V6 resolver in my network...
There's definitely something wrong with dhclient or the likes - asd soon as I configure a connection with static adresses all is well. But of course that doesn't work with a laptop that is used while travelling.
Cheers Mathias
There definately isn't an issue with network on my 0920 laptop which has travelled across 4 different networks so far today, all but one with fresh DHCP leases..
what network card do you have?
I can confirm DHCP works on the following cards
Realtek rtl8153b Intel e1000e
So I think you'll need to ask yourself what differences your system must have from the default and/or every single (very DHCP heavy) test done on openQA.
is there a dhcp test in openQA that turns off the randomized mac adresses? because that is the only "special" bit about my network configuration that comes to mind - I need to be able to identify client computers by their true hardware mac address.
Yes, and not only that, my e1000e carded system doesn't use randomized mac addresses
and here I don't even see outgoing dhcp packages with tcpdump on the affected systems... let's just say for peace's sake that it IS because of some local change that I have unknowingly done on two separate systems that had no effect up to tumbleweed 20210916, but breaks dhcp in 20210920, what the *beep* would that be? Definitely nothing in the network setup, because all I've done there is the bog standard "nmcli con add". at this point I'd be glad for any useful hint... Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am Donnerstag, 23. September 2021, 17:54:57 CEST schrieb Mathias Homann:
at this point I'd be glad for any useful hint...
nothing to do with my accesspoints or my dhcp server either: - cable ethernet is affected as well - connecting to the AP in my phone doesn't work either. -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 9/23/21 11:30, Mathias Homann wrote:
Am Donnerstag, 23. September 2021, 17:54:57 CEST schrieb Mathias Homann:
at this point I'd be glad for any useful hint...
nothing to do with my accesspoints or my dhcp server either: - cable ethernet is affected as well - connecting to the AP in my phone doesn't work either.
Both wired and wireless interfaces work for me on both IPv4 and IPv6. The output
of 'ip address' with interface lo removed is as follows:
finger@2603-8090-2005-39b3-0000-0000-0000-1007:~/staging>ip address
2: enp0s25:
Am Donnerstag, 23. September 2021, 19:12:26 CEST schrieb Larry Finger:
On 9/23/21 11:30, Mathias Homann wrote:
Am Donnerstag, 23. September 2021, 17:54:57 CEST schrieb Mathias Homann:
at this point I'd be glad for any useful hint...
nothing to do with my accesspoints or my dhcp server either: - cable ethernet is affected as well - connecting to the AP in my phone doesn't work either.
Both wired and wireless interfaces work for me on both IPv4 and IPv6. The output of 'ip address' with interface lo removed is as follows:
finger@2603-8090-2005-39b3-0000-0000-0000-1007:~/staging>ip address
2: enp0s25:
mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:6b:23:85:20:7a brd ff:ff:ff:ff:ff:ff inet 192.168.1.103/24 brd 192.168.1.255 scope global dynamic noprefixroute enp0s25 valid_lft 86392sec preferred_lft 86392sec inet6 2603:8090:2005:39b3::1007/128 scope global dynamic noprefixroute valid_lft 86395sec preferred_lft 86395sec inet6 fe80::ba6b:23ff:fe85:207a/64 scope link noprefixroute valid_lft forever preferred_lft forever 3: wlp4s0: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 80:86:f2:70:1f:20 brd ff:ff:ff:ff:ff:ff inet 192.168.1.105/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp4s0 valid_lft 80608sec preferred_lft 80608sec inet6 2603:8090:2005:39b3::1011/128 scope global dynamic noprefixroute valid_lft 80606sec preferred_lft 80606sec inet6 fe80::1ba4:c5f7:553f:6f72/64 scope link noprefixroute valid_lft forever preferred_lft forever 4: wls1: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 94:08:53:8e:ef:63 brd ff:ff:ff:ff:ff:ff altname wlp2s0 inet 10.62.118.101/24 brd 10.62.118.255 scope global dynamic noprefixroute wls1 valid_lft 86378sec preferred_lft 86378sec inet6 fe80::9965:8ab0:85ab:de78/64 scope link noprefixroute valid_lft forever preferred_lft forever Interfaces 2 and 3 are Intel devices. #4 is a Realtek RTL8852AE running an out-of kernel driver.
Have you checked for .rpmsave files to see if one of the configuration files was changed?
I just upgraded to 20210921 and now dhcp works again. .... Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am Donnerstag, 23. September 2021, 22:50:35 CEST schrieb Mathias Homann:
I just upgraded to 20210921 and now dhcp works again.
...or not. Right now it's HALF solved. My desktop and my laptop both have 20210921 now, my desktop has working DHCP, my laptop does not - and doesn't even print the banner when I start dhclient with "-v -v -d eth0". Strace shows dhclient as waiting for a futex... I'm out of my league here, who could help? Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
In data giovedì 23 settembre 2021 23:09:48 CEST, Mathias Homann ha scritto:
I'm out of my league here, who could help?
Perhaps a stupid question, but do you have firewalld running? In the past, some TW upgrades set the firewall into a panic mode, rejecting everything, including DHCP (hasn't happened in a while to me, hence I didn't report it as a bug). -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B
Am Freitag, 24. September 2021, 06:15:50 CEST schrieb Luca Beltrame:
In data giovedì 23 settembre 2021 23:09:48 CEST, Mathias Homann ha scritto:
I'm out of my league here, who could help?
Perhaps a stupid question, but do you have firewalld running? In the past, some TW upgrades set the firewall into a panic mode, rejecting everything, including DHCP (hasn't happened in a while to me, hence I didn't report it as a bug).
Yep that was one of the earlier things I thought of, too - but turning firewalld off doesn't make any difference. also, whatever it is rejects ONLY dhcp - if I set up a static address the network works just fine. At home that would work, I have my hosts setup with predefined ip adresses in my dhcp server anyways, but next week I gotta go off on a business trip, and hotel evenings with my laptop without nework don't sound all that great... Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 24.09.21 07:30, Mathias Homann wrote:
At home that would work, I have my hosts setup with predefined ip adresses in my dhcp server anyways, but next week I gotta go off on a business trip, and hotel evenings with my laptop without nework don't sound all that great...
Just some questions upfront, before offering a wild guess / crazy theory: * what dhcp server software are you running? * are AVM Fritz!Box routers / Mesh repeaters involved in the setup? Best regards, -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am Donnerstag, 23. September 2021, 17:14:48 CEST schrieb Mathias Homann:
is there a dhcp test in openQA that turns off the randomized mac adresses?
well I just tried that myself, does not make a difference. ...is there a sysctl that disables ethernet broadcasts that might have had its default setting changed in the kernel between 5.14.4 and 5.14.5, because looking at my dhcp server I don't even see any incoming dhcp requests in the logfiles from the two systems.... not even with tcpdump. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Thursday 2021-09-23 16:20, Mathias Homann wrote:
Am 2021-09-23 09:14, schrieb Mathias Homann:
Am 2021-09-22 21:00, schrieb Dominique Leuenberger:
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&groupid=1&version=Tumbleweed&build=20210920
After upgrading to 20210920 my laptop can't get an IPv4 address via dhcp anymore - it just times out. IPv6 adresses come in reliably via radvd, but I don't have a V6 resolver in my network...
There's definitely something wrong with dhclient or the likes - asd soon as I configure a connection with static adresses all is well. But of course that doesn't work with a laptop that is used while travelling.
So install networkd and use its own dhcp client? ;)
Am Freitag, 24. September 2021, 01:02:23 CEST schrieb Jan Engelhardt:
On Thursday 2021-09-23 16:20, Mathias Homann wrote:
Am 2021-09-23 09:14, schrieb Mathias Homann:
Am 2021-09-22 21:00, schrieb Dominique Leuenberger:
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&groupid=1&ver sion=Tumbleweed&build=20210920>> After upgrading to 20210920 my laptop can't get an IPv4 address via dhcp anymore - it just times out. IPv6 adresses come in reliably via radvd, but I don't have a V6 resolver in my network...
There's definitely something wrong with dhclient or the likes - asd soon as I configure a connection with static adresses all is well. But of course that doesn't work with a laptop that is used while travelling.
So install networkd and use its own dhcp client? ;)
...can networkd do everything NetworkManager can do? I'm thinking of the dispatcher scripts... cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 24.09.21 07:31, Mathias Homann wrote:
...can networkd do everything NetworkManager can do? I'm thinking of the dispatcher scripts...
probably yes, but different ways. But if it works with networkd and does not work with NM, then you have another data point for your investigation. I always try to debug such things with busybox tools. If they do not work, then something is *really* borken. Unfortunately, openSUSE's busybox does not contain udhcpc, but it can be built easily: tar xf busybox.tar.xz cd busybox mkdir build make allnoconfig O=build sed -i -e '/CONFIG_UDHCPC /d' \ -e '/CONFIG_BUSYBOX /d' \ -e '/CONFIG_SHOW_USAGE /d' build/.config echo CONFIG_UDHCPC=y >> build/.config echo CONFIG_BUSYBOX=y >> build/.config echo CONFIG_SHOW_USAGE=y >> build/.config make silentoldconfig O=build make -j8 O=build sudo build/busybox udhcpc -s '/bin/true' -i air udhcpc: started, v1.33.0.git udhcpc: sending discover udhcpc: sending select for 192.168.200.12 udhcpc: lease of 192.168.200.12 obtained, lease time 43200 Your interface is probably not named "air" ;-) Alternatively, without compiling anyhting, you can install "udhcp" package and just use udhcpc from there the same way as above. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
Am Freitag, 24. September 2021, 08:05:14 CEST schrieb Stefan Seyfried:
On 24.09.21 07:31, Mathias Homann wrote:
...can networkd do everything NetworkManager can do? I'm thinking of the dispatcher scripts...
probably yes, but different ways.
But if it works with networkd and does not work with NM, then you have another data point for your investigation.
I always try to debug such things with busybox tools. If they do not work, then something is *really* borken. Unfortunately, openSUSE's busybox does not contain udhcpc, but it can be built easily:
tar xf busybox.tar.xz cd busybox mkdir build make allnoconfig O=build sed -i -e '/CONFIG_UDHCPC /d' \ -e '/CONFIG_BUSYBOX /d' \ -e '/CONFIG_SHOW_USAGE /d' build/.config echo CONFIG_UDHCPC=y >> build/.config echo CONFIG_BUSYBOX=y >> build/.config echo CONFIG_SHOW_USAGE=y >> build/.config make silentoldconfig O=build make -j8 O=build
sudo build/busybox udhcpc -s '/bin/true' -i air udhcpc: started, v1.33.0.git udhcpc: sending discover udhcpc: sending select for 192.168.200.12 udhcpc: lease of 192.168.200.12 obtained, lease time 43200
Your interface is probably not named "air" ;-)
Alternatively, without compiling anyhting, you can install "udhcp" package and just use udhcpc from there the same way as above.
ok so I just switched back to the networkmanager connection that tries to do dhcp, which on my laptop still does not work, then created a softlink in /sbin pointing at /usr/bin/route, and ran "udhcpc eth0" - and that WORKED. eth0 got ip address and everything. if I try the same thing with dhclient, it does not do anything - it doesn't even *start* ("dhclient -v -v eth0" does not even print its banner, and shows as stuck in a futex() call in strace). Weirdly enough dhclient does work now after upgrading to 20210921 on my *other* TW installation... Guess its bugzilla time. Is there a way to tell NM to use udhcpc instead of dhclient? Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am Freitag, 24. September 2021, 08:49:09 CEST schrieb Mathias Homann:
Is there a way to tell NM to use udhcpc instead of dhclient?
I changed my NetworkManager config file like this: mio:/etc/NetworkManager # head -5 NetworkManager.conf [main] plugins=keyfile dhcp=udhcpc I mhave my working network back. Yay is me. Filing bugzilla about dhclient now. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 24.09.21 08:57, Mathias Homann wrote:
Am Freitag, 24. September 2021, 08:49:09 CEST schrieb Mathias Homann:
Is there a way to tell NM to use udhcpc instead of dhclient?
I changed my NetworkManager config file like this:
mio:/etc/NetworkManager # head -5 NetworkManager.conf [main] plugins=keyfile dhcp=udhcpc
This most likely means you are using "dhcp=internal" now... <warn> [1632475497.0719] dhcp-init: DHCP client 'udhcpc' not available <info> [1632475497.0722] dhcp-init: Using DHCP client 'internal' ...simply because there is no udhcpc option in NetworkManager... But if it works for you, that's a work around for now ;-) -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
A 'zypper dup' gives me this error: Problem: the to be installed python38-mpi4py-3.0.3-3.1.x86_64 requires 'openmpi4-config', but this requirement cannot be provided not installable providers: openmpi4-config-4.1.1-1.3.i586[http-download.opensuse.org-ade0eb17] openmpi4-config-4.1.1-1.3.x86_64[http-download.opensuse.org-ade0eb17] openmpi4-config-4.1.1-1.3.i586[repo-oss] openmpi4-config-4.1.1-1.3.x86_64[repo-oss] Solution 1: deinstallation of openmpi2-config-2.1.6-11.2.x86_64 Solution 2: deinstallation of python38-mpi4py-3.0.3-2.6.x86_64 Solution 3: keep obsolete python38-mpi4py-3.0.3-2.6.x86_64 Solution 4: break python38-mpi4py-3.0.3-3.1.x86_64 by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c): d Problem: the to be installed python38-mpi4py-3.0.3-3.1.x86_64 requires 'openmpi4-config', but this requirement cannot be provided not installable providers: openmpi4-config-4.1.1-1.3.i586[http-download.opensuse.org-ade0eb17] openmpi4-config-4.1.1-1.3.x86_64[http-download.opensuse.org-ade0eb17] openmpi4-config-4.1.1-1.3.i586[repo-oss] openmpi4-config-4.1.1-1.3.x86_64[repo-oss] Detailed information: the to be installed python38-mpi4py-3.0.3-3.1.x86_64 requires 'openmpi4-config', but this requirement cannot be provided the to be installed openmpi2-config-2.1.6-11.3.x86_64 conflicts with 'namespace:otherproviders(openmpi-runtime-config)' provided by the to be installed openmpi4-config-4.1.1-1.3.x86_64 the to be installed openmpi4-config-4.1.1-1.3.x86_64 conflicts with 'namespace:otherproviders(openmpi-runtime-config)' provided by the to be installed openmpi2-config-2.1.6-11.3.x86_64 the installed python38-mpi4py-3.0.3-2.6.x86_64 does not belong to a distupgrade repository and must be replaced the to be installed python38-mpi4py-3.0.3-3.1.i586 has inferior architecture the to be installed openmpi4-config-4.1.1-1.3.i586 has inferior architecture the installed openmpi2-config-2.1.6-11.2.x86_64 does not belong to a distupgrade repository and must be replaced the to be installed openmpi2-config-2.1.6-11.3.i586 has inferior architecture Solution 1: deinstallation of openmpi2-config-2.1.6-11.2.x86_64 Solution 2: deinstallation of python38-mpi4py-3.0.3-2.6.x86_64 Solution 3: keep obsolete python38-mpi4py-3.0.3-2.6.x86_64 Solution 4: break python38-mpi4py-3.0.3-3.1.x86_64 by ignoring some of its dependencies
On Thu, 2021-09-23 at 09:26 +0200, Michael Pujos wrote:
A 'zypper dup' gives me this error:
Problem: the to be installed python38-mpi4py-3.0.3-3.1.x86_64 requires 'openmpi4-config', but this requirement cannot be provided not installable providers: openmpi4-config-4.1.1-1.3.i586[http-download.opensuse.org-ade0eb17] openmpi4-config-4.1.1-1.3.x86_64[http-download.opensuse.org-ade0eb17] openmpi4-config-4.1.1-1.3.i586[repo-oss] openmpi4-config-4.1.1-1.3.x86_64[repo-oss] Solution 1: deinstallation of openmpi2-config-2.1.6-11.2.x86_64 Solution 2: deinstallation of python38-mpi4py-3.0.3-2.6.x86_64 Solution 3: keep obsolete python38-mpi4py-3.0.3-2.6.x86_64 Solution 4: break python38-mpi4py-3.0.3-3.1.x86_64 by ignoring some of its dependencies
Choose from above solutions by number or cancel [1/2/3/4/c/d/?] (c): d Problem: the to be installed python38-mpi4py-3.0.3-3.1.x86_64 requires 'openmpi4-config', but this requirement cannot be provided not installable providers: openmpi4-config-4.1.1-1.3.i586[http-download.opensuse.org-ade0eb17] openmpi4-config-4.1.1-1.3.x86_64[http-download.opensuse.org-ade0eb17] openmpi4-config-4.1.1-1.3.i586[repo-oss] openmpi4-config-4.1.1-1.3.x86_64[repo-oss] Detailed information: the to be installed python38-mpi4py-3.0.3-3.1.x86_64 requires 'openmpi4-config', but this requirement cannot be provided the to be installed openmpi2-config-2.1.6-11.3.x86_64 conflicts with 'namespace:otherproviders(openmpi-runtime-config)' provided by the to be installed openmpi4-config-4.1.1-1.3.x86_64 the to be installed openmpi4-config-4.1.1-1.3.x86_64 conflicts with 'namespace:otherproviders(openmpi-runtime-config)' provided by the to be installed openmpi2-config-2.1.6-11.3.x86_64 the installed python38-mpi4py-3.0.3-2.6.x86_64 does not belong to a distupgrade repository and must be replaced the to be installed python38-mpi4py-3.0.3-3.1.i586 has inferior architecture the to be installed openmpi4-config-4.1.1-1.3.i586 has inferior architecture the installed openmpi2-config-2.1.6-11.2.x86_64 does not belong to a distupgrade repository and must be replaced the to be installed openmpi2-config-2.1.6-11.3.i586 has inferior architecture Solution 1: deinstallation of openmpi2-config-2.1.6-11.2.x86_64 Solution 2: deinstallation of python38-mpi4py-3.0.3-2.6.x86_64 Solution 3: keep obsolete python38-mpi4py-3.0.3-2.6.x86_64 Solution 4: break python38-mpi4py-3.0.3-3.1.x86_64 by ignoring some of its dependencies
Remove your unsupported third party repositories and I'm sure it would work... -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
From what I can tell, all the mentioned packages are from the regular TW repo. Anyway, I could fix it with 'zypper rm openmpi2-config' as that package was conflicting with openmpi4-config. On 9/23/21 10:03, Richard Brown wrote:
Remove your unsupported third party repositories and I'm sure it would work...
Trying to roll back from 20210920 to 20210916: ( 163/3823) Installing: gtk3-metatheme-breeze-5.22.5-1.1.noarch .............................................................................................[error] Installation of gtk3-metatheme-breeze-5.22.5-1.1.noarch failed: Error: Subprocess failed. Error: RPM failed: rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by rpm) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/librpm.so.9) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/librpmio.so.9) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/libgcrypt.so.20) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/liblzma.so.5) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/libzstd.so.1) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/liblua5.4.so.5) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/libgpg-error.so.0) I need ideas/suggestions fast. I have one working ssh connection to the computer in question, I can't open any new one (connection reset by peer), I can't login on the physical console either. Thanks MH -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
Am 2021-09-23 09:46, schrieb Mathias Homann:
I have one working ssh connection to the computer in question, I can't open any new one (connection reset by peer), I can't login on the physical console either.
Actually, the existing ssh connection is useless as well, not a single binary works anymore because of the glibc. I believe all I can do at this point is run an upgrade back to 20210920 through booting from an installer usb stick - because there aint no isos of older snapshots that i can find. That would leave me with a laptop with no (reliable) network. Any ideas? -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Thu, 2021-09-23 at 09:46 +0200, Mathias Homann wrote:
Trying to roll back from 20210920 to 20210916:
( 163/3823) Installing: gtk3-metatheme-breeze-5.22.5-1.1.noarch ..................................................................... ........................[error] Installation of gtk3-metatheme-breeze-5.22.5-1.1.noarch failed: Error: Subprocess failed. Error: RPM failed: rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by rpm) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/librpm.so.9) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/librpmio.so.9) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/libgcrypt.so.20) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/liblzma.so.5) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/libzstd.so.1) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/liblua5.4.so.5) rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by /lib64/libgpg-error.so.0)
I need ideas/suggestions fast. I have one working ssh connection to the computer in question, I can't open any new one (connection reset by peer), I can't login on the physical console either.
Don't use tumbleweed-cli - this is a perfect example of how it is stupid Rollback using snapper -- Richard Brown Linux Distribution Engineer - Future Technology Team SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D-90409 Nuernberg (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
Am 2021-09-23 09:59, schrieb Richard Brown:
Rollback using snapper
...and how does that statement help me now? right, it doesn't. Also, snapper requires the use of battered FS which i do not use. Thankfully I managed to find iso images of 20210916. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org telegram: https://telegram.me/lemmy98 irc: [lemmy] on freenode and ircnet obs: lemmy04 gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Thu, 2021-09-23 at 10:14 +0200, Mathias Homann wrote:
Am 2021-09-23 09:59, schrieb Richard Brown:
Rollback using snapper
...and how does that statement help me now?
right, it doesn't.
Also, snapper requires the use of battered FS which i do not use.
Thankfully I managed to find iso images of 20210916.
Well I don't think mine was an unreasonable statement... btrfs+snapper is the default for all Tumbleweed installations for good reasons, with your current situation is a perfect example as to one. If you diverge from the defaults, you should be prepared for the consequences of your decisions. I think that is a better alternative than making mailinglist posts with demands for "help/suggestions fast!" Which reminds me..such a demand is probably better suited to actual support mailinglist. Regards, Richard
Hello, On 2021-09-23 10:14, Mathias Homann wrote:
Am 2021-09-23 09:59, schrieb Richard Brown:
Rollback using snapper
...and how does that statement help me now? right, it doesn't. Also, snapper requires the use of battered FS which i do not use.
only FYI also not helpful right now but perhaps for the future https://en.opensuse.org/SDB:Disaster_Recovery Kind Regards Johannes Meixner -- SUSE Software Solutions Germany GmbH Maxfeldstr. 5 - 90409 Nuernberg - Germany (HRB 36809, AG Nuernberg) GF: Felix Imendoerffer
On 9/23/21 10:14, Mathias Homann wrote:
Am 2021-09-23 09:59, schrieb Richard Brown:
Rollback using snapper
...and how does that statement help me now?
right, it doesn't.
Also, snapper requires the use of battered FS which i do not use.
I think you can also use snapper based on LVM thin snapshots, in case you want to use snapper and you trust LVM more than you trust btrfs. Cheers. -- Ancor González Sosa YaST Team at SUSE Software Solutions
On 2021/09/23 00:59, Richard Brown wrote:
Don't use tumbleweed-cli - this is a perfect example of how it is stupid
Rollback using snapper
If TW-cli is broken, perhaps that needs to be fixed? Saying to use anything but the defaults isn't acceptable where other options are offered as valid options. If they are not valid options -- if they won't work, then they should not be offered as such. This is where I get into trouble -- is that I am offered options to use or stick with "X" where I already have "X" working. I stick with it, and then see quotes like:
If you diverge from the defaults, you should be prepared for the consequences of your decisions.
And those consequences are listed where? How can anyone deal with "random" consequences if they aren't listed anywhere. From the various install options, it doesn't tell you anything about "consequences", and even on here, when an old method that was supported no longer works, people will say "That's no longer supported" (usually after-the-fact of it having been accepted as a valid option on some install). OTOH, maybe use of TW needs to have more cautionary statements next to it, like a requirement to use btrfs+have snapper working?
On Mon, 2021-09-27 at 11:38 -0700, L A Walsh wrote:
On 2021/09/23 00:59, Richard Brown wrote:
Don't use tumbleweed-cli - this is a perfect example of how it is stupid
Rollback using snapper
If TW-cli is broken, perhaps that needs to be fixed?
This sort of response is sort of standard on this mailing list - you're expected to share tribal knowledge that certain official or semi- official tools are broken and shouldn't be used. You're also expected to have a digest of the latest 12 months of posts on this ML in your memory... ;-)
Saying to use anything but the defaults isn't acceptable where other options are offered as valid options.
If they are not valid options -- if they won't work, then they should not be offered as such.
I agree, if there's consensus that tumbleweed-cli is broken (I don't know, I'm no user of it), it should be removed from the official Factory repositories, or at least modified to print a big fat warning before doing anything else.
This is where I get into trouble -- is that I am offered options to use or stick with "X" where I already have "X" working. I stick with it, and then see quotes like:
If you diverge from the defaults, you should be prepared for the consequences of your decisions.
And those consequences are listed where? How can anyone deal with "random" consequences if they aren't listed anywhere. From the various install options, it doesn't tell you anything about "consequences", and even on here, when an old method that was supported no longer works, people will say "That's no longer supported" (usually after-the-fact of it having been accepted as a valid option on some install).
OTOH, maybe use of TW needs to have more cautionary statements next to it, like a requirement to use btrfs+have snapper working?
TW is close to upstream, and many upstream projects work like this. And it's understandable to some degree, maintaining secondary tools in rapidly evolving projects is hard. I am not sure if tw-cli was ever an official part of factory. AFAICS it was rather not, it was a personal project of an individual, provided for convenience, not developed inside the core distribution. You can never be sure that tools like this will continue working. If you really rely on tw-cli, I guess you'll have to become part of its community and help maintaining it. Regards Martin
Am 28.09.21 um 08:56 schrieb Martin Wilck:
On Mon, 2021-09-27 at 11:38 -0700, L A Walsh wrote:
On 2021/09/23 00:59, Richard Brown wrote:
Don't use tumbleweed-cli - this is a perfect example of how it is stupid
Rollback using snapper
inside the core distribution. You can never be sure that tools like this will continue working. If you really rely on tw-cli, I guess you'll have to become part of its community and help maintaining it.
Regards Martin
mh, i think you do not understand why tumbleweed cli exists: the main reason (at least for me) to use it is: 1) stay "longer" on one snapshot and you could later install single packages without updating the whole system - without breaking the system -. 2) check what release of tumbleweed is stable and install exactly this (and jump over some "more or less" unstable releases.) 3) to rollback the whole system its not the best solution, (even if its possible) it will "only" roll back packages. BUT the configfiles may be meanwhile changed to support newer functions. so maybe the older binary/package will not be able to use it. BUT -> if you like to try a singe program's older version it's often a good (or the only fast) choice. so do not blame tumbleweed-CLI for something its not designed to do !!! !!for me it works perfect!! simoN -- www.becherer.de
On Tue, 2021-09-28 at 09:12 +0200, Simon Becherer wrote:
inside the core distribution. You can never be sure that tools like this will continue working. If you really rely on tw-cli, I guess you'll have to become part of its community and help maintaining it.
Regards Martin
mh, i think you do not understand why tumbleweed cli exists:
so do not blame tumbleweed-CLI for something its not designed to do !!!
I didn't blame it for anything. I said I was unsure about it's status in the TW universe. I'm not sure if it's tested in OpenQA for example. Martin
On Tue, 2021-09-28 at 10:48 +0200, Martin Wilck wrote:
mh, i think you do not understand why tumbleweed cli exists:
so do not blame tumbleweed-CLI for something its not designed to do !!!
I didn't blame it for anything. I said I was unsure about it's status in the TW universe. I'm not sure if it's tested in OpenQA for example.
THAT I can answer: no, at this moment, tumbleweed-cli is not tested. considering it does essentially not much more than changing repo URLs, there is also not much to test. Cheers, Dominique
Am Dienstag, 28. September 2021, 12:26:50 CEST schrieb Dominique Leuenberger / DimStar:
On Tue, 2021-09-28 at 10:48 +0200, Martin Wilck wrote:
mh, i think you do not understand why tumbleweed cli exists:
so do not blame tumbleweed-CLI for something its not designed to do !!!
I didn't blame it for anything. I said I was unsure about it's status in the TW universe. I'm not sure if it's tested in OpenQA for example.
THAT I can answer: no, at this moment, tumbleweed-cli is not tested.
considering it does essentially not much more than changing repo URLs, there is also not much to test.
exactly. Just as the actual culprit when my attempted rollback died was *not* tumbleweed-cli, it was basically because zypper installs every single rpm in a separate transaction - which dies horribly when you try to downgrade essential libraries like glibc. What actually needs fixing is how zypper uses rpm. Cheers MH -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On Tue, 2021-09-28 at 12:44 +0200, Mathias Homann wrote:
exactly.
Just as the actual culprit when my attempted rollback died was *not* tumbleweed-cli, it was basically because zypper installs every single rpm in a separate transaction - which dies horribly when you try to downgrade essential libraries like glibc.
What actually needs fixing is how zypper uses rpm.
AS you follow this mailing list very actively, you are well aware of the two new test modes provided by zyppre, right? one of them being 'do it all in one transaction'. So zypper CAN do what you ask of it. This is not yet default, as it's undertested. Cheers, Dominique
Am Dienstag, 28. September 2021, 12:51:57 CEST schrieb Dominique Leuenberger / DimStar:
On Tue, 2021-09-28 at 12:44 +0200, Mathias Homann wrote:
exactly.
Just as the actual culprit when my attempted rollback died was *not* tumbleweed-cli, it was basically because zypper installs every single rpm in a separate transaction - which dies horribly when you try to downgrade essential libraries like glibc.
What actually needs fixing is how zypper uses rpm.
AS you follow this mailing list very actively, you are well aware of the two new test modes provided by zyppre, right? one of them being 'do it all in one transaction'. So zypper CAN do what you ask of it.
good to know - so tumbleweed-cli needs work after all, too. -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102
On 28.09.21 12:44, Mathias Homann wrote:
Just as the actual culprit when my attempted rollback died was *not* tumbleweed-cli, it was basically because zypper installs every single rpm in a separate transaction - which dies horribly when you try to downgrade essential libraries like glibc.
What actually needs fixing is how zypper uses rpm.
Even with a single RPM transaction, downgrading a library that almost everything else depends upon will not work well. Think about %post scriptlets etc. Heck, I usually even upgrade rpm / libzypp stack separately from the rest of the system when doing Leap updates, just to avoid crazy "old bug in the package stack prevents update to work properly" scenarios. The only way I would attempt to do this is: * downgrade everything else * then downgrade glibc And you certainly know, that that's the way it should be done, you just did not look closely enough what that "rollback" command was going to do ;-) On a well maintained system, it would have just been "restore the backup and try again" ;-) Actually, your downgrade failure might be a bug, because zypper downgraded glibc while packages needing the newer version were still installed. The dependency solver should have prevented that IMHO. It should have installed the old glibc as one of the last packages. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
On Thursday 2021-09-23 09:46, Mathias Homann wrote:
Trying to roll back from 20210920 to 20210916:
( 163/3823) Installing: gtk3-metatheme-breeze-5.22.5-1.1.noarch .............................................................................................[error] Installation of gtk3-metatheme-breeze-5.22.5-1.1.noarch failed: Error: Subprocess failed. Error: RPM failed: rpm: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by rpm)
.oO(If only zypper ran rpm in _one_ transaction ;-) [It would still throw some errors, e.g. from %post, but that's more survivable than... this.]
On Wednesday, 22 September 2021 20:00:47 BST Dominique Leuenberger wrote:
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.
3rd attempt getting thru the spam filter.... I had this notification pop up at the end of the update - does it mean anything? "Bell in '- : sudo zypper' (Session 'Profile 2') " I couldn't see any errors during the "zypper dup" or is it something to do with "sudo"? -- opensuse:tumbleweed:20210916 Qt: 5.15.2 KDE Frameworks: 5.86.0 - KDE Plasma: 5.22.5 - kwin 5.22.5 kmail2 5.18.1 (21.08.1) - akonadiserver 5.18.1 (21.08.1) - Kernel: 5.14.2-1-default - xf86-video-nouveau: 1.0.17
On Thursday 2021-09-23 13:30, Ianseeks wrote:
On Wednesday, 22 September 2021 20:00:47 BST Dominique Leuenberger wrote:
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.
3rd attempt getting thru the spam filter....
I had this notification pop up at the end of the update - does it mean anything?
"Bell in '- : sudo zypper' (Session 'Profile 2') "
I couldn't see any errors during the "zypper dup" or is it something to do with "sudo"?
It can happen under a very specific set of circumstances: - zypper is running - zypper has no postinst notifications to show - you pressed cursor/function/special keys while zypper was active and which were not a hotkey captured by the graphical session already - terminals buffer keystrokes (no news there) - the buffer is processed once sh regains control (at the end of zypper, naturally) - the function key led to an action that your sh could not complete, hence it belled - watch where you type! :D
On Thursday, 23 September 2021 13:36:10 BST Jan Engelhardt wrote:
On Thursday 2021-09-23 13:30, Ianseeks wrote:
On Wednesday, 22 September 2021 20:00:47 BST Dominique Leuenberger wrote:
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.
3rd attempt getting thru the spam filter....
I had this notification pop up at the end of the update - does it mean anything?
"Bell in '- : sudo zypper' (Session 'Profile 2') "
I couldn't see any errors during the "zypper dup" or is it something to do with "sudo"?
It can happen under a very specific set of circumstances:
- zypper is running - zypper has no postinst notifications to show - you pressed cursor/function/special keys while zypper was active and which were not a hotkey captured by the graphical session already - terminals buffer keystrokes (no news there) - the buffer is processed once sh regains control (at the end of zypper, naturally) - the function key led to an action that your sh could not complete, hence it belled
- watch where you type! :D
Thanks for an answer. I was in the browser while zypper was working in the background but i did open the konsole window now and again to see how far it got. -- opensuse:tumbleweed:20210920 Qt: 5.15.2 KDE Frameworks: 5.86.0 - KDE Plasma: 5.22.5 - kwin 5.22.5 kmail2 5.18.1 (21.08.1) - akonadiserver 5.18.1 (21.08.1) - Kernel: 5.14.5-1-default - xf86-video-nouveau: 1.0.17
hi, today, after i installed recent updates, including the updates from snapshot 20210920, vscode did not work any more. after some searching, i found https://github.com/microsoft/vscode/issues/133804 so i worked around the problem with||||||||the "--no-sandbox" commandline parameter. then i noticed also other applications do not work any more. i noticed, that all non-working applications are chromium/electron based applications like slack, hamsket, vivaldi, discord, msteams. all of them don't work any more, unless you use the "--no-sandbox" commandline parameter. after some more searching i found: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468 the reason for all this seems to be the new glibc, which was coming with snapshot 20210920 is this already known? in the above ubuntu issue a new/patched glibc is mentioned. does such fix also exist for opensuse? -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
yes, it is known but discord works for me... look in the thread for
matrix element.
darix is working on it.
Regards,
Alin
Without Questions there are no Answers!
______________________________________________________________________
Dr. Alin Marin ELENA
http://alin.elena.space/
______________________________________________________________________
On Mon, 27 Sept 2021 at 14:42, Rainer Klier
hi,
today, after i installed recent updates, including the updates from snapshot 20210920, vscode did not work any more.
after some searching, i found https://github.com/microsoft/vscode/issues/133804
so i worked around the problem with||||||||the "--no-sandbox" commandline parameter.
then i noticed also other applications do not work any more.
i noticed, that all non-working applications are chromium/electron based applications like slack, hamsket, vivaldi, discord, msteams.
all of them don't work any more, unless you use the "--no-sandbox" commandline parameter.
after some more searching i found: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468
the reason for all this seems to be the new glibc, which was coming with snapshot 20210920
is this already known?
in the above ubuntu issue a new/patched glibc is mentioned.
does such fix also exist for opensuse?
--
Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales
*DI Rainer Klier*
DevOps, Research & Development
On Mon, Sep 27, Rainer Klier wrote:
hi,
today, after i installed recent updates, including the updates from snapshot 20210920, vscode did not work any more.
after some searching, i found https://github.com/microsoft/vscode/issues/133804
so i worked around the problem with||||||||the "--no-sandbox" commandline parameter.
then i noticed also other applications do not work any more.
i noticed, that all non-working applications are chromium/electron based applications like slack, hamsket, vivaldi, discord, msteams.
all of them don't work any more, unless you use the "--no-sandbox" commandline parameter.
after some more searching i found: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468
the reason for all this seems to be the new glibc, which was coming with snapshot 20210920
is this already known?
in the above ubuntu issue a new/patched glibc is mentioned.
The patch is for Electron to behave correct, not for glibc. Some people hacked around it by disablling the new clone3() syscall, but this is no solution. It's like buying a Porsche and then put a very slow engine into it.
does such fix also exist for opensuse?
If you speak about openSUSE packages like docker: yes, we fixed the applications we were aware of. But we cannot fix e.g. third party binaries and openQA does not cover all applications. Thorsten
--
Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales
*DI Rainer Klier*
DevOps, Research & Development
-- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
Am 27.09.21 um 16:28 schrieb Thorsten Kukuk:
On Mon, Sep 27, Rainer Klier wrote:
the reason for all this seems to be the new glibc, which was coming with snapshot 20210920
is this already known?
in the above ubuntu issue a new/patched glibc is mentioned. The patch is for Electron to behave correct, not for glibc.
ah, ok, then i misunderstood this from https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468
Some people hacked around it by disablling the new clone3() syscall, but this is no solution. It's like buying a Porsche and then put a very slow engine into it.
understood.
does such fix also exist for opensuse? If you speak about openSUSE packages like docker: yes, we fixed the applications we were aware of. But we cannot fix e.g. third party binaries and openQA does not cover all applications.
klar. this means, all Electron based applications need to be fixed. and as long as such an application has not been fixed, the "--no-sandbox" workaround has to be used with this application. thanks for the explanation. -- Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti | Atenciosamente | Saludos Cordiales *DI Rainer Klier* DevOps, Research & Development
On Mon, Sep 27, 2021 at 12:18 PM Rainer Klier
Am 27.09.21 um 16:28 schrieb Thorsten Kukuk:
On Mon, Sep 27, Rainer Klier wrote:
the reason for all this seems to be the new glibc, which was coming with snapshot 20210920
is this already known?
in the above ubuntu issue a new/patched glibc is mentioned. The patch is for Electron to behave correct, not for glibc.
ah, ok,
then i misunderstood this from
Yes, it is easy to understand it backwards.. glibc only guarantees binary level compatibility and adherence to the relevant standards , it does not cover which operating system facilities it uses for implementing things. Now it implements stuff on top of extremely powerful newish clone3() syscall and some apps do not like that.
On Mon, Sep 27, Cristian Rodríguez wrote:
Yes, it is easy to understand it backwards.. glibc only guarantees binary level compatibility and adherence to the relevant standards , it does not cover which operating system facilities it uses for implementing things. Now it implements stuff on top of extremely powerful newish clone3() syscall and some apps do not like that.
The problem is more: too many people did not take it serious enough that glibc will use clone3() in the future. Some projects were sitting for about 6 month on fixes but did not include them or release fixed packages... The main problem is, that most projects using seccomp for sandboxing don't really think about the future, but only the past. So they look at what is currently in use and forbid everything else with "ENOPERM". And are surprised if suddenly new syscalls are added and their code breaks applications. It would always be better to block unknown syscalls with "ENOSYS", so letting the application think the new syscall still does not exist. This gives the application (or in this case better glibc) the chance to use the old code as fallback. As long as the sandbox developers don't make their code future proof, we will have this problem again and again with every new syscall. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect SLES & MicroOS SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany Managing Director: Felix Imendoerffer (HRB 36809, AG Nürnberg)
On Tue, 28 Sep 2021 09:52, Thorsten Kukuk wrote:
On Mon, Sep 27, Cristian Rodríguez wrote:
Yes, it is easy to understand it backwards.. glibc only guarantees binary level compatibility and adherence to the relevant standards , it does not cover which operating system facilities it uses for implementing things. Now it implements stuff on top of extremely powerful newish clone3() syscall and some apps do not like that.
The problem is more: too many people did not take it serious enough that glibc will use clone3() in the future. Some projects were sitting for about 6 month on fixes but did not include them or release fixed packages...
The main problem is, that most projects using seccomp for sandboxing don't really think about the future, but only the past. So they look at what is currently in use and forbid everything else with "ENOPERM". And are surprised if suddenly new syscalls are added and their code breaks applications. It would always be better to block unknown syscalls with "ENOSYS", so letting the application think the new syscall still does not exist. This gives the application (or in this case better glibc) the chance to use the old code as fallback.
As long as the sandbox developers don't make their code future proof, we will have this problem again and again with every new syscall.
+1 Thank you Thorsten, for the compact insight into the causes behind the failures. Looking at my own coding efforts wrt. sandboxing, I can see the issue. Thankfully my teachers (more than two decades back) told me: "Do not say 'permission fail' if a unknown syscall comes, that is a 'system fail'. 'Permission fail' is only a known op abused." Non the less, your words hit the nail on the head. Thank you for that. - Yamaban.
participants (24)
-
Alin Marin Elena
-
Ancor Gonzalez Sosa
-
Carsten Ziepke
-
Cristian Rodríguez
-
Dominique Leuenberger
-
Dominique Leuenberger / DimStar
-
Ianseeks
-
Jan Engelhardt
-
jsmeix
-
L A Walsh
-
Larry Finger
-
Luca Beltrame
-
Martin Wilck
-
Martin Wilck
-
Mathias Homann
-
Mathias Homann
-
Michael Pujos
-
Michael Ströder
-
Rainer Klier
-
Richard Brown
-
Simon Becherer
-
Stefan Seyfried
-
Thorsten Kukuk
-
Yamaban