December 2022 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[Bug 1203393] New: microOS cloud-init (OpenStack variant) fails due to attempting systemd-network over NetworkManager
by bugzilla_noreply＠suse.com 21 Apr '23

21 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1203393 Bug ID: 1203393 Summary: microOS cloud-init (OpenStack variant) fails due to attempting systemd-network over NetworkManager Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: matt(a)traverse.com.au QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0 Build Identifier: When using an OpenStack-ContainerHost [aarch64] microOS Tumbleweed build (from https://en.opensuse.org/Portal:MicroOS), cloud-init will fail as it tries to create a file with a systemd-network UID. Despite NetworkManager being the microOS 'default', and systemd-network not being installed, cloud-init decides to create for systemd-networkd You do not even need to have a valid cloud-init source for this, the issue will occur on a 'fresh' system, verified by examining the log files after first boot ---------------------------------------------- 2022-09-14 06:54:40,414 - util.py[DEBUG]: Writing to /etc/systemd/network/10-cloud-init-eth0.network - wb: [644] 69 bytes 2022-09-14 06:54:40,416 - util.py[WARNING]: failed stage init-local 2022-09-14 06:54:40,417 - util.py[DEBUG]: failed stage init-local Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/cloudinit/util.py", line 1430, in chownbyname uid = pwd.getpwnam(user).pw_uid KeyError: "getpwnam(): name not found: 'systemd-network'" The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/cloudinit/cmd/main.py", line 689, in status_wrapper ret = functor(name, args) File "/usr/lib/python3.10/site-packages/cloudinit/cmd/main.py", line 398, in main_init init.apply_network_config(bring_up=bring_up_interfaces) [edited for brevity, I will attach the full log separately] OSError: Unknown user or group: "getpwnam(): name not found: 'systemd-network'" ---------------------------------------------- I built a custom microOS image (see https://build.opensuse.org/package/revisions/home:mcbridematt:branches:deve… ) with systemd-network installed and verified this "resolves" the issue. However, I haven't tried to diagnose why cloud-init wants to use networkd over NetworkManager. Reproducible: Always Steps to Reproduce: 1. Boot a microOS Tumbleweed VM with a cloud-init file (e.g cidata image) 2. Attempt to use system once it reaches the login prompt (for example, using credentials or SSH keys set in the supplied cloud-config) Actual Results: Login fails because cloud-init did not complete. No mention of the cloud-init failure is provided to the user at the console (except maybe the hostname not being configured by cloud-init) , it can only be discovered by examining the /var partition offline. The specific image I am using is: openSUSE-MicroOS.aarch64-16.0.0-OpenStack-Cloud-Snapshot20220911.qcow2 -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1206277] New: Network document scanners do not work out of the box
by bugzilla_noreply＠suse.com 19 Apr '23

19 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1206277 Bug ID: 1206277 Summary: Network document scanners do not work out of the box Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: vortex(a)z-ray.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello there I found out that network attached document scanners do not work on MicroOS out of the box. For my Canon TR4550 2 in 1 printer I had to add the following packages to make this workload work: - simple-scan (it's not on flathub) - sane-backends Then I configured sane to also use escl for network attached scanners to work by uncommenting the line: #escl in /etc/sane.d/dll.conf After a reboot simpel-scan was able to detect my network printer and successfully scanned the printer test page. I'd like to ask if this can be added to the base MicroOS image? Kind regards, V. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1205108] New: Redundant program for system monitoring on Gnome
by bugzilla_noreply＠suse.com 11 Feb '23

11 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1205108 Bug ID: 1205108 Summary: Redundant program for system monitoring on Gnome Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Enhancement Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: scribble3299(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0 Build Identifier: There are two programs installed by default on Gnome in Micro OS fresh install, Gnome System Monitor and Gnome Usage Respectively. Reproducible: Always Steps to Reproduce: 1.Install Micro OS Desktop Gnome 2.Open App Menu Actual Results: Two system monitor program installed with almost the same functionality. Expected Results: Gnome System Monitor(GSM) should be the only installed program for system monitoring as it is more feature rich and functional as compared to Gnome Usage which seems to be the "lite" version of GSM -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1200457] New: iscsi.service cannot start at microos
by bugzilla_noreply＠suse.com 10 Jan '23

10 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1200457 Bug ID: 1200457 Summary: iscsi.service cannot start at microos Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: matwey.kornilov(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello, I am running microOS 20220611 with open-iscsi-2.1.7-90.1.x86_64. When I try to start iscsi.service the following error appears: Jun 12 19:16:09 localhost.localdomain systemd[1]: Starting Login and scanning of iSCSI devices... Jun 12 19:16:09 localhost.localdomain iscsiadm[1009]: iscsiadm: Maybe you are not root? Jun 12 19:16:09 localhost.localdomain iscsiadm[1009]: iscsiadm: Could not lock discovery DB: /etc/iscsi/lock.write: No such file or directory Jun 12 19:16:09 localhost.localdomain iscsiadm[1009]: iscsiadm: No records found Jun 12 19:16:09 localhost.localdomain iscsiadm[1017]: iscsiadm: Maybe you are not root? Jun 12 19:16:09 localhost.localdomain iscsiadm[1017]: iscsiadm: Could not lock discovery DB: /etc/iscsi/lock.write: No such file or directory Jun 12 19:16:09 localhost.localdomain iscsiadm[1017]: iscsiadm: No records found Jun 12 19:16:09 localhost.localdomain iscsiadm[1018]: iscsiadm: Could not get list of targets from firmware. (err 21) Jun 12 19:16:09 localhost.localdomain systemd[1]: Finished Login and scanning of iSCSI devices. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[kubic-bugs] [Bug 1167780] New: MicroOS images don't update grub if booted without EFI
by bugzilla_noreply＠novell.com 09 Jan '23

09 Jan '23

http://bugzilla.suse.com/show_bug.cgi?id=1167780 Bug ID: 1167780 Summary: MicroOS images don't update grub if booted without EFI Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: fvogt(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org Found By: --- Blocker: --- The .qcow2 images are meant to work fine on systems with EFI (optionally secure boot) and without, so they have both i386-pc and x86_64-efi targets of grub2 installed by kiwi during image building. Kiwi sets LOADER_TYPE="grub2-efi" for this. When booting the image without EFI though, this is not changed by anything and so update-bootloader only manages the x86_64-efi target of grub2. As the grub.cfg file is in the same location, there aren't any immediate issues, but it means that grub is never updated in those deployments. -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1206700] New: systemd: Failed to start Create missing directories from rpmdb
by bugzilla_noreply＠suse.com 08 Jan '23

08 Jan '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1206700 Bug ID: 1206700 Summary: systemd: Failed to start Create missing directories from rpmdb Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: reiokorn(a)tutanota.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- sudo journalctl -b | grep rpm Dez 26 16:48:07 microos-pc systemd[1]: Starting Create missing directories from rpmdb... Dez 26 16:48:07 microos-pc create_dirs_from_rpmdb[921]: Failed to resolve uuidd/uuidd Dez 26 16:48:07 microos-pc systemd[1]: create-dirs-from-rpmdb.service: Main process exited, code=exited, status=1/FAILURE Dez 26 16:48:07 microos-pc systemd[1]: create-dirs-from-rpmdb.service: Failed with result 'exit-code'. Dez 26 16:48:07 microos-pc systemd[1]: Failed to start Create missing directories from rpmdb. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1206570] New: [SELinux] rebootmgr: new features needs bash execution
by bugzilla_noreply＠suse.com 02 Jan '23

02 Jan '23

https://bugzilla.suse.com/show_bug.cgi?id=1206570 Bug ID: 1206570 Summary: [SELinux] rebootmgr: new features needs bash execution Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- rebootmgr get's a new feature: make the reboot command configureable, so that we could use kexec, too (https://github.com/SUSE/rebootmgr/issues/13) This requires that the policy for rebootmgr allows to execute a shell: type=AVC msg=audit(1671572322.755:93): avc: denied { execute } for pid=1445 comm="rebootmgrd" name="bash" dev="vda2" ino=43372 scontext=system_u:system_r:rebootmgr_t:s0 tcontext=system_u:object_r:shell_exec_t:s0 tclass=file permissive=0 -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1203425] New: gvfs-backend-samba not installed, needed for SMB support in gnome files
by bugzilla_noreply＠suse.com 23 Dec '22

23 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203425 Bug ID: 1203425 Summary: gvfs-backend-samba not installed, needed for SMB support in gnome files Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: pranav.sharma.ama(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- without the package installed, gnome files will fail with an error saying it can't mount an smb share, forcing the user to install with t-u. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1202875] New: MicroOS Desktop: Can't start packagekitd due libdnf/libtukit symbol error
by bugzilla_noreply＠suse.com 23 Dec '22

23 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202875 Bug ID: 1202875 Summary: MicroOS Desktop: Can't start packagekitd due libdnf/libtukit symbol error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: michal.vyskocil(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- packagekitd won't start on my MicroOS GNOME Desktop and produces error messages in Gnome Software. NAME="openSUSE Tumbleweed" # VERSION="20220827" packagekitd[28073]: what(): Can't load plugin "txnupd.so": Can't load shared library "/usr/lib64/libdnf/plugins/txnupd.so": /usr/lib64/libdnf/plugins/txnupd.so: undefined symbol: _ZN19TransactionalUpdate11Transaction4initENSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE It looks like this commit https://github.com/openSUSE/transactional-update/commit/2a2117d15a87dfbedea… broke the ABI. Not sure why BuildService haven't solved the problem by rebuilding the package. What libtukit.so.4 provides (I run my setup inside distrobox, hence /run/host paths poiting to the "host" - the MicroOS itself) objdump -C -T /run/host/lib64/libtukit.so.4.0.0 | grep 'Transaction::init' 0000000000020010 g DF .text 0000000000000c7f Base TransactionalUpdate::Transaction::init(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::optional<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >) What txnupd requires objdump -C -T /run/host/lib64/libdnf/plugins/txnupd.so | grep 'Transaction::init' 0000000000000000 DF *UND* 0000000000000000 Base TransactionalUpdate::Transaction::init(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) $ rpm -qf /lib64/libdnf/plugins/txnupd.so /lib64/libtukit.so.4.0.0 libdnf-plugin-txnupd-0.1.3-1.10.x86_64 libtukit4-4.0.1-1.1.x86_64 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1202290] New: Unable to update system using GNOME Software
by bugzilla_noreply＠suse.com 23 Dec '22

23 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202290 Bug ID: 1202290 Summary: Unable to update system using GNOME Software Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: songchuan.kang(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:103.0) Gecko/20100101 Firefox/103.0 Build Identifier: In GNOME Software, when clicking "Restart & Update" button in updates tab, an error messages pops up saying: > Unable to update "System Updates": Failed to create symlink: Read-only file system This is due to GNOME Software trying to call pk-trigger-offline-update which creates /system-update. However, this won't succeed because of the read-only file system. Reproducible: Always -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1201566] New: setroubleshoot packages in repositories bundle a broken version of setroubleshootd
by bugzilla_noreply＠suse.com 23 Dec '22

23 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201566 Bug ID: 1201566 Summary: setroubleshoot packages in repositories bundle a broken version of setroubleshootd Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Tumbleweed Status: NEW Severity: Minor Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: systemtool.exe(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The setroubleshoot-server 3.3.26 package bundles a version of setroubleshootd that requires a python2 module but is executed with python3 (as the shebang in the executable is /usr/bin/python3). The issue has been resolved in later versions. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1206008] sealert - ModuleNotFoundError: No module named 'formatter'
by bugzilla_noreply＠suse.com 23 Dec '22

23 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206008 http://bugzilla.opensuse.org/show_bug.cgi?id=1206008#c2 Richard Brown <rbrown(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbrown(a)suse.com, | |torsten(a)behrens.biz Flags| |needinfo?(torsten(a)behrens.b | |iz) --- Comment #2 from Richard Brown <rbrown(a)suse.com> --- sealert is not installed on MicroOS, so why is this a MicroOS bug? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206292] New: Wine/Proton not working relaibly with default SELinux configuration
by bugzilla_noreply＠suse.com 23 Dec '22

23 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206292 Bug ID: 1206292 Summary: Wine/Proton not working relaibly with default SELinux configuration Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: vortex(a)z-ray.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 863450 --> http://bugzilla.opensuse.org/attachment.cgi?id=863450&action=edit Proton Log file if running from a BtrFS volume Hey there, this is a bit of a wired issue I was facing and first thought Proton/Wine to be the issue if running from a BtrFS subvolume but turned out this to not be the case. So here is the situation I faced with only some games: Running a game with Proton or Wine installed in my $HOME which is a BtrFS volume by default on MicroOS caused it to sometimes fail to install some dependencies into a new prefix. Often this seemed to have been related to C++ runtime stuff Wine/Proton will install for some games. It failed to install those and the game where unable to operate properly. My first quick fix was to move Proton to an XFS drive by creating a new SteamLibrary for the Flatpak Steam Client and moving Proton there. Afterwards it operated successfully with no issues. Later on however I've read someone��s review of MicroOS mentioning he had to set: sudo setsebool -P selinuxuser_execmod 1 To make Proton work reliable. I tested this for myself with affected games and can confirm this worked. Additionally also Bottles, Lutris and Heroic Games Launcher where affected by this issue and randomly did not operate successfully when running games via their own Wine runners. The above SELinux config change fixed it also for them. Games I experienced to have issues with the missing SELinux config: - Satisfactory (Steam) - Control (Heroic Games Launcher, EGS version) - Creature in the Well /Heroic Games Launcher, EGS VVersion) - Age of Mythology: Extended Edition (Steam) In case some wants to counter test this. Would it be an issue if the above SELinux configuration could be set as it by default on MicroOS to make the gaming workload work OOTB? Or are there any reasons some should not change the above configuration. In that case I'd like to know why. Kind regards, V. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1201874] KDE pattern is using PackageKit instead of transactional-updates
by bugzilla_noreply＠suse.com 22 Dec '22

22 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201874 http://bugzilla.opensuse.org/show_bug.cgi?id=1201874#c2 Shawn Dunn <sfalken(a)cloverleaf-linux.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED CC| |sfalken(a)cloverleaf-linux.or | |g Resolution|--- |FIXED --- Comment #2 from Shawn Dunn <sfalken(a)cloverleaf-linux.org> --- Fix has been done. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1203887] New: Cannot changr auto-login settings (Gnome Settings)
by bugzilla_noreply＠suse.com 22 Dec '22

22 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203887 Bug ID: 1203887 Summary: Cannot changr auto-login settings (Gnome Settings) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: cutelilfroggy(a)protonmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Trying to change the auto-login settings under Gnome Settings -> Users fails. You can push the little slider to turn auto-login on, but that setting change is not respected. If you switch to a different category in the setting menu or restart the setting app, the slider is also back to its previous state. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1167780] MicroOS images don't update grub if booted without EFI
by bugzilla_noreply＠suse.com 22 Dec '22

22 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1167780 http://bugzilla.opensuse.org/show_bug.cgi?id=1167780#c13 Joed L <jlopez777+opensuse(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fvogt(a)suse.com Flags| |needinfo?(fvogt(a)suse.com) --- Comment #13 from Joed L <jlopez777+opensuse(a)gmail.com> --- Have folks landed on this? If so, should we document/close? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204792] New: Desktop-GNOME - Network Manager requires root password to change anything
by bugzilla_noreply＠suse.com 22 Dec '22

22 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1204792 Bug ID: 1204792 Summary: Desktop-GNOME - Network Manager requires root password to change anything Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: rbrown(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- System should be using the "Easy" polkit profile, not standard https://github.com/openSUSE/polkit-default-privs/pull/85 -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1203427] New: distrobox should be installed by default for microos desktop
by bugzilla_noreply＠suse.com 22 Dec '22

22 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1203427 Bug ID: 1203427 Summary: distrobox should be installed by default for microos desktop Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Enhancement Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: pranav.sharma.ama(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- distrobox requires less fiddling with podman / base image, especially to get gui apps to work -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1206501] New: Base:System/transactional-update: transactional-update.service forces reboot with rebootmgr disabled
by bugzilla_noreply＠suse.com 19 Dec '22

19 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206501 Bug ID: 1206501 Summary: Base:System/transactional-update: transactional-update.service forces reboot with rebootmgr disabled Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: reiokorn(a)tutanota.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I've disabled rebootmgr.service After the system is triggering the transactional-update.service (via timer or I do it manually) the system updates and immediately afterwards it will force a reboot via systemd. Behavior expected: No reboot. To reproduce: switch to a (slightly) older snapshot. disable rebootmgr: systemctl disable --now rebootmgr Trigger transactional-update service: systemctl start transactional-update.service Watch it reboot. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1206502] New: Base:System/transactional-update: transactional-update.timer - Persistent attribute of timer is ignored
by bugzilla_noreply＠suse.com 19 Dec '22

19 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206502 Bug ID: 1206502 Summary: Base:System/transactional-update: transactional-update.timer - Persistent attribute of timer is ignored Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: reiokorn(a)tutanota.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The current RandomizedDelaySec=2h attribute is also applied to every boot, so users who only run their computers for a short time won't get their daily updates reliably. Normally, you'd expect that if the timer isn't run at the time (0:00 + randomized-delay) it will trigger at the next boot. However, this isn't the case at all: This behavior was changed with this merge in systemd https://github.com/systemd/systemd/pull/11608 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1206502] Base:System/transactional-update: transactional-update.timer - Persistent attribute of timer is ignored
by bugzilla_noreply＠suse.com 19 Dec '22

19 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206502 https://bugzilla.suse.com/show_bug.cgi?id=1206502#c3 --- Comment #3 from Thorsten Kukuk <kukuk(a)suse.com> --- (In reply to B from comment #0) > Normally, you'd expect that if the timer isn't run at the time (0:00 + > randomized-delay) it will trigger at the next boot. No, this is not what we expect. > However, this isn't the case at all: This behavior was changed with this > merge in systemd https://github.com/systemd/systemd/pull/11608 Exactly for the reasons mentioned in the bug report we don't expect that, and need and depend on the current behavior, we were really happy that this did change. Else transactional-update would slow down the boot process and login of the user massively. We had that in the past. If you use only your computer for a short time every day, you cannot expect that you get all daily updates reliable anyway, the time may be too short. Your mentioned PR points to https://github.com/systemd/systemd/issues/21166 which explains in the last comment what you need to do: you need to adjust the configuration to your use case. We cannot let everybody else suffer just because there is one use case where the default does not fit, in this case, you have to adjust the configuration options. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206501] Base:System/transactional-update: transactional-update.service forces reboot with rebootmgr disabled
by bugzilla_noreply＠suse.com 19 Dec '22

19 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206501 https://bugzilla.suse.com/show_bug.cgi?id=1206501#c2 --- Comment #2 from Thorsten Kukuk <kukuk(a)suse.com> --- (In reply to B from comment #1) > I know there is a .conf file where I can choose which one it takes in /etc/ > and by default it is set to "auto" > > https://github.com/openSUSE/transactional-update/blob/master/etc/ > transactional-update.conf > > But how do I know which one it will take? Is there some kind of priority? > It looks to me that it just straight up skips to systemd reboot method even > though it shouldn't. The priority is pretty well documented: https://manpages.opensuse.org/transactional-update.8 https://manpages.opensuse.org/transactional-update.conf.5 So behaves exactly as documented. > However if it is working as intended then the information on how to disable > automatic reboot on the MicroOS Desktop Portal is wrong. It's a wiki, fix it. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206462] MicroOS can't fstrim some partitions of SSD hard drives
by bugzilla_noreply＠suse.com 16 Dec '22

16 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206462 https://bugzilla.suse.com/show_bug.cgi?id=1206462#c1 Thorsten Kukuk <kukuk(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kukuk(a)suse.com Assignee|kubic-bugs(a)opensuse.org |saweber(a)suse.com --- Comment #1 from Thorsten Kukuk <kukuk(a)suse.com> --- /.snapshot is no own device, it's only a subvolume of the root filesystem. And the root filesystem is mounted read-only, so it is correct that fstrim is skipping that (it cannot write to a read-only filesystem). No idea how this could be fixed. SLE Micro has the same problem... -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206462] New: MicroOS can't fstrim some partitions of SSD hard drives
by bugzilla_noreply＠suse.com 15 Dec '22

15 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206462 Bug ID: 1206462 Summary: MicroOS can't fstrim some partitions of SSD hard drives Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: reiokorn(a)tutanota.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Fstrim service is missing by default some mounts sudo /usr/sbin/fstrim --fstab --verbose /home/cb/MX500: 387,3 MiB (406089728 Bytes) auf /dev/disk/by-label/MX500 getrimmt /home/cb/Daten: 1,3 TiB (1427942354944 Bytes) auf /dev/disk/by-label/Daten getrimmt /boot/efi: 505,9 MiB (530456576 Bytes) auf /dev/nvme0n1p1 getrimmt cb@microos-pc:~> sudo fstrim -a --verbose /home/cb/Daten: 1,3 TiB (1427942354944 Bytes) auf /dev/sda1 getrimmt /home/cb/MX500: 387,3 MiB (406089728 Bytes) auf /dev/sdb1 getrimmt /boot/efi: 505,9 MiB (530456576 Bytes) auf /dev/nvme0n1p1 getrimmt is that working as intended? No fstrim for /.snapshots? However it works manually cb@microos-pc:~> sudo fstrim --verbose /.snapshots /.snapshots: 1,6 GiB (1715036160 Bytes) getrimmt -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206292] [SELinux] Wine/Proton not working reliably with default SELinux configuration
by bugzilla_noreply＠suse.com 12 Dec '22

12 Dec '22

1 0

[Bug 1206121] New: Slow system shutdown due to the failure of stopping a distrobox container
by bugzilla_noreply＠suse.com 09 Dec '22

09 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206121 Bug ID: 1206121 Summary: Slow system shutdown due to the failure of stopping a distrobox container Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: moonsolo(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 863370 --> https://bugzilla.suse.com/attachment.cgi?id=863370&action=edit log When I initiate a shutdown/reboot, it takes much longer to shut down with a distrobox container running than without. The file attached is the logs about a recent shutdown of my machine. Those logs show I initiated a shutdown at 21:51:34. However, the system didn't fully do that until 21:53:04 when the attempt to stop a running container, was timed out. By comparison, if I stop a container manually (e.g. through distrobox stop) before shutting down the system, the whole process finishes almost instantly. The snapshot I am using is 20221204 -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1206199] udisks2 ignores fstab mount options and uses the defaults instead
by bugzilla_noreply＠suse.com 08 Dec '22

08 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206199 Thorsten Kukuk <kukuk(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|MicroOS |Other Assignee|kubic-bugs(a)opensuse.org |thomas.blume(a)suse.com -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206199] New: udisks2 ignores fstab mount options and uses the defaults instead
by bugzilla_noreply＠suse.com 08 Dec '22

08 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206199 Bug ID: 1206199 Summary: udisks2 ignores fstab mount options and uses the defaults instead Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: alexviralata(a)posteo.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0 Build Identifier: I used KDE Partition Manager to configure fstab to automount all of my drives. I activated the users option, and added "exec" as a mount option. The "exec" option isn't working. After some discution on reddit, I found out that udisksctl is in fact reading the fstab file, but the actual mount option used are the "safe defaults", I found this by using "findmnt". Reproducible: Always Steps to Reproduce: 1.Configure fstab to automount any other drive with "exec" mount option 2.Restart computer 3.Try to execute anything on that drive Actual Results: Nothing, since the drive is mount with "safe defaults" and that includes "rw,nosuid,nodev,noexec,relatime,lazytime,etc..." Expected Results: To be able to execute programs inside my drives. All my drives have my user name as owner and group owner. I think that's the only reason why they do actually automount, but with the wrong flags. Once I have fstab configured the way I like, and I unmount and re-mount my drives with KDE Partition Manager, the fstab mount option do get used, among the "safe defaults". SELinux disabled/permissive made no change. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206087] MicroOS - autoyast2-4.5.11-1.1.noarch requires 'yast2-network >= 4.5.9'
by bugzilla_noreply＠suse.com 06 Dec '22

06 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206087 https://bugzilla.suse.com/show_bug.cgi?id=1206087#c4 --- Comment #4 from Thorsten Kukuk <kukuk(a)suse.com> --- You don't need to install autoyast on the system to install MicroOS via autoyast. Just boot the installer DVD and provide an autoyast.xml file. If it is about creating the autoyast.xml file: you need to write one, there are several examples files for MicroOS somewhere flying around. If it's not about installation, but configuration: we have ignition/combustion for exactly this. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206087] New: MicroOS - autoyast2-4.5.11-1.1.noarch requires 'yast2-network >= 4.5.9'
by bugzilla_noreply＠suse.com 06 Dec '22

06 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206087 Bug ID: 1206087 Summary: MicroOS - autoyast2-4.5.11-1.1.noarch requires 'yast2-network >= 4.5.9' Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: samcon(a)protonmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:107.0) Gecko/20100101 Firefox/107.0 Build Identifier: When attempting to install autoyast2 on MicroOS ``` transactional-update pkg install autoyast2 Checking for newer version. transactional-update 4.1.0 started Options: pkg install autoyast2 Separate /var detected. 2022-12-06 10:18:51 tukit 4.1.0 started 2022-12-06 10:18:51 Options: -c58 open 2022-12-06 10:18:52 Using snapshot 58 as base for new snapshot 59. 2022-12-06 10:18:52 Syncing /etc of previous snapshot 57 as base into new snapshot "/.snapshots/59/snapshot" 2022-12-06 10:18:52 SELinux is enabled. ID: 59 2022-12-06 10:18:58 Transaction completed. Calling zypper install 2022-12-06 10:19:00 tukit 4.1.0 started 2022-12-06 10:19:00 Options: callext 59 zypper -R {} install autoyast2 2022-12-06 10:19:00 Executing `zypper -R /tmp/transactional-update-K8KWbl install autoyast2`: Loading repository data... Reading installed packages... Resolving package dependencies... Problem: the to be installed autoyast2-4.5.11-1.1.noarch requires 'yast2-network >= 4.5.9', but this requirement cannot be provided not installable providers: yast2-network-4.5.10-1.1.noarch[repo-oss] Solution 1: deinstallation of busybox-hostname-1.35.0-25.1.noarch Solution 2: do not install autoyast2-4.5.11-1.1.noarch Solution 3: break autoyast2-4.5.11-1.1.noarch by ignoring some of its dependencies Choose from above solutions by number or cancel [1/2/3/c/d/?] (c): c 2022-12-06 10:19:40 Application returned with exit status 4. ERROR: zypper install on /.snapshots/59/snapshot failed with exit code 4! Removing snapshot #59... 2022-12-06 10:19:41 tukit 4.1.0 started 2022-12-06 10:19:41 Options: abort 59 2022-12-06 10:19:41 Discarding snapshot 59. 2022-12-06 10:19:42 Transaction completed. transactional-update finished ``` OS info: ``` $ cat /etc/os-release NAME="openSUSE MicroOS" # VERSION="20221204" ID="opensuse-microos" ID_LIKE="suse opensuse opensuse-tumbleweed" VERSION_ID="20221204" PRETTY_NAME="openSUSE MicroOS" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:microos:20221204" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:MicroOS" LOGO="distributor-logo-MicroOS" ``` Reproducible: Always Steps to Reproduce: 1. run latest version of MicroOS 2. transactional-update pkg install autoyast2 Actual Results: Problem: the to be installed autoyast2-4.5.11-1.1.noarch requires 'yast2-network >= 4.5.9', but this requirement cannot be provided not installable providers: yast2-network-4.5.10-1.1.noarch[repo-oss] Solution 1: deinstallation of busybox-hostname-1.35.0-25.1.noarch Solution 2: do not install autoyast2-4.5.11-1.1.noarch Solution 3: break autoyast2-4.5.11-1.1.noarch by ignoring some of its dependencies Expected Results: autoyast2 is installed -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1206087] MicroOS - autoyast2-4.5.11-1.1.noarch requires 'yast2-network >= 4.5.9'
by bugzilla_noreply＠suse.com 06 Dec '22

06 Dec '22

https://bugzilla.suse.com/show_bug.cgi?id=1206087 https://bugzilla.suse.com/show_bug.cgi?id=1206087#c1 Thorsten Kukuk <kukuk(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |kukuk(a)suse.com Resolution|--- |WONTFIX --- Comment #1 from Thorsten Kukuk <kukuk(a)suse.com> --- That's normal and expected. First, YaST is not supported on MicroOS and that's why it is not installed there. Second, we have dependencies to exactly express this: to create conflicts if something should be installed which is incompatible to what is already installed, and we offer a solution to solve this conflict. So just tell zypper how you want to resolve the conflict and don't abort. There is no way to make all packages always installable on every product without ever creating a conflict. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1206008] sealert - ModuleNotFoundError: No module named 'formatter'
by bugzilla_noreply＠suse.com 05 Dec '22

05 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1206008 http://bugzilla.opensuse.org/show_bug.cgi?id=1206008#c1 Torsten Behrens <torsten(a)behrens.biz> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|X11 Applications |MicroOS Assignee|screening-team-bugs(a)suse.de |kubic-bugs(a)opensuse.org --- Comment #1 from Torsten Behrens <torsten(a)behrens.biz> --- changed to microos -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1205997] New: SELinux policy prevents launching steam games and bottles applications
by bugzilla_noreply＠suse.com 05 Dec '22

05 Dec '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205997 Bug ID: 1205997 Summary: SELinux policy prevents launching steam games and bottles applications Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Critical Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: ficous(a)protonmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:107.0) Gecko/20100101 Firefox/107.0 Build Identifier: I've tested on Silverblue, MicroOS, Leap, and Tumbleweed all on fresh VMs. This issue only occurs on MicroOS. 32 bit applications launched through Steam crash instantly as both native and wine apps, and any application run through Bottles, either 32 or 64 bit, will crash instantly. Steam and Bottles programs run though wine give this error: > wine: could not load kernel32.dll, status c0000135 Native steam games give this error: > failed to dlopen /home/shaw/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Left 4 Dead 2/bin/engine.so error=/home/shaw/.var/app/com.valvesoftware.Steam/.local/share/Steam/steamapps/common/Left 4 Dead 2/bin/engine.so: cannot enable executable stack as shared object requires: Permission denied failed to dlopen engine.so error=engine.so: cannot enable executable stack as shared object requires: Permission denied AppFramework : Unable to load module engine.so! Unable to load interface VCvarQuery001 from engine.so Of note, 64 bit applications through steam (like rimworld) work just fine with SELinux enabled, while 32 bit games like L4D2 crash with that second error code above. What I find interesting is in both of these failures the programs report that they aren't able to find or access libraries they need. All my searching kept turning up someone familiar, and turns out when I disable SELinux the problem vanishes entirely. I A-B tested back and forth and everytime I disable SELinux I can launch everything perfectly, but once I re-enable it's sad gamer town again. I'm 100% out of my depth when it comes to actual SELinux configuration, so I'm really at an impass. I have tried scowering wine_selinux's manpage and I applied these modifications to the system, but there was no change in behavior. >semanage permissive -a wine_t setsebool -P mmap_low_allowed 1 setsebool -P wine_mmap_zero_ignore 1 Additionally, this issue or set of issues doesn't seem to be limited to my machine. [Similar wine issue reproduced by BottlesDev](https://github.com/bottlesdevs/Bottles/issues/1968#issuecomment… [Similar native Issue](https://github.com/flathub/com.mattjakeman.ExtensionManager/issues/2… [Similar native issue](https://github.com/flathub/com.parsecgaming.parsec/issues/18) [Similar native issue](https://github.com/flathub/net.jami.Jami/issues/52#issue-1254111513) [Somewhat Similar Garry's Mod issue](https://github.com/Facepunch/garrysmod-issues/issues/5056#issue-9973… *it's always SELinux :P* Reproducible: Always Steps to Reproduce: 1. Install MicroOS 2. Install Bottles 3. Create a Gaming bottle (which partially fails silently due to this issue) 4. Install Battlenet 5. Battlenet will not be installed because the installer executable never executed During steps 3 and 4 the *wine: could not load kernel32.dll, status c0000135* error will spam every time bottles attempts to launch an executable. 1. Install MicroOS 2. Install Steam 3. Install any 32bit game. Fistful of Frags is free and affected by this 4. Launch the game natively or through proton 5. Instant crash, or if you're lucky you'll get a gui error Actual Results: N/A Expected Results: N/A MicroOS fresh install into a VM. Nothing installed, modified, or tweaked other than installing bottles. -- You are receiving this mail because: You are the assignee for the bug.

1 2