October 2021 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1167519] New: VUL-1: CVE-2020-10870: zim: creates temporary directories with predictable names, enabling malicious users to prevent other users from being able to start Zim
by bugzilla_noreply＠novell.com 15 Feb '23

15 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1167519 Bug ID: 1167519 Summary: VUL-1: CVE-2020-10870: zim: creates temporary directories with predictable names, enabling malicious users to prevent other users from being able to start Zim Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other URL: https://smash.suse.de/issue/255622/ OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Security Assignee: luke(a)ljones.dev Reporter: wolfgang.frisch(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2020-10870 Zim through 0.72.1 creates temporary directories with predictable names. A malicious user could predict and create Zim's temporary directories and prevent other users from being able to start Zim, resulting in a denial of service. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2020-10870 https://github.com/zim-desktop-wiki/zim-desktop-wiki/issues/1028 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10870 -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1180471] New: diff-pdf has incorrect description in manpage
by bugzilla_noreply＠suse.com 13 Feb '23

13 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1180471 Bug ID: 1180471 Summary: diff-pdf has incorrect description in manpage Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: All Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: munix9(a)googlemail.com Reporter: bwiedemann(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1047218 Found By: Development Blocker: --- While working on reproducible builds for openSUSE, I found that our diff-pdf package varies across builds: +++ /usr/share/man/man1/diff-pdf.1 .SH DESCRIPTION -18:55:41: Error: Unable to initialize GTK+, is DISPLAY set properly? +08:12:21: Error: Unable to initialize GTK+, is DISPLAY set properly? This comes from help2man. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1178453] New: [Build 20201103] gnuhealth_client crashes on start
by bugzilla_noreply＠suse.com 12 Feb '23

12 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1178453 Bug ID: 1178453 Summary: [Build 20201103] gnuhealth_client crashes on start Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1460183/modules/gnuh ealth_client_first_time/steps/2 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-gnuhealth@64bit fails in [gnuhealth_client_first_time](https://openqa.opensuse.org/tests/1460183/modu… ## Test suite description Maintainer: okurz(a)suse.de Test scenario for gnuhealth software stack ## Reproducible Fails since (at least) Build [20201103](https://openqa.opensuse.org/tests/1458960) ## Expected result Last good: [20201030](https://openqa.opensuse.org/tests/1456811) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

1 15

[Bug 1170553] New: [Build 20200425] gnuhealth UI looks broken with GNOME 3.36
by bugzilla_noreply＠novell.com 12 Feb '23

12 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1170553 Bug ID: 1170553 Summary: [Build 20200425] gnuhealth UI looks broken with GNOME 3.36 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1245677/modules/gnuh ealth_client_preconfigure/steps/6 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-gnuhealth@64bit fails in [gnuhealth_client_preconfigure](https://openqa.opensuse.org/tests/1245677/mo… ## Test suite description Maintainer: okurz(a)suse.de Test scenario for gnuhealth software stack ## Reproducible Fails since (at least) Build [20200423](https://openqa.opensuse.org/tests/1245318) ## Expected result Last good: [20200422](https://openqa.opensuse.org/tests/1243312) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are on the CC list for the bug.

2 6

[Bug 1131707] New: VUL-1: CVE-2019-10868: In trytond/model/modelstorage.py in Tryton 4.2 before 4.2.21, 4.4 before 4.4.19, 4.6 before 4.6.14, 4.8 before 4.8.10, and 5.0 before 5.0.6, an authenticated user can order records based on a field for which he has no
by bugzilla_noreply＠novell.com 12 Feb '23

12 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1131707 Bug ID: 1131707 Summary: VUL-1: CVE-2019-10868: In trytond/model/modelstorage.py in Tryton 4.2 before 4.2.21, 4.4 before 4.4.19, 4.6 before 4.6.14, 4.8 before 4.8.10, and 5.0 before 5.0.6, an authenticated user can order records based on a field for which he has no Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.3 Hardware: Other URL: https://smash.suse.de/issue/228999/ OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Security Assignee: axel.braun(a)gmx.de Reporter: atoptsoglou(a)suse.com QA Contact: security-team(a)suse.de Found By: Security Response Team Blocker: --- CVE-2019-10868 In trytond/model/modelstorage.py in Tryton 4.2 before 4.2.21, 4.4 before 4.4.19, 4.6 before 4.6.14, 4.8 before 4.8.10, and 5.0 before 5.0.6, an authenticated user can order records based on a field for which he has no access right. This may allow the user to guess values. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-10868 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10868 https://hg.tryton.org/trytond/rev/f58bbfe0aefb https://discuss.tryton.org/t/security-release-for-issue8189/1262 -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1131096] New: [Build 20190329] GNUHealth no longer installable
by bugzilla_noreply＠novell.com 12 Feb '23

12 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1131096 Bug ID: 1131096 Summary: [Build 20190329] GNUHealth no longer installable Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/895777/modules/gnuhe alth_client_install/steps/19 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-gnuhealth@64bit fails in [gnuhealth_client_install](https://openqa.opensuse.org/tests/895777/modules/… ## Test suite description Maintainer: okurz(a)suse.de Test scenario for gnuhealth software stack ## Reproducible Fails since (at least) Build [20190328](https://openqa.opensuse.org/tests/894742) ## Expected result Last good: [20190327](https://openqa.opensuse.org/tests/894056) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?flavor=DVD&version=Tumblew… The package python-GooCalendar no longer exists due to changes in https://build.opensuse.org/request/show/689360 -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 1186365] New: Empty screen on Live XFCE in QEMU with virgl
by bugzilla_noreply＠suse.com 10 Feb '23

10 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1186365 Bug ID: 1186365 Summary: Empty screen on Live XFCE in QEMU with virgl Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Xfce Assignee: bnc-team-xfce(a)forge.provo.novell.com Reporter: arvidjaar(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I observed this both with Leap 15.3 current image and with Tumbleweed. I boot manually using "${QEMU_BIN}" \ -nodefaults \ -machine q35,accel=kvm \ -cpu kvm64 \ -m 2G \ -device virtio-scsi-pci \ -drive file=$HOME/tmp/openSUSE-Leap-15.3-XFCE-Live-x86_64-Build9.78-Media.iso,if=none,id=cd0,format=raw -device scsi-cd,drive=cd0,id=cd0 \ -netdev user,id=uplink -device virtio-net-pci,netdev=uplink \ -name "Leap 15.3 Live XFCE" \ -monitor unix:path="$QEMU_MONITOR_SOCKET",server=on,wait=off \ -vga virtio -display gtk,gl=on,zoom-to-fit=off,show-cursor=on \ & It boots and leaves me with empty screen. Switching to tty1 and logging in I see full graphical session correctly started, all processes present, just no output on tty7. This works if I disable OpenGL (-display gtk,gl=off). The KDE Live image boots normally using the same command line. TW XFCE Live image has the same issue. Regular TW GNOME and KDE both work with virgl. Host - Ubuntu 20.04 with GNOME Wayland session. QEMU emulator version 6.0.0 (v6.0.0-1-gd11fb9fde1) virglrenderer-0.7.0-1138-g3639155 Both compiled from source. QEMU has single patch to fix mouse positioning in gtk under Wayland. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 1177260] New: Switching python-numpy to plain BLAS causes significant performance regression
by bugzilla_noreply＠suse.com 08 Feb '23

08 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1177260 Bug ID: 1177260 Summary: Switching python-numpy to plain BLAS causes significant performance regression Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: stefan.bruens(a)rwth-aachen.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- https://build.opensuse.org/request/show/835366 switched numpy to plain BLAS/LAPACK, which causes a significant performance regression: --- import numpy as np import time n = 4000 start_time = time.time() A = np.random.randn(n,n).astype('float64') B = np.random.randn(n,n).astype('float64') print(" init took {} seconds ".format(time.time() - start_time)) start_time = time.time() m = A@B print(" mmult took {} seconds ".format(time.time() - start_time)) print(np.__config__.show()) --- python3-numpy-1.19.1 with openblas: mmult took 2.4579274654388428 seconds python3-numpy-1.19.2 with blas/lapack: mmult took 877.8246397972107 seconds python3-numpy-1.19.2 with openblas: mmult took 2.6917877197265625 seconds MMult 4000x4000 is 64e9 multiplications and additions, thats ~150kOps/s for BLAS/LAPACK. -- You are receiving this mail because: You are on the CC list for the bug.

1 25

[Bug 1173919] New: Hawk backend fails to start
by bugzilla_noreply＠suse.com 08 Feb '23

08 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1173919 Bug ID: 1173919 Summary: Hawk backend fails to start Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: High Availability Assignee: ha-bugs(a)suse.de Reporter: john.goutbeck(a)newsignal.ca QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0 Build Identifier: did another fresh clean server install of openSUSE Leap 15.2, use openSUSE repositories set IP zypper in hawk2 zypper in ha-cluster-bootstrap ha-cluster-init - no sbd systemctl restart hawk systemctl restart hawk-backend with the browser (from a Win 10 laptop) https://192.168.12.242:7630/ - get certificate error - accept BLANK screen -- systemctl status hawk ● hawk.service - HA Web Konsole Loaded: loaded (/usr/lib/systemd/system/hawk.service; enabled; vendor preset> Active: active (running) since Mon 2020-07-06 21:43:25 MDT; 17min ago Main PID: 1903 (hawk-apiserver) But not the hawk-backend systemctl status hawk-backend ● hawk-backend.service - HA Web Konsole Backend Loaded: loaded (/usr/lib/systemd/system/hawk-backend.service; static; vendor> Active: failed (Result: exit-code) since Mon 2020-07-06 22:01:52 MDT; 5s ago Process: 14663 ExecStart=/usr/bin/puma.ruby2.5 -C /usr/share/hawk/config/puma> Main PID: 14663 (code=exited, status=1/FAILURE) So, looking at the /var/log/messages file, this is what I get --- 2020-07-06T21:52:07.277099-06:00 nss-leap152 systemd[1]: Started HA Web Konsole Backend. 2020-07-06T21:52:07.393681-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] Puma starting in cluster mode... 2020-07-06T21:52:07.393886-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Version 3.11.0 (ruby 2.5.8-p224), codename: Love Song 2020-07-06T21:52:07.393999-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Min threads: 0, max threads: 1 2020-07-06T21:52:07.394113-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Environment: production 2020-07-06T21:52:07.394231-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Process workers: 1 2020-07-06T21:52:07.394350-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] * Preloading application 2020-07-06T21:52:07.710011-06:00 nss-leap152 puma.ruby2.5[10033]: [10033] ! Unable to load application: Gem::ConflictError: Unable to activate sass-rails-5.1.0, because railties-5.1.4 conflicts with railties (>= 5.2.0) 2020-07-06T21:52:07.710267-06:00 nss-leap152 puma.ruby2.5[10033]: /usr/lib64/ruby/2.5.0/rubygems/specification.rb:2327:in `raise_if_conflicts': Unable to activate sass-rails-5.1.0, because railties-5.1.4 conflicts with railties (>= 5.2.0) (Gem::ConflictError) 2020-07-06T21:52:07.710480-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/specification.rb:1438:in `activate' 2020-07-06T21:52:07.710599-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:68:in `block in gem' 2020-07-06T21:52:07.710749-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `synchronize' 2020-07-06T21:52:07.710878-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_gem.rb:67:in `gem' 2020-07-06T21:52:07.710991-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/share/hawk/config/boot.rb:35:in `<top (required)>' 2020-07-06T21:52:07.711074-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2020-07-06T21:52:07.711158-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2020-07-06T21:52:07.711239-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/share/hawk/config/application.rb:4:in `<top (required)>' 2020-07-06T21:52:07.711320-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/share/hawk/config/environment.rb:5:in `require_relative' 2020-07-06T21:52:07.711400-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/share/hawk/config/environment.rb:5:in `<top (required)>' 2020-07-06T21:52:07.711477-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2020-07-06T21:52:07.711573-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/2.5.0/rubygems/core_ext/kernel_require.rb:59:in `require' 2020-07-06T21:52:07.711650-06:00 nss-leap152 puma.ruby2.5[10033]: #011from config.ru:4:in `block in <main>' 2020-07-06T21:52:07.711726-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:55:in `instance_eval' 2020-07-06T21:52:07.711804-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:55:in `initialize' 2020-07-06T21:52:07.711880-06:00 nss-leap152 puma.ruby2.5[10033]: #011from config.ru:in `new' 2020-07-06T21:52:07.711957-06:00 nss-leap152 puma.ruby2.5[10033]: #011from config.ru:in `<main>' 2020-07-06T21:52:07.712037-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:49:in `eval' 2020-07-06T21:52:07.712114-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:49:in `new_from_string' 2020-07-06T21:52:07.712186-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/rack-2.0.8/lib/rack/builder.rb:40:in `parse_file' 2020-07-06T21:52:07.712257-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/configuration.rb:318:in `load_rackup' 2020-07-06T21:52:07.712327-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/configuration.rb:243:in `app' 2020-07-06T21:52:07.712401-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/runner.rb:138:in `load_and_bind' 2020-07-06T21:52:07.712472-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/cluster.rb:397:in `run' 2020-07-06T21:52:07.712540-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/launcher.rb:183:in `run' 2020-07-06T21:52:07.712611-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/lib/puma/cli.rb:77:in `run' 2020-07-06T21:52:07.712680-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/lib64/ruby/gems/2.5.0/gems/puma-3.11.0/bin/puma:10:in `<top (required)>' 2020-07-06T21:52:07.712772-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/bin/puma.ruby2.5:23:in `load' 2020-07-06T21:52:07.712848-06:00 nss-leap152 puma.ruby2.5[10033]: #011from /usr/bin/puma.ruby2.5:23:in `<main>' 2020-07-06T21:52:07.713821-06:00 nss-leap152 systemd[1]: hawk-backend.service: Main process exited, code=exited, status=1/FAILURE 2020-07-06T21:52:07.714104-06:00 nss-leap152 systemd[1]: hawk-backend.service: Unit entered failed state. 2020-07-06T21:52:07.714242-06:00 nss-leap152 systemd[1]: hawk-backend.service: Failed with result 'exit-code'. --- query the rpm nss-leap152:~ # rpm -qa | grep railties ruby2.5-rubygem-railties-5_1-5.1.4-lp152.3.3.x86_64 ruby2.5-rubygem-railties-5.2-5.2.3-lp152.2.3.x86_64 nss-leap152:~ # rpm -qa | grep sass ruby2.5-rubygem-sass-3.5.3-lp152.3.3.x86_64 ruby2.5-rubygem-sass-rails-5.1-5.1.0-lp152.1.1.x86_64 ruby2.5-rubygem-sass-listen-4.0.0-lp152.3.3.x86_64 --- nss-leap152:~ # zypper up Loading repository data... Reading installed packages... Nothing to do. nss-leap152:~ # zypper in -force hawk The flag o is not known. nss-leap152:~ # update-alternatives --config rails There are 2 choices for the alternative rails (providing /usr/bin/rails). Selection Path Priority Status ------------------------------------------------------------ * 0 /usr/bin/rails.ruby2.5-5.2.3 50203 auto mode 1 /usr/bin/rails.ruby2.5-5.1.4 50104 manual mode 2 /usr/bin/rails.ruby2.5-5.2.3 50203 manual mode - I chose option 1, 2 and back to 0, still no joy - restart hawk and hawk-backend in-between options. --- zypper in -f hawk2 Loading repository data... Reading installed packages... Forcing installation of 'hawk2-2.1.1+git.1585238036.fab19246-lp152.1.9.x86_64' from repository 'Main Repository'. Resolving package dependencies... The following package is going to be reinstalled: hawk2 1 package to reinstall. Overall download size: 9.3 MiB. Already cached: 0 B. No additional space will be used or freed after the operation. Continue? [y/n/v/...? shows all options] (y): Retrieving package hawk2-2.1.1+git.1585238036.fab19246-lp152.1.9.x86_64 (1/1), 9.3 MiB ( 20.6 MiB unpacked) Retrieving: hawk2-2.1.1+git.1585238036.fab19246-lp152.1.9.x86_64.rpm ..............................................[done (3.7 MiB/s)] Checking for file conflicts: ..................................................................................................[done] (1/1) Installing: hawk2-2.1.1+git.1585238036.fab19246-lp152.1.9.x86_64 ........................................................[done] Additional rpm output: Updating /etc/sysconfig/hawk ... systemctl restart hawk systemctl restart hawk-backend - still BLANK whit screen - no joy Reproducible: Always Steps to Reproduce: 1. Install Server based openSUSE Leap 15.2 2. zypper in hawk2 3. zypper in ha-cluster-bootstrap 4. ha-cluster-init with the browser (from a Win 10 laptop) https://192.168.12.242:7630/ - get certificate error - accept BLANK white screen Actual Results: BLANK whit screen no HAWK2 login Expected Results: HAWK2 Login screen & HAWK 2 UI -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1178340] New: [yast] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support)
by bugzilla_noreply＠suse.com 07 Feb '23

07 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1178340 Bug ID: 1178340 Summary: [yast] Support for 64-bit processors on motherboards with 32-bit UEFI (mixed-mode support) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: All Status: NEW Severity: Enhancement Priority: P5 - None Component: Installation Assignee: yast2-maintainers(a)suse.de Reporter: jslaby(a)suse.com QA Contact: jsrain(a)suse.com CC: glin(a)suse.com, jens(a)krieger-juhnke.de, jlee(a)suse.com, jslaby(a)suse.com, mbenes(a)suse.com, mchang(a)suse.com, tiwai(a)suse.com Blocks: 1172292 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1172292 +++ On some devices (In my case a Lenovo Ideapad 100s-11iby) have 64 bit processors, but a 32-bit UEFI, so the 64-bit installation mediums are not recognized by it. Steps to Reproduce: 1. Grab a device with a 64-bit processor and a 32-bit UEFI 2. Try to boot from a 64-bit installation medium Actual Results: The installation medium is not listed in the boot menu. Expected Results: The installation medium is listed correctly, just like on a machine with a 64-bit UEFI. I did a bit of research, and found out the following: Fedora has natively supported 32-bit UEFI for 64 bit installs since Fedora 27. There seems to be a a workaround, but this is not very practical for new users, which adds a file from Github (https://github.com/hirotakaster/baytail-bootia32.efi) to the installation medium. ============= Could the installer detect whether firmware is 32 or 64 bit on x86_64 and install either grub2-i386-efi, or grub2-x86_64-efi respectively. This detection can be done by checking /sys/firmware/efi/fw_platform_size (it contains either 32 or 64). -- You are receiving this mail because: You are on the CC list for the bug.

1 7