April 2023 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[Bug 1210975] New: MicroOSD Plasma: connecting USB stick with distro ISO shows duplicate entries
by bugzilla_noreply＠suse.com 30 Jun '23

30 Jun '23

https://bugzilla.suse.com/show_bug.cgi?id=1210975 Bug ID: 1210975 Summary: MicroOSD Plasma: connecting USB stick with distro ISO shows duplicate entries 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: herzenschein(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 866680 --> https://bugzilla.suse.com/attachment.cgi?id=866680&action=edit Duplicate in plasmoid Plugging a USB stick that was flashed with isoimagewriter or Balena Etcher shows two entries in the removable disks plasmoid and in Dolphin. See attached screenshots. On Fedora this doesn't happen. This issue occurred with both the Kubuntu and Fedora ISOs. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1210964] MicroOS does not boot after install on Lenovo ThinkPad X1 Carbon (4th Gen)
by bugzilla_noreply＠suse.com 30 Apr '23

30 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1210964 https://bugzilla.suse.com/show_bug.cgi?id=1210964#c8 Doe <tckkv3bu9k0(a)temp.mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Doe <tckkv3bu9k0(a)temp.mailbox.org> --- I've solved the issue. What I did: - changed in the BIOS/UEFI Mode via "Startup ➙ UEFI/Legacy Boot: Both" to "UEFI Only" - boot from USB Media - started the installation process again - noticed minor changes in installation summary, like Update NVRAM: "active" - changed the follwing item: "Systemstart" Secure Boot: "active" => "deactivated" - started the installtion routine - reboot => done; The system re-boots as expected To sum up: After the installation I noticed the new OpenSuse boot screen was coming up on reboot. I guess the installation script wasn't aware of the hybrid UEFI/BIOS setting of my Lenovo Laptop mentioned above and might prepared the System as Legacy BIOS Linux client instead of an UEFI-based one. Which means it doesn't used efibootmgr to write/alter the UEFI boot entry/touch the NVRAM in my case. I had to "force" the installation process to (re-)write the boot entry in the NVRAM, by setting the Firmware to "UEFI-only" mode in the first place. To be clear: My conclusion is based on my observation and extremely "not deep-dive debugging". It could be bloody wrong and I don't want to be rude to the devs or blame your nice upcoming new OS. I just thought that my case could sand down the possible rough edges of the release candidate to make a desktop user's experience as pleasant as possible :) . Have a nice weekend folks! Regards, C. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1210964] MicroOS does not boot after install on Lenovo ThinkPad X1 Carbon (4th Gen)
by bugzilla_noreply＠suse.com 29 Apr '23

29 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1210964 https://bugzilla.suse.com/show_bug.cgi?id=1210964#c7 Richard Brown <rbrown(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbrown(a)suse.com Priority|P2 - High |P5 - None --- Comment #7 from Richard Brown <rbrown(a)suse.com> --- Resetting priority, as it is a judgement made by individuals who are responsible to resolve the bug. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1210964] MicroOS does not boot after install on Lenovo ThinkPad X1 Carbon (4th Gen)
by bugzilla_noreply＠suse.com 28 Apr '23

28 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1210964 https://bugzilla.suse.com/show_bug.cgi?id=1210964#c6 --- Comment #6 from Thorsten Kukuk <kukuk(a)suse.com> --- I have the same Notebook and that works fine with openSUSE Tumbleweed, which uses the same bootloader configuration. You need UEFI, if you enable or disable secure boot does not matter. But you have to decide before the installation what you want to use: installing with disabled secure boot and enable it later is in general not a good idea, independent of MicroOS or Tumbleweed. (In reply to Doe from comment #5) > Could it be that MicroOS is "made just for UEFI-clients"? No, MicroOS works with all kinds of firmware like Tumbleweed. > I wonder if the Lenovo default value "Legacy/UEFI: both", "Legacy first" > leads to my problem. Could be, I don't remember what the default was. > Should I install MicroOS with secure boot and UEFI-only mode again? MicroOS > seems to use GPT, so in my opinion this kicks out Legacy-Clients with only > BIOS, or am I wrong? GPT has nothing to do with legacy or UEFI firmware. I would suggest to switch to UEFI only, so that no part of the system get's confused and makes a wrong assumption and install new. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1210964] New: MicroOS does not boot after install on Lenovo ThinkPad X1 Carbon (4th Gen)
by bugzilla_noreply＠suse.com 28 Apr '23

28 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1210964 Bug ID: 1210964 Summary: MicroOS does not boot after install on Lenovo ThinkPad X1 Carbon (4th Gen) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 64bit OS: Other Status: NEW Severity: Major Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: tckkv3bu9k0(a)temp.mailbox.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; rv:112.0) Gecko/20100101 Firefox/112.0 Build Identifier: Dear Devs, after I've installed MicroOS on my Lenovo ThinkPad X1 Carbon (4th Gen), it won't boot. The boot menu seems to be a Lenovo one and not GRUB2. It has two tabs, first is called "x" the second does have the Lenovo Diagnostics. When I click on the SUSE boot entry, the screen is black for several seconds and shows the boot menu again. I have to use the MicroOS usb boot media and issue "Boot Linux System" to boot into MicroOS No command in transaction-update menu (bootloader, initrd, grub.cfg) to re-install the bootloader, create grub.cfg or initrd helps to solve my issue. I have no idea to solve this. Reproducible: Always Steps to Reproduce: 1. Boot from MicroOS USB Media 2. Install MicroOS 3. Reboot Actual Results: It does not boot into MicroOS Expected Results: It should boot into the freshly installed MicroOS Basic info about my system: BIOS/UEFI-Settings: UEFI/Legacy Boot :Both CSM-Support: yes lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 476.9G 0 disk ├─sda1 8:1 0 8M 0 part └─sda2 8:2 0 476.9G 0 part /usr/local /opt /srv /home /boot/writable /boot/grub2/x86_64-efi /boot/grub2/i386-pc /.snapshots /var /root / sdb 8:16 1 7.6G 0 disk ├─sdb1 8:17 1 4.4M 0 part └─sdb2 8:18 1 3.9G 0 part /run/media/$USER/openSUSE-MicroOS-DVD-x86_64 -- You are receiving this mail because: You are the assignee for the bug.

1 6

[Bug 1210710] New: Including `inxi` in default MicroOS installation
by bugzilla_noreply＠suse.com 22 Apr '23

22 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1210710 Bug ID: 1210710 Summary: Including `inxi` in default MicroOS installation 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: groguko36(a)pm.me QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- I'm running a Optimus setup (Intel iGPU and Nvidia dGPU). I installed the Nvidia G06 driver with `suse-prime` and `bbswitch`. I had trouble with switching graphic cards. `suse-prime` couldn't detect Intel when I tried to switch to it. Then it would attempt to switch to Nvidia instead and caused black screen with login, because it also couldn't detect Nvidia. The problem is solved by installing the `inxi` package. It seems `inxi` is necessary for detecting running graphic card for `suse-prime`. Therefore, I think `inxi` should come as the default package in MicroOS. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[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 1210483] New: RTL8821CE Firmware not installed on MicroOS
by bugzilla_noreply＠suse.com 20 Apr '23

20 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1210483 Bug ID: 1210483 Summary: RTL8821CE Firmware not installed on 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: izineth09(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- OpenSUSE MicroOS does not install the kernel-firmware-realtek package when installing on an HP 14 laptop with RTL8821CE wifi card. Installing the kernel-firmware-realtek-20230320.noarch.rpm package from the installation media manually after installation fixes the issue. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1206946] New: First boot fails with USB devices plugged in
by bugzilla_noreply＠suse.com 19 Apr '23

19 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1206946 Bug ID: 1206946 Summary: First boot fails with USB devices plugged in 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: sebastian.kuebbeler(a)gmx.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:108.0) Gecko/20100101 Firefox/108.0 Build Identifier: I am trying to install MicroOS on a Raspberry Pi, but it fails when non-simple USB devices are attached. I used this image: openSUSE-MicroOS.aarch64-16.0.0-ContainerHost-RaspberryPi-Snapshot20230101.raw.xz I double checked this against the latest Tumbleweed image: openSUSE-Tumbleweed-ARM-JeOS-raspberrypi.aarch64-2022.12.31-Snapshot20230101.raw.xz I also tested with the latest Leap image: openSUSE-Leap-15.4-ARM-JeOS-raspberrypi.aarch64-2022.09.29-Build31.38.raw.xz The Leap Image works, so it must be an issue with Tumbleweed. Reproducible: Always Steps to Reproduce: 1. Boot 2. Enters UBoot 3. Reboots -> Loop Actual Results: Failed to boot Expected Results: Should boot -- You are receiving this mail because: You are the assignee for the bug.

1 5

[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 1210492] New: Gnome Settings -> Color option is not available in the default install
by bugzilla_noreply＠suse.com 17 Apr '23

17 Apr '23

http://bugzilla.suse.com/show_bug.cgi?id=1210492 Bug ID: 1210492 Summary: Gnome Settings -> Color option is not available in the default install 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: silviucc(a)outlook.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0 Build Identifier: On a default install of MicroOS this option is missing. Reproducible: Always Steps to Reproduce: 1.Start Settings. There should be a "Color" option on the left column that allows installing and managing color profiles for various devices like displays, printers, etc. Actual Results: The "Color" option is missing. Expected Results: There should be a "Color" option on the left column that allows installing and managing color profiles for various devices like displays, printers, etc. The workaround is to install the missing package in transactional-update shell gnome-control-center-color Maybe the package should be part of the OS image. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1210330] New: MicroOS Desktop Plasma: Kate Project plugin doesn't work
by bugzilla_noreply＠suse.com 13 Apr '23

13 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210330 Bug ID: 1210330 Summary: MicroOS Desktop Plasma: Kate Project plugin doesn't work 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: herzenschein(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Kate is not installed as a flatpak. I think it came with the default snapshot, as there's no Kate on flathub, only flathub-beta and kdeapps. When I initialize or clone any git repository and open its files with Kate, the Project pane on the left provided by the Projects plugin doesn't update to show the contents of the repository. Additionally, the Git pane, also provided by the Projects plugin, doesn't show any changes if I edit and save any files in the repository, even when I click the Refresh button. This works fine with Kate installed in a distrobox container, as well as Kate compiled from within a distrobox container. Unsure if this is related, but the experimental Kate flatpak doesn't have a functional Projects plugin either. I wonder if something is missing from both. https://github.com/flathub/org.kde.kate/issues/32 -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1210026] New: Delay of portal service start on MicroOS Desktop KDE delays flatpak application startup.
by bugzilla_noreply＠suse.com 13 Apr '23

13 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210026 Bug ID: 1210026 Summary: Delay of portal service start on MicroOS Desktop KDE delays flatpak application startup. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: touko.alasavikota(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Running MicroOS Desktop KDE snapshot 20230330 (originally 20230212). Proprietary nvidia drivers and wayland. My install comes automatically with multiple xdg-desktop-portal backends: xdg-desktop-portal-gnome, xdg-desktop-portal-kde and xdg-desktop-portal-gtk. The problem is that the GNOME backend is started first and it times out and fails. I think that this delays the start of xdg-desktop-portal and flatpak applications like Firefox won't start during the delay. The portal service is able to start after the timeout and everything works normally after that. This github issue might be related: https://github.com/flatpak/xdg-desktop-portal/issues/656 I tested installing a fresh MicroOS Desktop 20230330 with both GNOME and KDE flavors. They only had the their respective backends installed with no flatpak application launch delays on startup. My other MicroOS Desktop KDE is originally from snapshot 20230212 so that might have had the GNOME implementation included from the start. I'm not sure if multiple xdg-desktop-portal implementations should even be installed in the first place but in this state the system will have a consistent timeout with every boot. -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1210302] New: Snapshot entries aren't being created for grub
by bugzilla_noreply＠suse.com 11 Apr '23

11 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210302 Bug ID: 1210302 Summary: Snapshot entries aren't being created for grub 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: lilfrogg(a)posteo.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This is my second MicroOS install in a row where new snapshots at some point stopped showing up in the grub menu. The snapshots themselves are created as normal and it appears that the script of the grub2-snapper-plugin fails to create the entries because my snapshots appear to be writable for some reason. Here are some terminal outputs I was asked to create in the oS support channel: sudo find /.snapshots -maxdepth 2 -type f -name grub-snapshot.cfg �/.snapshots/91/grub-snapshot.cfg /.snapshots/grub-snapshot.cfg� Snapshot 91 is one I manually created with 'snapper create' which creates a grub entry. all the other snapshots don't show up Using 'sh -o xtrace usr/lib/snapper/plugins/grub --enable' in a transactional-update shell �+ set -e + grub_mkconfig=/usr/sbin/grub2-mkconfig + grub_mkrelpath=/usr/bin/grub2-mkrelpath + grub_script_check=/usr/bin/grub2-script-check + grub_setting=/etc/default/grub + grub_cfg=/boot/grub2/grub.cfg + grub_snapshot_cfg=/boot/grub2/snapshot_submenu.cfg + snapper_snapshot_path=/.snapshots + snapshot_submenu_name=grub-snapshot.cfg + snapper_snapshots_cfg=/.snapshots/grub-snapshot.cfg + hotkey= ++ uname -m + machine=x86_64 + case "$machine" in + cmdline='/usr/lib/snapper/plugins/grub --enable hotkey='\'''\''' + test 1 -gt 0 + option=--enable + shift + case "$option" in + opt_enable=true + test 0 -gt 0 + '[' xtrue = xtrue ']' + snapper_snapshots_cfg_refresh + '[' '!' -d /.snapshots ']' + cs= + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/79/snapshot + '[' '!' -d /.snapshots/79 -o -w /.snapshots/79/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/80/snapshot + '[' '!' -d /.snapshots/80 -o -w /.snapshots/80/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/81/snapshot + '[' '!' -d /.snapshots/81 -o -w /.snapshots/81/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/82/snapshot + '[' '!' -d /.snapshots/82 -o -w /.snapshots/82/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/83/snapshot + '[' '!' -d /.snapshots/83 -o -w /.snapshots/83/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/84/snapshot + '[' '!' -d /.snapshots/84 -o -w /.snapshots/84/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/85/snapshot + '[' '!' -d /.snapshots/85 -o -w /.snapshots/85/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/86/snapshot + '[' '!' -d /.snapshots/86 -o -w /.snapshots/86/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/87/snapshot + '[' '!' -d /.snapshots/87 -o -w /.snapshots/87/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/88/snapshot + '[' '!' -d /.snapshots/88 -o -w /.snapshots/88/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/89/snapshot + '[' '!' -d /.snapshots/89 -o -w /.snapshots/89/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/90/snapshot + '[' '!' -d /.snapshots/90 -o -w /.snapshots/90/snapshot ']' + continue + for s_dir in ${snapper_snapshot_path}/* + snapshot=/.snapshots/grub-snapshot.cfg/snapshot + '[' '!' -d /.snapshots/grub-snapshot.cfg -o -w /.snapshots/grub-snapshot.cfg/snapshot ']' + continue + hk= + '[' -z '' ']' ++ printf %s '' ++ sort -Vr + cat + /usr/bin/grub2-script-check /.snapshots/grub-snapshot.cfg.new + mv -f /.snapshots/grub-snapshot.cfg.new /.snapshots/grub-snapshot.cfg + '[' x = xtrue ']' + '[' x = xtrue ']'� ls -lad /.snap* �drwxr-x---. 1 root root 98 Apr 11 11:02 /.snapshots� mount | grep snapshots �/dev/mapper/cr_root on / type btrfs (ro,relatime,seclabel,space_cache=v2,subvolid=363,subvol=/(a)/.snapshots/90/snapshot) /dev/mapper/cr_root on /.snapshots type btrfs (rw,relatime,seclabel,space_cache=v2,subvolid=266,subvol=/@/.snapshots)� -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1210207] New: selinux: missing policy for dbus allow msg for xdm_t
by bugzilla_noreply＠suse.com 06 Apr '23

06 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1210207 Bug ID: 1210207 Summary: selinux: missing policy for dbus allow msg for xdm_t 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: luca.dimaio1(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 866166 --> https://bugzilla.suse.com/attachment.cgi?id=866166&action=edit generated rule for selinux with audit2allow After latest update of either gpg or selinux, now communication with gpg-agent is denied by selinux: Apr 06 09:47:58 localhost dbus-daemon[1914]: avc: denied { send_msg } for msgtype=method_return dest=:1.1048 spid=1892 tpid=5585 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:spc_t:s0 tclass=dbus permissive=0 Running audit2why avc: denied { send_msg } for msgtype=method_return dest=:1.1048 spid=1892 tpid=5585 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:system_r:spc_t:s0 tclass=dbus permissive=0 Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access. In fact, audit2allow generates a valid module, and everything works like before Attaching here the generated modules, loading them fixes the issue -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1210125] New: Unable to mount network Shares from within dolphin
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210125 Bug ID: 1210125 Summary: Unable to mount network Shares from within dolphin 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: sfalken(a)cloverleaf-linux.org QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Likely due to lacking kio_fuse and/or kdenetwork-filesharing. Currently poking at things and testing in VM -- You are receiving this mail because: You are the assignee for the bug.

1 1