December 2022 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[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