July 2022 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[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 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 1195878] New: [Build 20220211] openQA test fails in disk_boot
by bugzilla_noreply＠suse.com 26 Oct '22

26 Oct '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1195878 Bug ID: 1195878 Summary: [Build 20220211] openQA test fails in disk_boot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/2186742/modules/disk _boot/steps/5 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes ## Observation openQA test in scenario microos-Tumbleweed-MicroOS-Image-x86_64-microos@64bit fails in [disk_boot](https://openqa.opensuse.org/tests/2186742/modules/disk_boot/step… Feb 13 08:01:56.395743 localhost dracut-initqueue[502]: /sbin/ifup: line 135: dhclient: command not found ## Test suite description ## Reproducible Fails since (at least) Build [20220211](https://openqa.opensuse.org/tests/2186317) ## Expected result Last good: [20220210](https://openqa.opensuse.org/tests/2184227) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=microos… -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1183582] New: transactional server role has very inconsistent package selection (TW, SLE, Leap)
by bugzilla_noreply＠suse.com 10 Aug '22

10 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1183582 Bug ID: 1183582 Summary: transactional server role has very inconsistent package selection (TW, SLE, Leap) Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Selecting the transactional server role results in a very different selection of patterns and packages. On Tumbleweed: https://openqa.opensuse.org/tests/1667896#step/disable_grub_timeout/13 Documentation, Minimal Base, Enhanced Base, AppArmor, YaST Base, Software Management, Minimal Appliance Base On SLE 15 SP3: https://openqa.suse.de/tests/5670408#step/disable_grub_timeout/14 Minimal Base, Enhanced Base, AppArmor, 32-Bit Runtime Environment On Leap 15.3: https://openqa.opensuse.org/tests/1667171#step/disable_grub_timeout/13 Minimal Base, Minimal Appliance Base -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1196547] New: MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 10 Aug '22

10 Aug '22

https://bugzilla.suse.com/show_bug.cgi?id=1196547 Bug ID: 1196547 Summary: MicroOS Desktop GNOME system role doesn't preinstall language subpackages 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: fcrozat(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Follow-up of https://github.com/yast/skelcd-control-MicroOS/pull/51 Installing MicroOS Desktop (GNOME system role) doesn't install the language subpackages for the select language on the installer. Languages subpackages are currently handled as soft dependencies, which doesn't mix well with MicroOS relying only on requires. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1202000] New: [Build 20220729] openQA test fails in transactional_update: read-only file system
by bugzilla_noreply＠suse.com 30 Jul '22

30 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1202000 Bug ID: 1202000 Summary: [Build 20220729] openQA test fails in transactional_update: read-only file system Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/2488839/modules/tran sactional_update/steps/176 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: openQA Blocker: Yes In the openQA test for TW transactional server, it sometimes (50%?) comes up with /var and /etc read-only. The journal shows: Jul 30 14:51:59.631975 susetest systemd[1]: systemd-remount-fs.service: Main process exited, code=exited, status=1/FAILURE Jul 30 14:51:59.631989 susetest systemd[1]: systemd-remount-fs.service: Failed with result 'exit-code'. ... Jul 30 14:51:59.621373 susetest systemd-remount-fs[451]: /usr/bin/mount for / exited with exit status 32. ... Jul 30 14:51:59.650244 susetest systemd-remount-fs[457]: mount: /: mount point is busy. ... Jul 30 14:52:01.223177 susetest systemd[1]: Mounted /opt. Jul 30 14:52:01.238240 susetest systemd[1]: Mounted /srv. Jul 30 14:52:01.238624 susetest systemd[1]: Mounted /usr/local. ... Jul 30 14:52:01.591134 susetest apparmor.systemd[485]: mkstemp: Read-only file system I don't see the failure happening in earlier snapshots, so this might be something with the AppArmor update in 0729. ## Observation openQA test in scenario opensuse-Tumbleweed-DVD-x86_64-extra_tests_transactional_server@64bit fails in [transactional_update](https://openqa.opensuse.org/tests/2488839/modules/tra… ## Test suite description test transactional server. Maintainer: Zaoliang Luo <zluo(a)suse.com> ## Reproducible Fails since (at least) Build [20220729](https://openqa.opensuse.org/tests/2488609) ## Expected result Last good: [20220728](https://openqa.opensuse.org/tests/2486021) (or more recent) ## Further details Always latest result in this scenario: [latest](https://openqa.opensuse.org/tests/latest?arch=x86_64&distri=opensus… -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1186158] [SELinux] blocking podman socket access to /var/run/podman/podman.sock
by bugzilla_noreply＠suse.com 27 Jul '22

27 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1186158 https://bugzilla.suse.com/show_bug.cgi?id=1186158#c13 --- Comment #13 from Gayane Osipyan <gayane.osipyan(a)suse.com> --- Are there any updates ?Should we close bug ? -- You are receiving this mail because: You are the assignee for the bug.

1 0

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

26 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1201874 Bug ID: 1201874 Summary: KDE pattern is using PackageKit instead of transactional-updates 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: dgonzalez(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- As subject states, the KDE pattern was not adapted for using transactional updates. The issue was already fixed by @sfalken at https://github.com/yast/skelcd-control-MicroOS/pull/54, but we forgot to include a Bugzilla entry to please our CI. Thus, this report will be useful for tracking the change and sending the updated skelcd. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1171174] security enhancement: no setuid
by bugzilla_noreply＠suse.com 25 Jul '22

25 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1171174 https://bugzilla.suse.com/show_bug.cgi?id=1171174#c3 --- Comment #3 from Ludwig Nussel <lnussel(a)suse.com> --- Good catch. Unfortunately I can't find any records about who put that there. Looks like even the first SUSE-MicroOS had while the never was on openSUSE side. Would be interesting to see the fallout when fixing that for the next SLE-Micro version :) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1171174] security enhancement: no setuid
by bugzilla_noreply＠suse.com 22 Jul '22

22 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1171174 https://bugzilla.suse.com/show_bug.cgi?id=1171174#c2 Georg Pfuetzenreuter <georg.pfuetzenreuter(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |georg.pfuetzenreuter(a)suse.c | |om --- Comment #2 from Georg Pfuetzenreuter <georg.pfuetzenreuter(a)suse.com> --- Hi! According to your comment the default permission set on SLE Micro should be "paranoid". Indeed, the `config.sh` script in https://build.opensuse.org/package/view_file/SUSE:SLE-15-SP4:Update:Product… "attempts" to change the security setting with a reference to this bug but due to not specifying the "-i" flag in the `sed` line the change is merely printed and never actually written to the file: ``` # fix security level (boo#1171174) sed -e '/^PERMISSION_SECURITY=s/easy/paranoid/' /etc/sysconfig/security chkstat --set --system ``` This can be confirmed in `/etc/sysconfig/security` on a fresh copy of the SLE Micro .raw image: ``` PERMISSION_SECURITY="easy local" ``` Is this expected? Maybe I am missing something! :-) Best, Georg -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1201400] New: Unable to add a flatpak gnome repo due TLS error
by bugzilla_noreply＠suse.com 15 Jul '22

15 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1201400 Bug ID: 1201400 Summary: Unable to add a flatpak gnome repo due TLS error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major 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: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:101.0) Gecko/20100101 Firefox/101.0 Build Identifier: I've installed a fresh MicroOS Destkop 20220710, but I am unable finish the first installation or to add any flatpak repo. Reproducible: Always Steps to Reproduce: 1.flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo 2. or run mod-firstboot, but this does not provide any reasonable error Actual Results: F: Opening system flatpak installation at path /var/lib/flatpak F: Loading https://flathub.org/repo/flathub.flatpakrepo using libsoup error: Can't load uri https://flathub.org/repo/flathub.flatpakrepo: Unacceptable TLS certificate Expected Results: Repository being added. I found out that after a fresh installation neither flatpak neither curl have been working due the TLS certificates. I called sudo update-ca-certificates which fixed the curl part, but not the flatpak. I did a restart, but was the same. As this prevents me to install any application, I consider this as a major problem. -- You are receiving this mail because: You are the assignee for the bug.

1 8

[Bug 1186158] [SELinux] blocking podman socket access to /var/run/podman/podman.sock
by bugzilla_noreply＠suse.com 12 Jul '22

12 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1186158 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|SElinux is blocking podman |[SELinux] blocking podman |socket access to |socket access to |/var/run/podman/podman.sock |/var/run/podman/podman.sock -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 12 Jul '22

12 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c15 --- Comment #15 from Ludwig Nussel <lnussel(a)suse.com> --- (In reply to Richard Brown from comment #14) > (In reply to Ludwig Nussel from comment #13) > > (In reply to Alois Wohlschlager from comment #12) > > > [...] Some concrete examples > > > TW/MicroOS experience: > > > * enhanced_base -> plymouth: This is a Recommends, so it's not installed on > > > MicroOS today. The system works without a boot splash, but it looks nicer > > > with one. > > > > Plymouth needs to be made a requirement for graphical desktops > > unfortunately. If someone desperately doesn't want it installed, the pattern > > dragging plymouth in would have to be uninstalled. > > It's also worth considering on most systems plymouth starts slower than > GDM/SDDM, so the only real-world effect of installing plymouth is often the > addition of a flicker between grub and the login prompt, a flicker which is > noticibly absent on MicroOS. > > Personally I'd rather have no flicker rather than an ugly flicker that > doesn't have time for the human brain to register the fact there could have > been an image there. Absolutely. The point is that if the OS needs plymouth because we fail to make it boot fast and need to paper over the ugly messages then plymouth must be required. Or we fix the broken boot time and render plymouth obsolete. Then it doesn't need to be listed at all. IOW if plymouth is "recommended" there's something worth fixing. > > > * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a > > > Requires today. A desktop system can work without printing if so desired, > > > but a significant part of the userbase appreciates their printer working. > > > > That should neither be required nor recommended. If one plugs a USB printer, > > hardware supplements are supposed to pull in required packages. I wouldn't > > be surprised if that's broken (again) on openSUSE though. Also any > > assumptions about whether or not users with local printers constitute a > > significant part of the user base are based on pure guessing related to > > personal bias :-) > > It is a clear design requirement of the MicroOS Desktop that it must be " > small, but not at the expense of functionality. Printing, Gaming, Media > Production and much more should all work." > > And such things should work "out of the box" Again I agree. That cannot mean installing cups with all drivers and ppds for all printers ever manufactured on this planet by default though. Think out of the box to find a proper solution :-) -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c14 --- Comment #14 from Richard Brown <rbrown(a)suse.com> --- (In reply to Ludwig Nussel from comment #13) > (In reply to Alois Wohlschlager from comment #12) > > [...] Some concrete examples > > TW/MicroOS experience: > > * enhanced_base -> plymouth: This is a Recommends, so it's not installed on > > MicroOS today. The system works without a boot splash, but it looks nicer > > with one. > > Plymouth needs to be made a requirement for graphical desktops > unfortunately. If someone desperately doesn't want it installed, the pattern > dragging plymouth in would have to be uninstalled. It's also worth considering on most systems plymouth starts slower than GDM/SDDM, so the only real-world effect of installing plymouth is often the addition of a flicker between grub and the login prompt, a flicker which is noticibly absent on MicroOS. Personally I'd rather have no flicker rather than an ugly flicker that doesn't have time for the human brain to register the fact there could have been an image there. > > > * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a > > Requires today. A desktop system can work without printing if so desired, > > but a significant part of the userbase appreciates their printer working. > > That should neither be required nor recommended. If one plugs a USB printer, > hardware supplements are supposed to pull in required packages. I wouldn't > be surprised if that's broken (again) on openSUSE though. Also any > assumptions about whether or not users with local printers constitute a > significant part of the user base are based on pure guessing related to > personal bias :-) It is a clear design requirement of the MicroOS Desktop that it must be " small, but not at the expense of functionality. Printing, Gaming, Media Production and much more should all work." And such things should work "out of the box" https://en.opensuse.org/Portal:MicroOS/Desktop Therefore your 'concrete example' here is invalid and antithetical to the goals of the MicroOS Desktop Project -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c13 --- Comment #13 from Ludwig Nussel <lnussel(a)suse.com> --- (In reply to Alois Wohlschlager from comment #12) > Recommends are, in my book, supposed to be things which are in fact *not* strictly mandatory, but generally useful to have. That's the theory. In practice we ended up with a mess and without soft locks. Now those recommends are just a pita, haunting you if you don't also lock packages :-) They might be ok actually for something like, say FreeCAD, ie some extra app that you will for sure install manually and interactively. So the UI can show you specifically for that app what it recommends. For the thousands of OS components the recommends just lead to not seeing the forest for all the trees though. We'd be better off trying harder to avoid them. > [...] Some concrete examples > TW/MicroOS experience: > * enhanced_base -> plymouth: This is a Recommends, so it's not installed on > MicroOS today. The system works without a boot splash, but it looks nicer > with one. Plymouth needs to be made a requirement for graphical desktops unfortunately. If someone desperately doesn't want it installed, the pattern dragging plymouth in would have to be uninstalled. > (Same with the language magic this issue is about, but I don't > understand how it works exactly. The locale is some kind of virtual provides of the system and packages containing localization files supplement that. Hardware supplements work in a similar way. > * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a > Requires today. A desktop system can work without printing if so desired, > but a significant part of the userbase appreciates their printer working. That should neither be required nor recommended. If one plugs a USB printer, hardware supplements are supposed to pull in required packages. I wouldn't be surprised if that's broken (again) on openSUSE though. Also any assumptions about whether or not users with local printers constitute a significant part of the user base are based on pure guessing related to personal bias :-) > As a concrete example again, the x11 -> x11_enhanced -> web_browser > Recommends chain does make sense on traditional systems. On MicroOS not so > much, since you just install the browser using Flatpak. Also in that case the recommends should be removed IMO. Default applications can be pulled in by a specific pattern that is added explicitly by YaST when selecting a desktop via role. No need to express this via dependencies. But then maybe we should also stop treating the traditional desktop install as the Linux desktop demo show we have currently. We can do it like in MicroOS. Basic desktop only, ie fast install. Then have eg opensuse-welcome suggest a bunch of common apps with a nice UI on first boot. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c12 --- Comment #12 from Alois Wohlschlager <alois1(a)gmx-topmail.de> --- (In reply to Ludwig Nussel from comment #11) > If you have such a list already, a first approach could also be to try to > simply file sr's to eliminate those recommends. That's what I did in the > past with some packages and generally didn't get much pushback. Mind trying? > :-) I don't really have a list handy, but I definitely can (and in fact planned to) try to create such a list (part of that will involve tracking down the SELinux -> Jupyter madness, which will most likely result in a SR). However, just eliminating these recommends unconditionally won't work, see below why. I will answer your other two points in the opposite order that you have mentioned them, since I think this is more logical. > I'd prefer to get rid of recommends. As OS vendor we > have to decide whether a package is needed or not. A stricter definition of > what is a mandatory part of the OS really helps in other areas too (eg > transactional-update status). That decision was already made, and such a definition already exists: it's called Requires. We already have that situation in today's MicroOS. Recommends are, in my book, supposed to be things which are in fact *not* strictly mandatory, but generally useful to have. Some concrete examples TW/MicroOS experience: * enhanced_base -> plymouth: This is a Recommends, so it's not installed on MicroOS today. The system works without a boot splash, but it looks nicer with one. (Same with the language magic this issue is about, but I don't understand how it works exactly. Emoji fonts and color management are also in this category.) * microos_desktop_common -> hplip-hpijs, OpenPrintingPPDs: This is in fact a Requires today. A desktop system can work without printing if so desired, but a significant part of the userbase appreciates their printer working. With Recommends, everyone can have a good experience, while users can choose to slim their systems down further. In a world without Recommends, this option doesn't exist any more: in order not to bloat everyone's system, many "nice to have" things have to be left out, leading to degraded experience after installation (of course you can install these things after the fact, but that's not user-friendly at all). > Yes that is likely possible via boolean dependencies. I wonder whether it's > really needed though. As a concrete example again, the x11 -> x11_enhanced -> web_browser Recommends chain does make sense on traditional systems. On MicroOS not so much, since you just install the browser using Flatpak. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c11 --- Comment #11 from Ludwig Nussel <lnussel(a)suse.com> --- (In reply to Alois Wohlschlager from comment #7) > What about enabling recommends, but shipping targeted locks to prevent > installation of the worst offenders by default? That's what I currently do > on my MicroOS system, since no-recommends is too barebones, and with my > approach I get the bloat down quite a bit If you have such a list already, a first approach could also be to try to simply file sr's to eliminate those recommends. That's what I did in the past with some packages and generally didn't get much pushback. Mind trying? :-) (In reply to Alois Wohlschlager from comment #10) > (In reply to Richard Brown from comment #8) > > > > Locks are a terrible cludge that just result in broken systems > > Ok, understood that this is not a generally applicable solution. > > > I'm all for installing all language patterns all the time, I'm not for > > installing GB and GB of random junk alongside them > > Well, but recommends are not supposed to be "random junk" anyway, but rather > "generally useful, but not strictly required". Where they do pull in random > junk, I see basically three categories: > 1a. Things that are generally useful on traditional systems, but not on > MicroOS (e.g. pulling in YaST or Firefox from various desktop patterns). > Does zypp have a way to express something like "Recommends: (MicroOS or > yast2)"? If so, these could be used for a fix. Yes that is likely possible via boolean dependencies. I wonder whether it's really needed though. I'd prefer to get rid of recommends. As OS vendor we have to decide whether a package is needed or not. A stricter definition of what is a mandatory part of the OS really helps in other areas too (eg transactional-update status). > 1b. Compatibility-related, but rarely useful things, I mainly think of the > kernel's "Recommends: kernel-firmware" here. This could be fixed the same > way as 1a. > 2. Things which are arguably plain bugs, such as pulling in Jupyter from > some SELinux-related packages. These should be fixed anyway. +1 -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188939] SELinux prevents podman from being run as a systemd service and from being updated
by bugzilla_noreply＠suse.com 11 Jul '22

11 Jul '22

https://bugzilla.suse.com/show_bug.cgi?id=1188939 https://bugzilla.suse.com/show_bug.cgi?id=1188939#c2 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NORESPONSE --- Comment #2 from Johannes Segitz <jsegitz(a)suse.com> --- Please reopen if you can still reproduce this -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 09 Jul '22

09 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c10 --- Comment #10 from Alois Wohlschlager <alois1(a)gmx-topmail.de> --- (In reply to Richard Brown from comment #8) > > Locks are a terrible cludge that just result in broken systems Ok, understood that this is not a generally applicable solution. > I'm all for installing all language patterns all the time, I'm not for > installing GB and GB of random junk alongside them Well, but recommends are not supposed to be "random junk" anyway, but rather "generally useful, but not strictly required". Where they do pull in random junk, I see basically three categories: 1a. Things that are generally useful on traditional systems, but not on MicroOS (e.g. pulling in YaST or Firefox from various desktop patterns). Does zypp have a way to express something like "Recommends: (MicroOS or yast2)"? If so, these could be used for a fix. 1b. Compatibility-related, but rarely useful things, I mainly think of the kernel's "Recommends: kernel-firmware" here. This could be fixed the same way as 1a. 2. Things which are arguably plain bugs, such as pulling in Jupyter from some SELinux-related packages. These should be fixed anyway. > We should have this fixed in the install media somewhen soon..then we just > need to find a solution for pre-built images also I see two problems with this approach: * It's not just about language packs, some other things like boot splash, emoji fonts, color management, and hardware support are also at least nice to have, but currently not installed on MicroOS. Duplicating the work already done is brittle, and probably more work than fixing the few suboptimal recommends. * If some user, for some reason, wants a special-purpose, ultra-minimal system without language packs or the like, they cannot just uninstall the recommended package any more, because it's now required from somewhere. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 08 Jul '22

08 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c9 --- Comment #9 from Peter Maris <petermaris(a)al-bayyina.de> --- Flathub packages also contain all languages by default. So pre-installing all languages would be in line with Flatpak's philosophy. Software is more successful when it is more inclusive for everyone in the world. The easiest thing would be to enable recommended packages. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 08 Jul '22

08 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c8 --- Comment #8 from Richard Brown <rbrown(a)suse.com> --- (In reply to Alois Wohlschlager from comment #7) > What about enabling recommends, but shipping targeted locks to prevent > installation of the worst offenders by default? That's what I currently do > on my MicroOS system, since no-recommends is too barebones, and with my > approach I get the bloat down quite a bit (actually the current root > snapshot for some reason uses *less* disk space than the one of a completely > vanilla reference installation in a VM). Locks are a terrible cludge that just result in broken systems I'm all for installing all language patterns all the time, I'm not for installing GB and GB of random junk alongside them We should have this fixed in the install media somewhen soon..then we just need to find a solution for pre-built images also -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1196547] MicroOS Desktop GNOME system role doesn't preinstall language subpackages
by bugzilla_noreply＠suse.com 08 Jul '22

08 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1196547 http://bugzilla.opensuse.org/show_bug.cgi?id=1196547#c7 Alois Wohlschlager <alois1(a)gmx-topmail.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |alois1(a)gmx-topmail.de --- Comment #7 from Alois Wohlschlager <alois1(a)gmx-topmail.de> --- What about enabling recommends, but shipping targeted locks to prevent installation of the worst offenders by default? That's what I currently do on my MicroOS system, since no-recommends is too barebones, and with my approach I get the bloat down quite a bit (actually the current root snapshot for some reason uses *less* disk space than the one of a completely vanilla reference installation in a VM). -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1200182] New: systemd-resolved cannot bind port 53
by bugzilla_noreply＠suse.com 04 Jul '22

04 Jul '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1200182 Bug ID: 1200182 Summary: systemd-resolved cannot bind port 53 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: paul(a)pbarker.dev QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- On a fresh installation of OpenSUSE MicroOS, I have attempted to switch to systemd-networkd and systemd-resolved to manage my network connections following the instructions in https://en.opensuse.org/Network_Management_With_Systemd. However, when trying to enable systemd-resolved I hit an error: alpha:~ # systemctl enable --now systemd-resolved Created symlink /etc/systemd/system/dbus-org.freedesktop.resolve1.service �� /usr/lib/systemd/system/systemd-resolved.service. Created symlink /etc/systemd/system/multi-user.target.wants/systemd-resolved.service �� /usr/lib/systemd/system/systemd-resolved.service. Job for systemd-resolved.service failed because the control process exited with error code. See "systemctl status systemd-resolved.service" and "journalctl -xeu systemd-resolved.service" for details. alpha:~ # journalctl -xeu systemd-resolved.service �� Subject: Automatic restarting of a unit has been scheduled �� Defined-By: systemd �� Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel �� Automatic restarting of the unit systemd-resolved.service has been scheduled, as the result for �� the configured Restart= setting for the unit. Jun 02 21:51:19 alpha.cephei.uk systemd[1]: Stopped Network Name Resolution. �� Subject: A stop job for unit systemd-resolved.service has finished �� Defined-By: systemd �� Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel �� A stop job for unit systemd-resolved.service has finished. �� The job identifier is 1376 and the job result is done. Jun 02 21:51:19 alpha.cephei.uk systemd[1]: Starting Network Name Resolution... �� Subject: A start job for unit systemd-resolved.service has begun execution �� Defined-By: systemd �� Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel �� A start job for unit systemd-resolved.service has begun execution. �� The job identifier is 1376. Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Positive Trust Anchors: Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.> Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Using system hostname 'alpha.cephei.uk'. Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed to bind socket: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to process RTNL link message: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed to bind socket: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to process RTNL link message: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed to bind socket: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to process RTNL link message: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv6(UDP): Failed to bind socket: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed to bind socket: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to listen on UDP socket 127.0.0.53:53: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: Failed to start manager: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv4(UDP): Failed to bind socket: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd-resolved[1643]: LLMNR-IPv6(UDP): Failed to bind socket: Permission denied Jun 02 21:51:19 alpha.cephei.uk systemd[1]: systemd-resolved.service: Main process exited, code=exited, status=1/FAILURE �� Subject: Unit process exited �� Defined-By: systemd �� Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel �� An ExecStart= process belonging to unit systemd-resolved.service has exited. �� The process' exit code is 'exited' and its exit status is 1. Jun 02 21:51:19 alpha.cephei.uk systemd[1]: systemd-resolved.service: Failed with result 'exit-code'. �� Subject: Unit failed �� Defined-By: systemd �� Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel �� The unit systemd-resolved.service has entered the 'failed' state with result 'exit-code'. Jun 02 21:51:19 alpha.cephei.uk systemd[1]: Failed to start Network Name Resolution. It appears that the permission denied errors when systemd-resolved tried to bind port 53 are caused by SELinux. I confirmed that this is the case by disabling SELinux and retrying the command - this resulted in systemd-resolved successfully starting. Therefore I think there is an error in the SELinux policy here - systemd-resolved should be able to bind port 53 on localhost to offer DNS resolution services. -- You are receiving this mail because: You are the assignee for the bug.

1 1