July 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1213187] New: External microphone does not work on Acer Swift SF514-52T even with snd-hda-intel model=alc255-acer
by bugzilla_noreply＠suse.com 13 Oct '23

13 Oct '23

https://bugzilla.suse.com/show_bug.cgi?id=1213187 Bug ID: 1213187 Summary: External microphone does not work on Acer Swift SF514-52T even with snd-hda-intel model=alc255-acer Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Sound Assignee: tiwai(a)suse.com Reporter: 95kreaninw95(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- According to aplay -l, my device has “card 0: PCH [HDA Intel PCH], device 0: ALC255 Analog [ALC255 Analog]” as one of the playback hardware devices. By default, the external mic won't show up as an input device at all when plugged. I have to add "options snd-hda-intel model=alc255-acer" to /etc/modprobe.d/alsa-base.conf or /etc/modprobe.d/snd-hda-intel.conf. After adding "options snd-hda-intel model=alc255-acer", then reboot, my external mic shows up correctly. But it only picks up noise. I tried adding "options snd-hda-intel model=alc255-acer,dell-headset-multi", which proved to be working for some users who have the same ALC255 on Acer (https://www.reddit.com/r/openSUSE/comments/yseu43/sound_problems/) but this also doesn't work for me. I updated my Tumbleweed to the latest snapshot. -- You are receiving this mail because: You are on the CC list for the bug.

1 70

[Bug 1212816] New: salt-minions from some machines do not return "Minion did not return. [No response]" since salt-3006.0-150400.8.34.2
by bugzilla_noreply＠suse.com 11 Oct '23

11 Oct '23

https://bugzilla.suse.com/show_bug.cgi?id=1212816 Bug ID: 1212816 Summary: salt-minions from some machines do not return "Minion did not return. [No response]" since salt-3006.0-150400.8.34.2 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Salt Assignee: salt-maintainers(a)suse.de Reporter: okurz(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- ## Observation We observed that in our salt managed infrastructure the salt-minion from some machines do not return any result reproducibly since the upgrade salt-3004-150400.8.25.1->salt-3006.0-150400.8.34.2 salt-minions from some machines do not return "Minion did not return. [No response]" since salt-3006.0-150400.8.34.2. In our infrastructure we currently have 31 machines controlled by salt. Out of those 31 machines reproducibly 6 machines do not return with a response after some time regardless of the salt command used. The other 25 machines are not affected, all have the most up-to-date salt package version installed and an up-to-date Leap 15.4. We run machines with architectures x86_64, aarch64, ppc64le and have affected as well as non-affected machines of each architecture so this can not be an architecture-specific issue. The issue is visible when executing any salt command like `test.ping` as well as in `salt-run manage.down` showing the unresponsive salt minion nodes. ## Steps to reproduce In our infrastructure we reproduce the problem with: ``` for i in {1..7200}; do echo "### Run $i -- $(date -Is)" && salt --no-color \* test.ping ; df -i / ; salt-run jobs.list_jobs | wc -l && salt --no-color \* saltutil.kill_all_jobs && sleep 60 && rm -rf /var/cache/salt/master/jobs/*; done | tee -a log_salt_test_ping_poo131249_$(date -Is).log ``` showing the problem for the affected machines after roughly one hour. The command can be simplified by removing counting, logging, cleanup: ``` while :; do salt \* test.ping; done ``` Note that without sleeping between each loop iteration this eventually exhausted free inodes on our salt master node. ## Problem We could narrow down the problem to the salt packages upgrade salt-3004-150400.8.25.1 to salt-3006.0-150400.8.34.2 . Full changelog of the package for the above mentioned upgrade step: ``` * Mon Jun 19 2023 pablo.suarezhernandez(a)suse.com - Make master_tops compatible with Salt 3000 and older minions (bsc#1212516) (bsc#1212517) - Added: * make-master_tops-compatible-with-salt-3000-and-older.patch * Mon May 29 2023 yeray.gutierrez(a)suse.com - Avoid failures due transactional_update module not available in Salt 3006.0 (bsc#1211754) - Added: * define-__virtualname__-for-transactional_update-modu.patch * Wed May 24 2023 pablo.suarezhernandez(a)suse.com - Avoid conflicts with Salt dependencies versions (bsc#1211612) - Added: * avoid-conflicts-with-dependencies-versions-bsc-12116.patch * Fri May 05 2023 alexander.graul(a)suse.com - Update to Salt release version 3006.0 (jsc#PED-4360) * See release notes: https://docs.saltproject.io/en/latest/topics/releases/3006.0.html - Add missing patch after rebase to fix collections Mapping issues - Add python3-looseversion as new dependency for salt - Add python3-packaging as new dependency for salt - Allow entrypoint compatibility for "importlib-metadata>=5.0.0" (bsc#1207071) - Create new salt-tests subpackage containing Salt tests - Drop conflictive patch dicarded from upstream - Fix SLS rendering error when Jinja macros are used - Fix version detection and avoid building and testing failures - Prevent deadlocks in salt-ssh executions - Require python3-jmespath runtime dependency (bsc#1209233) - Added: * 3005.1-implement-zypper-removeptf-573.patch * control-the-collection-of-lvm-grains-via-config.patch * fix-version-detection-and-avoid-building-and-testing.patch * make-sure-the-file-client-is-destroyed-upon-used.patch * skip-package-names-without-colon-bsc-1208691-578.patch * use-rlock-to-avoid-deadlocks-in-salt-ssh.patch - Modified: * activate-all-beacons-sources-config-pillar-grains.patch * add-custom-suse-capabilities-as-grains.patch * add-environment-variable-to-know-if-yum-is-invoked-f.patch * add-migrated-state-and-gpg-key-management-functions-.patch * add-publish_batch-to-clearfuncs-exposed-methods.patch * add-salt-ssh-support-with-venv-salt-minion-3004-493.patch * add-sleep-on-exception-handling-on-minion-connection.patch * add-standalone-configuration-file-for-enabling-packa.patch * add-support-for-gpgautoimport-539.patch * allow-vendor-change-option-with-zypper.patch * async-batch-implementation.patch * avoid-excessive-syslogging-by-watchdog-cronjob-58.patch * bsc-1176024-fix-file-directory-user-and-group-owners.patch * change-the-delimeters-to-prevent-possible-tracebacks.patch * debian-info_installed-compatibility-50453.patch * dnfnotify-pkgset-plugin-implementation-3002.2-450.patch * do-not-load-pip-state-if-there-is-no-3rd-party-depen.patch * don-t-use-shell-sbin-nologin-in-requisites.patch * drop-serial-from-event.unpack-in-cli.batch_async.patch * early-feature-support-config.patch * enable-passing-a-unix_socket-for-mysql-returners-bsc.patch * enhance-openscap-module-add-xccdf_eval-call-386.patch * fix-bsc-1065792.patch * fix-for-suse-expanded-support-detection.patch * fix-issue-2068-test.patch * fix-missing-minion-returns-in-batch-mode-360.patch * fix-ownership-of-salt-thin-directory-when-using-the-.patch * fix-regression-with-depending-client.ssh-on-psutil-b.patch * fix-salt-ssh-opts-poisoning-bsc-1197637-3004-501.patch * fix-salt.utils.stringutils.to_str-calls-to-make-it-w.patch * fix-the-regression-for-yumnotify-plugin-456.patch * fix-traceback.print_exc-calls-for-test_pip_state-432.patch * fixes-for-python-3.10-502.patch * include-aliases-in-the-fqdns-grains.patch * info_installed-works-without-status-attr-now.patch * let-salt-ssh-use-platform-python-binary-in-rhel8-191.patch * make-aptpkg.list_repos-compatible-on-enabled-disable.patch * make-setup.py-script-to-not-require-setuptools-9.1.patch * pass-the-context-to-pillar-ext-modules.patch * prevent-affection-of-ssh.opts-with-lazyloader-bsc-11.patch * prevent-pkg-plugins-errors-on-missing-cookie-path-bs.patch * prevent-shell-injection-via-pre_flight_script_args-4.patch * read-repo-info-without-using-interpolation-bsc-11356.patch * restore-default-behaviour-of-pkg-list-return.patch * return-the-expected-powerpc-os-arch-bsc-1117995.patch * revert-fixing-a-use-case-when-multiple-inotify-beaco.patch * run-salt-api-as-user-salt-bsc-1064520.patch * run-salt-master-as-dedicated-salt-user.patch * save-log-to-logfile-with-docker.build.patch * switch-firewalld-state-to-use-change_interface.patch * temporary-fix-extend-the-whitelist-of-allowed-comman.patch * update-target-fix-for-salt-ssh-to-process-targets-li.patch * use-adler32-algorithm-to-compute-string-checksums.patch * use-salt-bundle-in-dockermod.patch * x509-fixes-111.patch * zypperpkg-ignore-retcode-104-for-search-bsc-1176697-.patch - Removed: * 3003.3-do-not-consider-skipped-targets-as-failed-for.patch * 3003.3-postgresql-json-support-in-pillar-423.patch * add-amazon-ec2-detection-for-virtual-grains-bsc-1195.patch * add-missing-ansible-module-functions-to-whitelist-in.patch * add-rpm_vercmp-python-library-for-version-comparison.patch * add-support-for-name-pkgs-and-diff_attr-parameters-t.patch * adds-explicit-type-cast-for-port.patch * align-amazon-ec2-nitro-grains-with-upstream-pr-bsc-1.patch * backport-syndic-auth-fixes.patch * batch.py-avoid-exception-when-minion-does-not-respon.patch * check-if-dpkgnotify-is-executable-bsc-1186674-376.patch * clarify-pkg.installed-pkg_verify-documentation.patch * detect-module.run-syntax.patch * do-not-crash-when-unexpected-cmd-output-at-listing-p.patch * enhance-logging-when-inotify-beacon-is-missing-pyino.patch * fix-62092-catch-zmq.error.zmqerror-to-set-hwm-for-zm.patch * fix-crash-when-calling-manage.not_alive-runners.patch * fixes-pkg.version_cmp-on-openeuler-systems-and-a-few.patch * fix-exception-in-yumpkg.remove-for-not-installed-pac.patch * fix-for-cve-2022-22967-bsc-1200566.patch * fix-inspector-module-export-function-bsc-1097531-481.patch * fix-ip6_interface-grain-to-not-leak-secondary-ipv4-a.patch * fix-issues-with-salt-ssh-s-extra-filerefs.patch * fix-jinja2-contextfuntion-base-on-version-bsc-119874.patch * fix-multiple-security-issues-bsc-1197417.patch * fix-salt-call-event.send-call-with-grains-and-pillar.patch * fix-salt.states.file.managed-for-follow_symlinks-tru.patch * fix-state.apply-in-test-mode-with-file-state-module-.patch * fix-test_ipc-unit-tests.patch * fix-the-regression-in-schedule-module-releasded-in-3.patch * fix-wrong-test_mod_del_repo_multiline_values-test-af.patch * fixes-56144-to-enable-hotadd-profile-support.patch * fopen-workaround-bad-buffering-for-binary-mode-563.patch * force-zyppnotify-to-prefer-packages.db-than-packages.patch * ignore-erros-on-reading-license-files-with-dpkg_lowp.patch * ignore-extend-declarations-from-excluded-sls-files.patch * ignore-non-utf8-characters-while-reading-files-with-.patch * implementation-of-held-unheld-functions-for-state-pk.patch * implementation-of-suse_ip-execution-module-bsc-10999.patch * improvements-on-ansiblegate-module-354.patch * include-stdout-in-error-message-for-zypperpkg-559.patch * make-pass-renderer-configurable-other-fixes-532.patch * make-sure-saltcacheloader-use-correct-fileclient-519.patch * mock-ip_addrs-in-utils-minions.py-unit-test-443.patch * normalize-package-names-once-with-pkg.installed-remo.patch * notify-beacon-for-debian-ubuntu-systems-347.patch * refactor-and-improvements-for-transactional-updates-.patch * retry-if-rpm-lock-is-temporarily-unavailable-547.patch * set-default-target-for-pip-from-venv_pip_target-envi.patch * state.apply-don-t-check-for-cached-pillar-errors.patch * state.orchestrate_single-does-not-pass-pillar-none-4.patch * support-transactional-systems-microos.patch * wipe-notify_socket-from-env-in-cmdmod-bsc-1193357-30.patch ``` ## Workaround Restarting the salt-minion systemd service on affected machines mitigates the problem for one to multiple hours until the minion becomes unresponsive again. `systemctl restart salt-minion`. For now we have downgraded the affected machines except for one which we keep as purposely broken machine which we can offer with some limitations applied to anyone interested in investigating further. ## Further details Please find our internal investigation issue on https://progress.opensuse.org/issues/131249 -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1213822] New: invalid grub.cfg created with INITRD_IN_POSTTRANS=1
by bugzilla_noreply＠suse.com 05 Oct '23

05 Oct '23

https://bugzilla.suse.com/show_bug.cgi?id=1213822 Bug ID: 1213822 Summary: invalid grub.cfg created with INITRD_IN_POSTTRANS=1 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: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Invalid boot entry is generated with latest TW update and INITRD_IN_POSTTRANS=1 set: echo 'Loading Linux 6.4.6-1-default ...' linux /boot/vmlinuz-6.4.6-1-default root=/dev/sda7 /dev/sda5 ${extra_cmdline} sysrq_always_enabled panic=100 ignore_loglevel unknown_nmi_panic resume=/dev/sda6 crashkernel=128M@256M showopts The root device in question is a btrfs device with two members, where grub2-probe prints this: # grub2-probe --target=device / /dev/sda7 /dev/sda5 The issue happened because the update transaction comprised both a grub2 update and a kernel-default update. With INITRD_IN_POSTTRANS=1, if the posttrans script of grub2-x86_64-efi is executed before the posttrans script of kernel-default, the initrd will not exist at the time grub2-mkconfig is run, and the following code from /etc/grub.d/10_linux will be executed: if test -z "${initramfs}" && test -z "${initrd_real}" ; then # "UUID=" and "ZFS=" magic is parsed by initrd or initramfs. Since there's # no initrd or builtin initramfs, it can't work here. if [ "x${GRUB_DEVICE_PARTUUID}" = "x" ] \ || [ "x${GRUB_DISABLE_LINUX_PARTUUID}" = "xtrue" ]; then linux_root_device_thisversion=${GRUB_DEVICE} else linux_root_device_thisversion=PARTUUID=${GRUB_DEVICE_PARTUUID} fi fi This will cause the wrong grub.cfg entry shown above. The script assumes that if no initrd exists at the time it is running, there will be none later, either. This assumption is arguably wrong under SUSE and openSUSE, where we always have an initrd — it would be smarter to assume that if no initrd exists, it will be created later. Also, it's very questionable to create a syntactically wrong boot entry rather than a (possibly) unparseable UUID= entry. The initramfs is created later in the installation process, when the posttrans script of kernel-default is run; but that won't cause the grub.cfg file to be regenerated. We need to make sure that grub2-mkconfig is run after initrd creation. This needs to be fixed in suse-module-tools. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1213754] New: liblinphone_tester and linphone do not start: undefined symbol
by bugzilla_noreply＠suse.com 05 Oct '23

05 Oct '23

https://bugzilla.suse.com/show_bug.cgi?id=1213754 Bug ID: 1213754 Summary: liblinphone_tester and linphone do not start: undefined symbol Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: b-h-dra(a)t-online.de QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When I start linphone,, I get the error message linphone: symbol lookup error: /lib64/liblinphone.so.10: undefined symbol: _ZN4lime11LimeManager6updateERKSt8functionIFvNS_14CallbackReturnENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE The same applies for liblinphone_tester: liblinphone_tester: symbol lookup error: /lib64/liblinphone.so.10: undefined symbol: _ZN4lime11LimeManager6updateERKSt8functionIFvNS_14CallbackReturnENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1212962] New: caja file manager not launching
by bugzilla_noreply＠suse.com 03 Oct '23

03 Oct '23

https://bugzilla.suse.com/show_bug.cgi?id=1212962 Bug ID: 1212962 Summary: caja file manager not launching Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: X11 Applications Assignee: screening-team-bugs(a)suse.de Reporter: balping314(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When using the MATE desktop (with marco window manager) and trying to start caja, I get the following error: Could not register the application: GDBus.Error:org.freedesktop.DBus.Error.NoReply: Message recipient disconnected from message bus without replying $ caja --version MATE caja 1.26.1 I'm running Tumbleweed 20230701. Without caja, the DE is basically unusable. Possibly the same bug in Ubuntu: https://bugs.launchpad.net/ubuntu-mate/+bug/2013284 -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1213572] New: Firefox 115: fonts too large
by bugzilla_noreply＠suse.com 18 Sep '23

18 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1213572 Bug ID: 1213572 Summary: Firefox 115: fonts too large Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Firefox Assignee: factory-mozilla(a)lists.opensuse.org Reporter: matwey.kornilov(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868382 --> https://bugzilla.suse.com/attachment.cgi?id=868382&action=edit Firefox 102 Hello, I am running openSUSE Leap 15.5 with KDE Plasma desktop environment. After installing patch with MozillaFirefox-115.0-150200.152.93.1.x86_64, my Firefox appearance has changed. All fonts in the Firefox are 150% of desktop environment fonts. Attached here are screenshots to demonstrate the issue: 1. Firefox appearance before the update (102) 2. Firefox appearance after the update (115) -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1213808] New: Unexpected DP dual mode adaptor
by bugzilla_noreply＠suse.com 18 Sep '23

18 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1213808 Bug ID: 1213808 Summary: Unexpected DP dual mode adaptor Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: matwey.kornilov(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868524 --> https://bugzilla.suse.com/attachment.cgi?id=868524&action=edit hwinfo output Hello, I am running openSUSE Leap 15.4 with kernel-default-5.14.21-150400.24.69.1.x86_64 After I updated to Leap 15.4 from 15.3 I see a lots of the following messages in dmesg: [135976.467456] i915 0000:00:02.0: [drm] *ERROR* Unexpected DP dual mode adaptor ID 44 Attached here is /usr/sbin/hwinfo output -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1213334] New: AMDGPU stuttering: *ERROR* Error waiting for DMUB idle: status=3
by bugzilla_noreply＠suse.com 16 Sep '23

16 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1213334 Bug ID: 1213334 Summary: AMDGPU stuttering: *ERROR* Error waiting for DMUB idle: status=3 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: reiokorn(a)tutanota.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Stuttering/lag since update to Kernel 6.4.2-1-default # VERSION="20230712" AMD ATI Radeon RX 7900 XT Error message according to journalctl: --- Jul 14 14:30:11 opensuse-pc kernel: [drm:dc_dmub_setup_subvp_dmub_command [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 Jul 14 14:30:12 opensuse-pc kernel: [drm:dc_dmub_setup_subvp_dmub_command [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 Jul 14 14:30:16 opensuse-pc kernel: [drm:dc_dmub_setup_subvp_dmub_command [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 Jul 14 14:31:18 opensuse-pc kernel: [drm:dc_dmub_setup_subvp_dmub_command [amdgpu]] *ERROR* Error waiting for DMUB idle: status=3 --- -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 1212936] New: [Build 20230701] qgis fails to build against updated exiv2
by bugzilla_noreply＠suse.com 14 Sep '23

14 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1212936 Bug ID: 1212936 Summary: [Build 20230701] qgis fails to build against updated exiv2 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/3399778/modules/qgis /steps/21 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 Target Milestone: --- Found By: openQA Blocker: Yes ## Observation exiv2 was updated to version 0.28.x; as a result, qgis now fails to build: [ 868s] /home/abuild/rpmbuild/BUILD/qgis-3.30.3/src/core/raster/qgsexiftools.cpp:69:40: error: 'const class Exiv2::Xmpdatum' has no member named 'toLong' [ 868s] 69 | val = QVariant::fromValue( it->toLong() ); openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-extra_tests_gnome@64bit fails in [qgis](https://openqa.opensuse.org/tests/3399778/modules/qgis/steps/21) ## Test suite description Maintainer: QE Core, asmorodskyi. Extra tests which were designed to run on gnome ## Reproducible Fails since (at least) Build [20230630](https://openqa.opensuse.org/tests/3398067) ## Expected result Last good: [20230629](https://openqa.opensuse.org/tests/3395201) (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 5

[Bug 1213222] New: Better warning and error recovery when dracut fails during installation
by bugzilla_noreply＠suse.com 14 Sep '23

14 Sep '23

https://bugzilla.suse.com/show_bug.cgi?id=1213222 Bug ID: 1213222 Summary: Better warning and error recovery when dracut fails during installation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Enhancement Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: akruppa(a)gmail.com QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- This is a copy-paste of https://forums.opensuse.org/t/boot-problem-after-15-5-tumbleweed-upgrade/16… ----- After upgrading from Leap 15.5 to Tumbleweed, my system failed to boot with a message: No filesystem could mount root, tried: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,2) I think I’ve narrowed the problem down to dracut failing during the upgrade process. The relevant lines of output are: dracut-install: Failed to find module ‘atiixp’ dracut[E]: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.X8M8eJ/initramfs -N ^i2o_scsi$ --kerneldir /lib/modules/6.3.7-1-default/ -m pata_atiixp ata_generic fan atiixp ide_pci_generic jbd ext3 edd dracut[F]: installkernel failed in module suse-initrd The /etc/sysconfig/kernel contains the line: INITRD_MODULES=“pata_atiixp ata_generic processor fan ahci atiixp ide_pci_generic jbd ext3 edd” ----- There were stale entries in INITRD_MODULES which caused dracut to fail. My enhancement suggestion is: 1. If dracut fails during installation, state clearly that this leaves the system in an unbootable state. This would help users who are not familiar with the Linux boot process to understand what the problem is. 2. If dracut fails because of missing modules during installation, allow the user to edit the INITRD_MODULES setting and trying dracut again. -- You are receiving this mail because: You are on the CC list for the bug.

1 31