- openSUSE Kubic Bugs

[Bug 1208616] Unable to boot on encrypted RAID 1 Btrfs install
by bugzilla_noreply＠suse.com 24 Feb '23

24 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1208616 https://bugzilla.suse.com/show_bug.cgi?id=1208616#c5 Kelvin Hu <hukelvin99(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #865091|0 |1 is obsolete| | --- Comment #5 from Kelvin Hu <hukelvin99(a)gmail.com> --- Created attachment 865102 --> https://bugzilla.suse.com/attachment.cgi?id=865102&action=edit RAID 1 settings enabled explicitly It looks like the default RAID level for both data and metadata is dependent on disk configuration. I've performed the same steps again while explicitly setting to RAID 1 for both. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208616] Unable to boot on encrypted RAID 1 Btrfs install
by bugzilla_noreply＠suse.com 23 Feb '23

23 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1208616 https://bugzilla.suse.com/show_bug.cgi?id=1208616#c4 --- Comment #4 from Kelvin Hu <hukelvin99(a)gmail.com> --- Another thing to note, I didn't change any of the default Btrfs settings during the installation so I'm actually not sure if it's RAID 1, I'll double check within the next 24 hours and post an update (and corresponding logs) then. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208616] New: Unable to boot on encrypted RAID 1 Btrfs install
by bugzilla_noreply＠suse.com 23 Feb '23

23 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208616 Bug ID: 1208616 Summary: Unable to boot on encrypted RAID 1 Btrfs install 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: hukelvin99(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 865089 --> http://bugzilla.opensuse.org/attachment.cgi?id=865089&action=edit The looping errors outputted Hi all, as in the title, I've successfully installed but failed to boot on an encrypted Btrfs RAID 1 setup. I've also tested this on the KDE variant which yields the same outcome. Current hardware: - Gigabyte Aorus 5 KE4 laptop with two deviations - Two NVMe SSDs, a WD_BLACK SN770 1TB and a Samsung MZVL21T0HCLR-00B00 (OEM PM9A1) - 64GiB (2x 32GiB) DDR4. Steps I performed during setup: - On partitioning, went through the guided proposal with disk encryption enabled. - After that, performed an expert partitioning with the current proposal. - Created a new partition on second drive with max size, role set to raw volume, and drive encrypted. - Under the Btrfs tab in the sidebar, I added the aforementioned encrypted second drive to the one created as part of the guided setup via the used devices tab. - Under Security, enabled firewall and disabled SSH service Steps performed during boot: - Entered the password when prompted for both drives - Selected default boot under Grub. - Error loops for a period of time. Afterwards the system reboots. Additional note: - The following attached images were from a Qemu/KVM (Proxmox specifically) VM, but the same behaviour was observed on a bare metal install. -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1208616] Unable to boot on encrypted RAID 1 Btrfs install
by bugzilla_noreply＠suse.com 23 Feb '23

23 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1208616 https://bugzilla.suse.com/show_bug.cgi?id=1208616#c2 Ancor Gonzalez Sosa <ancor(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ancor(a)suse.com --- Comment #2 from Ancor Gonzalez Sosa <ancor(a)suse.com> --- Although the steps are well described, it would be even better to have installation logs. They describe the storage (partitioning, encryption, etc.) in better detail. https://en.opensuse.org/openSUSE:Report_a_YaST_bug -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208218] New: Mendeley flatpak fails to start in MicroOS - Gnome desktop
by bugzilla_noreply＠suse.com 15 Feb '23

15 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208218 Bug ID: 1208218 Summary: Mendeley flatpak fails to start in MicroOS - Gnome desktop 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: sunscape1(a)hotmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Installed the Mendeley flatpak from flathub in MicroOS, but it will not launch. Mendeley is a popular reference manager. NAME="openSUSE MicroOS" VERSION="20230211" From a terminal, the error is... /app/extra/bin/mendeleydesktop: error while loading shared libraries: libQt5WebEngineCore.so.5: cannot enable executable stack as shared object requires: Permission denied Tried to install libqt5-qtwebengine, but the error persists. Is this a MicroOS issue or with the flatpak itself? -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1208256] New: Flatpak Access Control KCM not installed by default after updating to plasma 5.27
by bugzilla_noreply＠suse.com 15 Feb '23

15 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208256 Bug ID: 1208256 Summary: Flatpak Access Control KCM not installed by default after updating to plasma 5.27 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: alexandre(a)eskulap.fr QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello all ! Configuration : Lenovo Thinkpad P14s 20Y Ryzen 4750U Opensuse MicroOS (installation from 20230209) with KDE Plasma on Wayland Summary of the problem : Having installed a fresh version of MicroOS Plasma, there is no access to the all new and shiny "Access control for Flatpaks" KCM. It is, indeed, not installed during the update to plasma 5.27. Steps to reproduce : 1 - Install MicroOS with KDE Plasma 2 - Boot in Plasma and update to 20230213. 3 - Reboot and go to "Settings" and then "Applications" Actual results : 1 - No "Access Control for Flatpaks" KCM visible. Expected results : Having access to the KCM to manage Flatpaks permissions. Mitigation : By installing the adequate KCM : sudo transactional-update pkg install kcm_flatpak Thank you ! -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1208255] New: No image or document viewer installed on MicroOS Plasma by default
by bugzilla_noreply＠suse.com 15 Feb '23

15 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208255 Bug ID: 1208255 Summary: No image or document viewer installed on MicroOS Plasma by default 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: alexandre(a)eskulap.fr QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello all ! Configuration : Lenovo Thinkpad P14s 20Y Ryzen 4750U Opensuse MicroOS (installation from 20230209) with KDE Plasma on Wayland Summary of the problem : Having installed a fresh version of MicroOS Plasma, there is no document or image viewer installed by default, or even included with the "First Boot" installation of Flatpaks (Firefox, Calculator...) Steps to reproduce : 1 - Install MicroOS with KDE Plasma 2 - Boot in Plasma and search for "Gwenview" or "Okular" in plasma menu, or try to open an image or a PDF. Actual results : 1 - Neither Gwenview or Okular are installed 2 - A lot of images an documents can not be seen by default. Expected results : Given the importance for a desktop user to have access to a document and an image viewer, is it possible to include them in the "First boot" installation ? Mitigation : By installing the adequate flatpaks : flatpak install gwenview okular It's more of an observation than a bug I think, and I would like to know if more people are interested in proposing by default a document and an image viewer in MicroOS Plasma. Thank you ! -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1208265] New: Automatic transactional-update doesn't agree to the NVIDIA license which leads to the update failing.
by bugzilla_noreply＠suse.com 15 Feb '23

15 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208265 Bug ID: 1208265 Summary: Automatic transactional-update doesn't agree to the NVIDIA license which leads to the update failing. 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: touko.alasavikota(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/110.0 Build Identifier: MicroOS snapshot 20230212 with the KDE Plasma desktop. Fail occured when upgrading to snapshot 20230213. When running a system with an NVIDIA GPU, one often needs to use the proprietary drivers which in this case are included in the https://download.nvidia.com/opensuse/tumbleweed repository. After installing the drivers, if the next system upgrade contains updates to the NVIDIA packages, transactional-update won't agree to the license. This leads to the transactional-update to fail. Reproducible: Didn't try Steps to Reproduce: 1. Install proprietary NVIDIA drivers by running the following commands: # Add the repository containing the proprietary driver packages sudo zypper addrepo --refresh https://download.nvidia.com/opensuse/tumbleweed NVIDIA # Install drivers to the next snapshot (and the user accepts the license interactively here) sudo transactional-update pkg install nvidia-video-G06 nvidia-gl-G06 # Boot to the next snapshot systemctl reboot 2. Run the next transactional update that has upgrades for the NVIDIA packages. Actual Results: Transactional update fails because it answered "no" to the NVIDIA license agreement. Transactional update is aborted and the snapshot is discarded. Expected Results: Transactional update should agree to the license agreement and continue with the update. This might happen because of wrong options supplied to zypper dup. transactional-update calls "zypper --no-cd dup -y --auto-agree-with-product-licenses" while upgrading the next snapshot. However, I don't see "--auto-agree-with-product-licenses" while using the bash auto complete to search for options. I only see "--auto-agree-with-licenses". -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1208171] New: Unable to switch to Nvidia or Intel appropriately on MicroOS
by bugzilla_noreply＠suse.com 13 Feb '23

13 Feb '23

https://bugzilla.suse.com/show_bug.cgi?id=1208171 Bug ID: 1208171 Summary: Unable to switch to Nvidia or Intel appropriately on MicroOS Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: groguko36(a)tuta.io QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I'm using Micro OS Gnome here. I installed the Nvidia G06 driver with `suse-prime` and `bbswitch`. I had trouble with switching graphic cards. According to `prime-select.log', it 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. Here is the part of the log: ``` [ 18:36:16 ] service restored by user [ 18:38:35 ] user_logout_waiter: started [ 18:38:35 ] user_logout_waiter: X restart detected, preparing switch to intel [ 18:38:35 ] Forcing nvidia due to Intel card not found [ 18:38:35 ] Unloading bbswitch and switching nvidia ON... [ 18:38:38 ] PCI BusID of NVIDIA card could not be detected! [ 18:38:38 ] Configuration failed [ 18:39:42 ] Boot: setting-up card [ 18:39:42 ] HotSwitch: completed! ``` Interestingly, when I switched to Nvidia, `suse-prime` complained about not able to detect Nvidia and wanted to switch to Intel. This time the Intel just mysteriously worked along with bbswitch. ``` [ 20:47:07 ] user_logout_waiter: started [ 20:47:07 ] user_logout_waiter: X restart detected, preparing switch to nvidia [ 20:47:07 ] Forcing intel due to NVIDIA card not found [ 20:47:07 ] NVIDIA card will be switched off, NVIDIA offloading will not be available [ 20:47:07 ] trying switch OFF nvidia: [bbswitch] NVIDIA card is OFF [ 20:47:07 ] Intel card correctly set [ 20:47:07 ] HotSwitch: starting Display Manager [ 20:47:08 ] HotSwitch: completed! ``` I think these are MicroOS exclusive issues, as I never encountered them on Tumbleweed. It's similar to one of the old issues here reported two years ago. Switching to Nvidia G05 driver doesn��t help either. The issue was also reported on the SUSE-Prime's page: By default, MicroOS comes with less installed packages than Tumbleweed, nor does it have ��recommended packages�� like Tumbleweed. For example, my Tumbleweed ships with packages like intel-media-driver intel-vaapi-driver xorg-x11-driver-video libvulkan_intel Mesa-vulkan-device-select, which MicroOS doesn��t. Here I��m wondering if missing driver-related packages are missing might be the cause of the issues mentioned above. Or maybe there is something wrong with detecting graphic card on MicroOS' end. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1208163] New: microOS Plasma - sddm wallpaper change is not possible
by bugzilla_noreply＠suse.com 11 Feb '23

11 Feb '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208163 Bug ID: 1208163 Summary: microOS Plasma - sddm wallpaper change is not possible Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Enhancement 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: --- kcm_sddm is unable to change the wallpaper on microOS Plasma. Most likely due to configurations being written by default into an ro location. -- You are receiving this mail because: You are the assignee for the bug.

1 1