September 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1229396] New: Old kernel file and initrd not deleted when removing kernels with systemd boot
by bugzilla_noreply＠suse.com 19 Apr '25

19 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1229396 Bug ID: 1229396 Summary: Old kernel file and initrd not deleted when removing kernels with systemd boot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: screening-team-bugs(a)suse.de Reporter: rosuna(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Problem as explained in description. I reported it as a zypper problem, so this issue will probably be closed as invalid: https://github.com/openSUSE/zypper/issues/564 OS: openSUSE Tumbleweed Bootloader: systemd boot Other info: encrypted filesystem Does this always happened? At least I can confirm it for the last two kernel updates. Which files are the ones I'm reporting as not having been deleted as expected? They're under /boot/efi/bad01a2647cb4fef8827293b9d389245 (obviously the last directory has some random string related to systemd boot). There's a kernel directory for each installed version there, containing the kernel itself and at least one initrd (more if dracut has been called several times). Why am I reporting this? The default size for /boot/efi defaults to half a GB, which seems to be enough... Well, I'm definitely going to double that in my next installation, but even with the default 2 kernels, this is easy to fill if calling dracut for whatever reasons (and sometimes, scripts are the ones calling it). If one of the kernels to be purged is not actually purged there, the partition gets filled very easily. I'm attaching some output to illustrate it. Let me know if you need anything else. Please also let me know if this is not zypper purge-kernels's fault (and if possible, point me to where to report this). mordor:~ # rpm -qa | grep -i kernel-default kernel-default-6.10.3-1.1.x86_64 kernel-default-6.10.4-1.1.x86_64 mordor:~ # uname -a Linux mordor.arkayate.org 6.10.4-1-default #1 SMP PREEMPT_DYNAMIC Mon Aug 12 05:49:20 UTC 2024 (0363a35) x86_64 x86_64 x86_64 GNU/Linux mordor:~ # ls -l /boot/efi/bad01a2647cb4fef8827293b9d389245/ total 12 drwxr-x--- 2 root root 4096 Aug 16 22:55 6.10.2-1-default drwxr-x--- 2 root root 4096 Aug 16 22:55 6.10.3-1-default drwxr-x--- 2 root root 4096 Aug 16 22:55 6.10.4-1-default mordor:~ # du -sh /boot/efi/bad01a2647cb4fef8827293b9d389245/* 175M /boot/efi/bad01a2647cb4fef8827293b9d389245/6.10.2-1-default 95M /boot/efi/bad01a2647cb4fef8827293b9d389245/6.10.3-1-default 175M /boot/efi/bad01a2647cb4fef8827293b9d389245/6.10.4-1-default mordor:~ # df -h /boot/efi/ Filesystem Size Used Avail Use% Mounted on /dev/nvme0n1p1 511M 449M 63M 88% /boot/efi mordor:~ # zypper purge-kernels -D Reading installed packages... Preparing to purge obsolete kernels... Configuration: latest,latest-1,running Running kernel release: 6.10.4-1-default Running kernel arch: x86_64 Resolving package dependencies... Nothing to do. In the output above, the directory /boot/efi/bad01a2647cb4fef8827293b9d389245/6.10.2-1-default should get deleted (I believe that by zypper purge-kernels, but not 100% sure). P.S.: Completely unrelated, but I'm happy to have seen that my FDE encryption with TPM chip as decryption key now survives kernel updates, this was also broken and got fixed recently, even before I could report this. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1224103] New: Hybrid sleep wakes up on bluetooth device (normal sleep does not)
by bugzilla_noreply＠suse.com 18 Apr '25

18 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1224103 Bug ID: 1224103 Summary: Hybrid sleep wakes up on bluetooth device (normal sleep does not) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: katonag(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- If I send my laptop to hybrid sleep it wakes up when I power on my bluetooth headset. Using simple sleep works as expected. This is only happening since a few weeks. I have also added a rule to udev: ACTION=="add", SUBSYSTEM=="usb", DRIVERS=="usb", ATTRS{idVendor}=="8087", ATTR{power/wakeup}="disabled" because my bluetooth adapter shows up in lsusb, but there is no change. The system is Tumbleweed 20240503 with KDE6. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1223674] New: tensorflow-lite fails to build with GCC 13, keeps gcc12 from being removed
by bugzilla_noreply＠suse.com 18 Apr '25

18 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1223674 Bug ID: 1223674 Summary: tensorflow-lite fails to build with GCC 13, keeps gcc12 from being removed Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: rguenther(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When building tensorflow-lite with GCC 13 (the default compiler), there's a spurious -Wstringop-overflow diagnostic promoted to an error becuause we build the package with -Werror. Adding -Wno-error=stringop-overflow causes other issues to appear: [ 51s] In file included from /home/abuild/rpmbuild/BUILD/tensorflow-2.10.0/tflite-build/build/abseil-cpp/absl/strings/internal/str_format/extension.cc:16: [ 51s] /home/abuild/rpmbuild/BUILD/tensorflow-2.10.0/tflite-build/build/abseil-cpp/absl/strings/internal/str_format/extension.h:34:6: warning: elaborated-type-specifier for a scoped enum must not use the ‘class’ keyword [ 51s] 34 | enum class FormatConversionChar : uint8_t; [ 51s] | ~~~~ ^~~~~ [ 51s] | ----- [ 51s] /home/abuild/rpmbuild/BUILD/tensorflow-2.10.0/tflite-build/build/abseil-cpp/absl/strings/internal/str_format/extension.h:34:33: error: found ‘:’ in nested-name-specifier, expected ‘::’ [ 51s] 34 | enum class FormatConversionChar : uint8_t; [ 51s] | ^ [ 51s] | :: ... [ 51s] /home/abuild/rpmbuild/BUILD/tensorflow-2.10.0/tflite-build/build/abseil-cpp/absl/strings/internal/str_format/extension.h:173:8: warning: elaborated-type-specifier for a scoped enum must not use the ‘class’ keyword [ 51s] 173 | enum class Enum : uint8_t { [ 51s] | ~~~~ ^~~~~ [ 51s] | ----- and more Likely fixed in newer upstream versions of tensorflow. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1225965] New: Improve KDE Discover bug reporting button
by bugzilla_noreply＠suse.com 18 Apr '25

18 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1225965 Bug ID: 1225965 Summary: Improve KDE Discover bug reporting button Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs(a)opensuse.org Reporter: Andreas.Stieger(a)gmx.de QA Contact: qa-bugs(a)suse.de CC: shundhammer(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Whenever we have a generic package issues that affects multiple users like (bug 1225174), we get a whole to of bug reports and duplicates. All that users seem to be doing is copy the text "<html>Dependency resolution failed:<br/><br/>[...] </html>", report a bug in a random component. Bonus: If the component is YaST, Huha gets angry like in bug 1225949. We do not see the bugs that were not reported due to bugzilla pointing out the possible duplicate, but in the example above we got 14 reports. These users may or may not have read through the duplicated bug, or read the recommendation there. https://github.com/KDE/discover/blob/d644b2a1000c04f084d39a4ef8a3402abf6417… Let's improve user experience here. Some ideas: 0. Direct the user to zypper/YaST for self-service resolution of the conflict. 1. Direct the user to a landing page with instructions for #0. 2. Direct the user to bugzilla search first 3. Take the message - extract package names only, strip arch/installed version, sort, and make a hash from it. Use that as the bug alias for automatic reduplication. 4. or even a fuzzy hash 5. Use a bugzilla whiteboard field with self-service fix instructions -- You are receiving this mail because: You are on the CC list for the bug.

1 41

[Bug 1224386] New: Please package systemd-resolved seperate from systemd-network
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1224386 Bug ID: 1224386 Summary: Please package systemd-resolved seperate from systemd-network Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: systemd-maintainers(a)suse.de Reporter: rbrown(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I get why resolved is packaged with networkd but there's also use cases where resolved would be very , very useful, even with NetworkManager eg. I want it for openSUSE Aeon, with GNOME, with NetworkManager, but using resovled for more intelligent DNS resolution as people hop networks/VPNs. Could we please package -resolved as it's own seperate thing and have it required by -networkd, as I really wouldn't like to have -networkd installed if I can avoid it. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1220905] New: salt-master: Error loading known_hosts
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1220905 Bug ID: 1220905 Summary: salt-master: Error loading known_hosts Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Python Assignee: python-maintainers(a)suse.com Reporter: egotthold(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- This error is happening to me on openSUSE MicroOS 20240302 (the logs reveal this has been happening for a good while already). The error is known upstream and is due to a combination of changes in pygit2 and how Salt is starting up its daemon. https://github.com/saltstack/salt/issues/64121#issuecomment-1705658539 Since we are not using the onedir packaging yet one cannot downgrade to another pygit2 version via salt-pip. I am not that deep into the codebase to know if a systemd drop-in that specifies the user used for running the salt-master.service as "salt", is enough. The log of the salt-master is spammed with the following message: Mar 04 00:01:51 esprimo-1 salt-master[30997]: [ERROR ] Error occurred fetching git_pillar remote 'main git(a)gitlab.com:<user>/<repo>.git': error loading known_hosts: Mar 04 00:01:51 esprimo-1 salt-master[30997]: Traceback (most recent call last): Mar 04 00:01:51 esprimo-1 salt-master[30997]: File "/usr/lib/python3.11/site-packages/salt/utils/gitfs.py", line 1996, in _fetch Mar 04 00:01:51 esprimo-1 salt-master[30997]: fetch_results = origin.fetch(**fetch_kwargs) Mar 04 00:01:51 esprimo-1 salt-master[30997]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mar 04 00:01:51 esprimo-1 salt-master[30997]: File "/usr/lib64/python3.11/site-packages/pygit2/remotes.py", line 155, in fetch Mar 04 00:01:51 esprimo-1 salt-master[30997]: payload.check_error(err) Mar 04 00:01:51 esprimo-1 salt-master[30997]: File "/usr/lib64/python3.11/site-packages/pygit2/callbacks.py", line 99, in check_error Mar 04 00:01:51 esprimo-1 salt-master[30997]: check_error(error_code) Mar 04 00:01:51 esprimo-1 salt-master[30997]: File "/usr/lib64/python3.11/site-packages/pygit2/errors.py", line 65, in check_error Mar 04 00:01:51 esprimo-1 salt-master[30997]: raise GitError(message) Mar 04 00:01:51 esprimo-1 salt-master[30997]: _pygit2.GitError: error loading known_hosts: -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 1230642] New: Salt GitFS - AttributeError: '_pygit2.Blob' object has no attribute 'hex'
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1230642 Bug ID: 1230642 Summary: Salt GitFS - AttributeError: '_pygit2.Blob' object has no attribute 'hex' Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Salt Assignee: salt-maintainers(a)suse.de Reporter: egotthold(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Same setup as on my last reports. Sadly I still can't operate my GitFS. It would be nice if the stability could be improved as GitFS isn't usable for multiple weeks now. Currently installed version: salt-master-3006.0-23.1.x86_64 Sep 17 14:11:36 esprimo-1 salt-master[15762]: [ERROR ] Uncaught exception while updating gitfs fileserver cache Sep 17 14:11:36 esprimo-1 salt-master[15762]: Traceback (most recent call last): Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/master.py", line 467, in _do_update Sep 17 14:11:36 esprimo-1 salt-master[15762]: update_func(*args) Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/loader/lazy.py", line 149, in __call__ Sep 17 14:11:36 esprimo-1 salt-master[15762]: return self.loader.run(run_func, *args, **kwargs) Sep 17 14:11:36 esprimo-1 salt-master[15762]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/loader/lazy.py", line 1234, in run Sep 17 14:11:36 esprimo-1 salt-master[15762]: return self._last_context.run(self._run_as, _func_or_method, *args, **kwargs) Sep 17 14:11:36 esprimo-1 salt-master[15762]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/loader/lazy.py", line 1249, in _run_as Sep 17 14:11:36 esprimo-1 salt-master[15762]: return _func_or_method(*args, **kwargs) Sep 17 14:11:36 esprimo-1 salt-master[15762]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/fileserver/gitfs.py", line 139, in update Sep 17 14:11:36 esprimo-1 salt-master[15762]: _gitfs().update(remotes) Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/utils/gitfs.py", line 2760, in update Sep 17 14:11:36 esprimo-1 salt-master[15762]: salt.fileserver.reap_fileserver_cache_dir( Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/fileserver/__init__.py", line 274, in reap_fileserver_cache_dir Sep 17 14:11:36 esprimo-1 salt-master[15762]: ret = find_func(filename, saltenv=saltenv) Sep 17 14:11:36 esprimo-1 salt-master[15762]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/utils/gitfs.py", line 3119, in find_file Sep 17 14:11:36 esprimo-1 salt-master[15762]: blob, blob_hexsha, blob_mode = repo.find_file(repo_path, tgt_env) Sep 17 14:11:36 esprimo-1 salt-master[15762]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sep 17 14:11:36 esprimo-1 salt-master[15762]: File "/usr/lib/python3.11/site-packages/salt/utils/gitfs.py", line 2148, in find_file Sep 17 14:11:36 esprimo-1 salt-master[15762]: return blob, blob.hex, mode -- You are receiving this mail because: You are on the CC list for the bug.

1 22

[Bug 1230022] New: VUL-0: CVE-2024-45508: HTMLDOC before 1.9.19 has an out-of-bounds write in parse_paragraph in ps-pdf.cxx because of an attempt to strip leading whitespace from a whitespace-only node.
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1230022 Bug ID: 1230022 Summary: VUL-0: CVE-2024-45508: HTMLDOC before 1.9.19 has an out-of-bounds write in parse_paragraph in ps-pdf.cxx because of an attempt to strip leading whitespace from a whitespace-only node. Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other URL: https://smash.suse.de/issue/419446/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: pgajdos(a)suse.com Reporter: smash_bz(a)suse.de QA Contact: security-team(a)suse.de CC: abergmann(a)suse.com Target Milestone: --- Found By: Security Response Team Blocker: --- HTMLDOC before 1.9.19 has an out-of-bounds write in parse_paragraph in ps-pdf.cxx because of an attempt to strip leading whitespace from a whitespace-only node. Backport code-streams: openSUSE:Backports:SLE-12-SP1/htmldoc openSUSE:Backports:SLE-15-SP5:Update/htmldoc openSUSE:Backports:SLE-15-SP6:Update/htmldoc References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2024-45508 https://www.cve.org/CVERecord?id=CVE-2024-45508 https://github.com/michaelrsweet/htmldoc/blob/2d5b2ab9ddbf2aee2209010cebc11… https://github.com/michaelrsweet/htmldoc/commit/2d5b2ab9ddbf2aee2209010cebc… https://github.com/michaelrsweet/htmldoc/issues/528 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1217885] New: dracut: the nfs module issues "rpc.statd: Running as root. chown /var/lib/nfs to choose different user"
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1217885 Bug ID: 1217885 Summary: dracut: the nfs module issues "rpc.statd: Running as root. chown /var/lib/nfs to choose different user" Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: dracut-maintainers(a)suse.de Reporter: antonio.feijoo(a)suse.com QA Contact: qa-bugs(a)suse.de CC: nfbrown(a)suse.com Target Milestone: --- Found By: --- Blocker: --- CC: nfbrown(a)suse.com Flags: needinfo?(nfbrown(a)suse.com) Created attachment 871199 --> https://bugzilla.suse.com/attachment.cgi?id=871199&action=edit dracut patch While testing the dracut nfs module in Tumbleweed, I found this warning in the journal: > Dec 07 14:07:30 localhost systemd[1]: Starting dracut pre-udev hook... > Dec 07 14:07:30 localhost kernel: RPC: Registered named UNIX socket transport m> > Dec 07 14:07:30 localhost kernel: RPC: Registered udp transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp-with-tls transport module. > Dec 07 14:07:30 localhost kernel: RPC: Registered tcp NFSv4.1 backchannel trans> > Dec 07 14:07:30 localhost rpc.statd[363]: Version 2.6.3 starting > Dec 07 14:07:30 localhost rpc.statd[363]: Initializing NSM state > ---> Dec 07 14:07:30 localhost rpc.statd[363]: Running as root. chown /var/lib/nfs to choose different user > Dec 07 14:07:30 localhost rpc.idmapd[477]: Setting log level to 0 > Dec 07 14:07:30 localhost rpc.idmapd[477]: libnfsidmap: requested translation method, 'nsswitch', is not available > Dec 07 14:07:30 localhost systemd[1]: Finished dracut pre-udev hook. I never saw this in SLE, but then I noticed that nfs-utils adds the statd user via sysusers.d configuration since version 2.5.1: > $ rpm -qf /usr/lib/sysusers.d/statd-user.conf > nfs-client-2.6.3-41.1.x86_64 > $ cat /usr/lib/sysusers.d/statd-user.conf > # Type Name ID GECOS [HOME] Shell > u statd - "NFS statd daemon" /var/lib/nfs - Also, the nfs-utils.spec file defines: > # lib/nfs must be root-owned. > # sm and sm.back and contents should be statd:statd, > # but only chown if the dirs are currently root-owned. > # This is needed for some upgraded, but chown is best avoided > # when not necessary > ... > %{_sysusersdir}/statd-user.conf > %dir %{_localstatedir}/lib/nfs > %dir %{_localstatedir}/lib/nfs/rpc_pipefs > %dir %{_localstatedir}/lib/nfs/v4recovery > %attr(0700,statd,statd) %dir %{_localstatedir}/lib/nfs/sm > %attr(0700,statd,statd) %dir %{_localstatedir}/lib/nfs/sm.bak > %ghost %{_localstatedir}/lib/nfs/state Neil, I can't find this in nfs-utils upstream, is this SUSE-specific? how bad is this warning? should we add a custom patch (maybe similar to the one attached) to the dracut nfs module to avoid it? -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1225296] New: Dual monitor not recognised after upgrade 15.5 to 15.6
by bugzilla_noreply＠suse.com 16 Apr '25

16 Apr '25

https://bugzilla.suse.com/show_bug.cgi?id=1225296 Bug ID: 1225296 Summary: Dual monitor not recognised after upgrade 15.5 to 15.6 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: x86 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: martin.schmidt(a)io-warnemuende.de QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- Moin, moin, I am using openSUSE 15.5 on an old intel based x86 PC, equipped with a simple nvidia gforce and two monitors. The monitors are using a displayport connnection from the graphics card to the monitors via an Y-shaped cable. Both monitors are recognised correctly and can be configured to form a single graphical work space, when the system is up and running. After upgrading to openSUSE 15.6 this does not work any more. When booting, monitor 1 shows some firmware screen and the openSUSE boot screen, where the OS version (several subversions of 15.6 and frozen snapshots of 15.5) can be selected. Using the default option (15.6 from harddrive), the output of the boot process is moving to monitor 2, but monitor 1 is going to a "power saving sleep mode" and stays inactive frome here on. The boot process is finished correctly with monitor 2 as the only graphical device. Monitor 1 cannot be activated again. Switching off monitor 2 before booting, the system comes up without any valid output device. Monitor 1 goes to sleep after the system boot started. I did not check the system status with a remote ssh-connection yet. Switching off monitor 1 before booting, lets the system come up completely with monitor 2. Also the initial hardware screen is diplayerd there. In turn, booting from a read-only snapshot with openSUSE 15.5, both monitors are used as before. The nouveau-dri drivers are used, no propriatary nvidia driver is installed. Some upgrade history: - just to test, if the few graphic card cores could be used in a cuda environment, cuda was installed under 15.5. This failed and cuda was deinstalled. However, when upgrading later from 15.5 to 15.6 the cuda development environment was reinstalled automatically together with nvidia drivers. As a result the nvidia drivers allowed only for a single low resolution vga monitor. May be, this happened, since the nvidia repository was not deleted and there was some leftover from the cuda test. - with the ascii-yast the nvidia drivers (gforce003/004) and cuda could be removed and the nouveau-dri drivers where reinstalled - together with dependencies. This allows for a single monitor OS_15.6 system with high resolution, but the second monitor (monitor 1) is lost during the boot process as described above. Before I try to install from scratch just with the hope that the error goes away, I am reporting this strange behaviour here. May be, this helps to streamline the distribution. Any hints are very welcome - especially how to modify the bootloader options. Cheers, Martin Schmidt -- You are receiving this mail because: You are on the CC list for the bug.

1 36