December 2021 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[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 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 1186158] New: SElinux is blocking socket access for podman
by bugzilla_noreply＠suse.com 04 Apr '22

04 Apr '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1186158 Bug ID: 1186158 Summary: SElinux is blocking socket access for podman Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE MicroOS Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: gm.venekamp(a)quicknet.nl QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- test-vm:~ # head -2 /etc/os-release NAME="openSUSE MicroOS" # VERSION="20210515" When starting a container (as root) like traefik, I get the following error: test-vm:~ # podman run -p 8080:8080 -p 80:80 -v /etc/traefik/traefik.yml:/etc/traefik/traefik.yml -v /var/run/podman/podman.sock:/var/run/docker.sock traefik:v2.0 time="2021-05-18T06:46:37Z" level=info msg="Configuration loaded from file: /etc/traefik/traefik.yml" time="2021-05-18T06:46:38Z" level=error msg="Failed to retrieve information of the docker client and server host: Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.24/version: dial unix /var/run/docker.sock: connect: permission denied" providerName=docker This is what /var/log/audit/audit/log tells me: type=AVC msg=audit(1621319586.484:965): avc: denied { connectto } for pid=1785 comm="traefik" path="/run/podman/podman.sock" scontext=system_u:system_r:container_t:s0:c741,c830 tcontext=system_u:system_r:container_runtime_t:s0 tclass=unix_stream_socket permissive=1 test-vm:~ # ll -Z /var/run/podman/podman.sock srw-rw----. 1 root root system_u:object_r:var_run_t:s0 0 May 18 08:46 /var/run/podman/podman.sock Am I doing anything wrong -- You are receiving this mail because: You are the assignee for the bug.

1 11

[Bug 1188957] New: Micro OS Desktop GNOME: Mesa-dri-nouveau not installed on first boot
by bugzilla_noreply＠suse.com 29 Mar '22

29 Mar '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1188957 Bug ID: 1188957 Summary: Micro OS Desktop GNOME: Mesa-dri-nouveau not installed on first boot 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: richwallwork(a)pm.me QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I've installed MicroOS desktop GNOME and noticed that it was reporting that the built in Intel gfx is the graphics adapter rather than the installed Nvidia card (which works fine on regular Tumbleweed). the Journal suggests that nouveau_dri.so cannot be found in /usr/lib64/dri and it seems the Mesa-dri-nouveau package wasn't installed. I used: sudo tukit --continue execute bash zypper in Mesa-dri-nouveau and after a reboot the system is working fine with nouveau. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1193706] New: pkcon reporting a (spurious?) read-only fs error
by bugzilla_noreply＠suse.com 25 Feb '22

25 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1193706 Bug ID: 1193706 Summary: pkcon reporting a (spurious?) read-only fs error Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: dfaggioli(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hey! So, since some users were complaining about pkcon throwing errors on MicroOS, I decided to try myself (I just installed snapshot 20211211). It is, in fact, the case that the following shows up: dario@localhost:~> pkcon install rclone Fatal error: Failed to create directory "/.snapshots/4/snapshot/etc/dnf/modules.d": 30 - Read-only file system However, if I try again, it seems the package was installed inside of the snapshot: dario@localhost:~> pkcon -v install rclone 22:33:59 PackageKit Verbose debugging enabled (on console 1) 22:34:00 PackageKit role now resolve PackageKit adding state 0x559f4fd43be0 PackageKit notify::connected PackageKit remove state 0x559f4fd43be0 Fatal error: rclone-1.57.0-1.1.x86_64 is already installed And if I reboot, rclone is there: dario@localhost:~> rclone -h Rclone syncs files to and from cloud storage providers as well as mounting them, listing them in lots of different ways. See the home page (https://rclone.org/) for installation, usage, documentation, changelog and configuration walkthroughs. Usage: rclone [flags] rclone [command] ... ... ... So, is that "Fatal error" just some spurious message we should suppress? Or has something really gone bad, despite the package ending up being installed (from what I can tell) correctly? Neal, any idea? -- You are receiving this mail because: You are the assignee for the bug.

1 2

[Bug 1183856] New: fstab gets overriden by transactional-update
by bugzilla_noreply＠suse.com 18 Feb '22

18 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1183856 Bug ID: 1183856 Summary: fstab gets overriden by transactional-update 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: nmoreychaisemartin(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Running transactional-update removes fstab entries that were added post install Steps to reproduce: - Add fstab entry using transactional-update -c shell - Reboot [ fstab is properly updated ] - Run transactional-update pkg in something - cat /var/lib/overlay/<last overlay>/etc/fstab (or reboot and check fstab) fstab entry is now missing -- You are receiving this mail because: You are the assignee for the bug.

1 5

[Bug 1183521] New: [Build 20210312] openQA test fails in transactional_update
by bugzilla_noreply＠suse.com 18 Feb '22

18 Feb '22

https://bugzilla.suse.com/show_bug.cgi?id=1183521 Bug ID: 1183521 Summary: [Build 20210312] openQA test fails in transactional_update Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/1666862/modules/tran sactional_update/steps/81 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: iforster(a)suse.com Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org Found By: openQA Blocker: Yes Two bugs were observed when running the latest transactional-update on an older Tumbleweed snapshot: 1. "transactional-update" fails in zypper, because /var/lib/rpm inside the new root is an absolute symlink pointing to the current /, which is read-only 2. transactional-update 3.20.0 creates snapshots which transactional-update 2.24.1 does not understand due to a different workdir= value in /etc/fstab ## Observation openQA test in scenario microos-Tumbleweed-MicroOS-Image-ContainerHost-x86_64-container-host-old2microosnext@64bit fails in [transactional_update](https://openqa.opensuse.org/tests/1666862/modules/tra… ## Test suite description Boot from existing, static MicroOS ContainerHost image and transactional-update dup to snapshot under test. ## Reproducible Fails since (at least) Build [20210223](https://openqa.opensuse.org/tests/1644898) ## Expected result Last good: [20210222](https://openqa.opensuse.org/tests/1642729) (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 on the CC list for the bug.

1 4

[Bug 1191677] php8-nginx container broken
by bugzilla_noreply＠suse.com 16 Dec '21

16 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1191677 https://bugzilla.suse.com/show_bug.cgi?id=1191677#c6 --- Comment #6 from Noah Kalish <noah(a)spacemule.net> --- I figured it out! Sorry for bugging you about this. The problem is apparmor. I didn't realize it also confined container processes in the same way. The apparmor profile for php-fpm only covers version 5 and 7. I added 8, and it's good to go. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1191677] php8-nginx container broken
by bugzilla_noreply＠suse.com 15 Dec '21

15 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1191677 https://bugzilla.suse.com/show_bug.cgi?id=1191677#c5 --- Comment #5 from Thorsten Kukuk <kukuk(a)suse.com> --- (In reply to Noah Kalish from comment #4) > Interestingly, I built my own image on OBS that uses php-fpm, and it's > giving the same error. I'd appreciate if you could look into this again, as > it's not working on any machine I try it. I cannot reproduce it on any of my Tumbleweed or MicroOS machines: podman run --rm -v /srv/www/htdocs/:/srv/www/htdocs -it opensuse/php8-nginx /docker-entrypoint.d/ is not empty, will attempt to perform configuration Looking for shell scripts in /docker-entrypoint.d/ Launching /docker-entrypoint.d/30-populate-etc.sh Populate /etc/nginx Launching /docker-entrypoint.d/40-populate-htdocs.sh Launching /docker-entrypoint.d/50-set-timezone.sh Launching /docker-entrypoint.d/90-run-php-fpm.sh Starting php-fpm... Configuration complete; ready for start up Starting nginx... It just works. And I have absolute no idea who could block the access to that file. All you could do is to run: podman run --rm -v /home/pod/rainloop/:/srv/www/htdocs -it opensuse/php8-nginx /bin/bash and look at the /etc/php8/fpm/php-fpm.conf file, ownership and permissions (including for all directories in the path). There must be something you do or install on your hosts which blocks the access. It's local only to you. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193706] pkcon reporting a (spurious?) read-only fs error
by bugzilla_noreply＠suse.com 14 Dec '21

14 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1193706 http://bugzilla.opensuse.org/show_bug.cgi?id=1193706#c1 Neal Gompa <ngompa13(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ngompa13(a)gmail.co |needinfo?(iforster(a)suse.com |m) |) --- Comment #1 from Neal Gompa <ngompa13(a)gmail.com> --- I wonder if tukit selectively mounts part of /etc into the snapshot or something like that? If that's the case, we're probably just missing /etc/dnf being set up as a read-write thing in the snapshot. Ignaz, do you have any idea here? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1185461] New: ignition doesn't reset firstboot
by bugzilla_noreply＠suse.com 13 Dec '21

13 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1185461 Bug ID: 1185461 Summary: ignition doesn't reset firstboot 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: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Using openSUSE-MicroOS.x86_64-16.0.0-kvm-and-xen-Snapshot20210427.qcow2 in qemu with an ignition config that touches a file in /etc. Rebooting leads to maintenance mode as ignition started again and exists as the file already exist. So for some reason the no firstboot condition is not detected. /boot/writable/firstboot_happened exist though: Entering emergency mode. Exit the shell to continue. Type "journalctl" to view system logs. You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick or /boot after mounting them and attach it to a bug report. Press Enter for maintenance (or press Control-D to continue): :/root# mount -o subvol=@/boot/writable /dev/vda3 /mnt :/root# ls /mnt/ firstboot_happened :/root# cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-5.11.16-1-default root=UUID=1bd1020f-74e9-4d1f-bb36-859e1f4e86bd rw rd.timeout=60 quiet systemd.show_status=yes console=ttyS0,115200 console=tty0 net.ifnames=0 ignition.firstboot ignition.platform.id=qemu -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1191677] php8-nginx container broken
by bugzilla_noreply＠suse.com 13 Dec '21

13 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1191677 https://bugzilla.suse.com/show_bug.cgi?id=1191677#c4 --- Comment #4 from Noah Kalish <noah(a)spacemule.net> --- I appreciate you looking into this. I found another solution since I couldn't get it working, but now I need it again, and I've found the same issue. I've tried it now on three installs. Two Tumbleweed and one MicroOS. All are up to date and no changes to the default podman configs on one other than adding a registry. Another one has the same registry added and the storage pool moved. The final one is completely vanilla. All three give the same output: ``` podman run --rm -v /home/pod/rainloop/:/srv/www/htdocs -it opensuse/php8-nginx /docker-entrypoint.d/ is not empty, will attempt to perform configuration Looking for shell scripts in /docker-entrypoint.d/ Launching /docker-entrypoint.d/30-populate-etc.sh Populate /etc/nginx Launching /docker-entrypoint.d/40-populate-htdocs.sh Populate /srv/www/htdocs Launching /docker-entrypoint.d/50-set-timezone.sh Launching /docker-entrypoint.d/90-run-php-fpm.sh Starting php-fpm... [13-Dec-2021 18:28:36] ERROR: failed to open configuration file '/etc/php8/fpm/php-fpm.conf': Permission denied (13) [13-Dec-2021 18:28:36] ERROR: failed to load configuration file '/etc/php8/fpm/php-fpm.conf' [13-Dec-2021 18:28:36] ERROR: FPM initialization failed ``` Interestingly, I built my own image on OBS that uses php-fpm, and it's giving the same error. I'd appreciate if you could look into this again, as it's not working on any machine I try it. Thanks! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193642] New: problem with pkcon install-local into /opt
by bugzilla_noreply＠suse.com 12 Dec '21

12 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1193642 Bug ID: 1193642 Summary: problem with pkcon install-local into /opt 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: lubos.kocman(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello I just wanted to install local identity app from government but seems like pkcon install-local failed to populated /opt and /usr/local/etc. The toplevel dirs were simply not created The rpm was converted from deb (published by .gov) into rpm by alien. followed by pkcon install-local && reboot. nstall complained at the very end (single line after message install finished) about failed to create /etc/modules something dir in the snapshot directory as it was read only. lkocman@localhost:~> rpm -q eObcanka eObcanka-3.2.0-2.x86_64 https://www.dropbox.com/s/4wziaff6d02rp5l/eObcanka-3.2.0-2.x86_64.rpm?dl=0 I'm running NAME="openSUSE MicroOS" # VERSION="20211207" # These top level dirs are empty lkocman@localhost:~> rpm -q -V eObcanka | grep missing | wc -l 1263 lkocman@localhost:~> rpm -q -V eObcanka | cut -c -26 | sort | uniq missing /opt/eObcanka missing /opt/eObcanka/ missing /usr/local/etc # empty opt lkocman@localhost:~> ls -laZ /opt total 0 dr-xr-xr-x. 1 root root system_u:object_r:usr_t:s0 0 Dec 9 15:08 . drwxrwxr-x. 1 root root system_u:object_r:root_t:s0 142 Dec 12 10:10 .. # /usr/local/etc is missing completely lkocman@localhost:~> ls -laZ /usr/local/ total 0 drwxr-xr-x. 1 root root system_u:object_r:usr_t:s0 80 Dec 9 15:08 . drwxr-xr-x. 1 root root system_u:object_r:usr_t:s0 124 Dec 12 10:23 .. drwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 0 Dec 9 15:08 bin drwxr-xr-x. 1 root root system_u:object_r:usr_t:s0 0 Dec 9 15:08 include drwxr-xr-x. 1 root root system_u:object_r:lib_t:s0 0 Dec 9 15:08 lib drwxr-xr-x. 1 root root system_u:object_r:lib_t:s0 0 Dec 9 15:08 lib64 drwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 0 Dec 9 15:08 libexec drwxr-xr-x. 1 root root system_u:object_r:man_t:s0 80 Dec 9 15:08 man drwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 0 Dec 9 15:08 sbin drwxr-xr-x. 1 root root system_u:object_r:usr_t:s0 0 Dec 9 15:08 share drwxr-xr-x. 1 root root system_u:object_r:usr_t:s0 0 Dec 9 15:08 src lkocman@localhost:~> -- You are receiving this mail because: You are the assignee for the bug.

1 4

[Bug 1192242] transactional-update 3.6.0 lost changes in /etc (and some selinux issues)
by bugzilla_noreply＠suse.com 10 Dec '21

10 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1192242 https://bugzilla.suse.com/show_bug.cgi?id=1192242#c11 --- Comment #11 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-RU-2021:3989-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1188110,1191945,1192078,1192242,1192302 CVE References: JIRA References: Sources used: SUSE MicroOS 5.1 (src): transactional-update-3.6.2-3.8.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1188110] pkcon system-upgrade leads to unbootable system with kernel upgrade
by bugzilla_noreply＠suse.com 10 Dec '21

10 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1188110 https://bugzilla.suse.com/show_bug.cgi?id=1188110#c18 --- Comment #18 from Swamp Workflow Management <swamp(a)suse.de> --- SUSE-RU-2021:3989-1: An update that has 5 recommended fixes can now be installed. Category: recommended (moderate) Bug References: 1188110,1191945,1192078,1192242,1192302 CVE References: JIRA References: Sources used: SUSE MicroOS 5.1 (src): transactional-update-3.6.2-3.8.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193588] New: MicroOS will not complete boot on Raspberry Pi 3 (and more)
by bugzilla_noreply＠suse.com 09 Dec '21

09 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1193588 Bug ID: 1193588 Summary: MicroOS will not complete boot on Raspberry Pi 3 (and more) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: SUSE Other Status: NEW Severity: Critical Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: corvettecole(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/96.0.4664.45 Safari/537.36 Build Identifier: The latest MicroOS images for the Raspberry Pi (both arm64 and armv7l), containing kernel 5.15 will not complete boot on actual hardware. Initial boot output will disappear about halfway through and the device will never show up on the network (after 15+ minutes of waiting) Reproducible: Always Steps to Reproduce: 1. Pull the latest MicroOS image for the Raspberry Pi, either aarch64 or armv7l 2. Flash on to a microsd card 3. Boot the raspberry pi 3 Actual Results: Boot output disappears and monitor turns off halfway through boot process (after dracut starts doing things) Expected Results: Boot complete successfully (like with kernel 5.14 MicroOS) -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1193572] Can't add any nodes from fresh Installation
by bugzilla_noreply＠suse.com 09 Dec '21

09 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1193572 https://bugzilla.suse.com/show_bug.cgi?id=1193572#c2 Thorsten Kukuk <kukuk(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Thorsten Kukuk <kukuk(a)suse.com> --- That's already fixed in git and the devel project, fix is still somewhere in the stagings waiting for release. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1193572] New: Can't add any nodes from fresh Installation
by bugzilla_noreply＠suse.com 09 Dec '21

09 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1193572 Bug ID: 1193572 Summary: Can't add any nodes from fresh Installation Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Critical Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: mail.petermark(a)web.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Today, I reinstalled kubic with today's ISO snapshot release and tried again to add a node onto the kubic-master, because I had the same issue with an two weeks old snapshot. Reproduce: Install master and client and try to add a worker node. Procedure: Install the node via ISO-Image as an additional worker node. Note: Contrary to the official documentation the salt minion is ready to work, so u have nothing to do on the client-side. Accept salt-keys on master from the worker-node Test the salt-communication with salt "*" test.ping : OK, it's working ... Try to add the worker-node with: kubicctl node add testnode.example.com Generate new token ... Error invoking salt: exit status 1 (miles1.alveare.loc: ERROR executing 'test.ping': Executor '[direct_call]' is not available) Client-Side: �� salt-minion.service - The Salt Minion Loaded: loaded (/usr/lib/systemd/system/salt-minion.service; enabled; vendor preset: disabled) Drop-In: /usr/lib/systemd/system/salt-minion.service.d ��TMPDIR.conf Active: active (running) since Wed 2021-12-08 10:19:48 UTC; 1min 2s ago Main PID: 1776 (salt-minion) Tasks: 6 (limit: 4915) CPU: 2.356s CGroup: /system.slice/salt-minion.service ��1776 /usr/bin/python3 /usr/bin/salt-minion ��1781 /usr/bin/python3 /usr/bin/salt-minion ��1783 /usr/bin/python3 /usr/bin/salt-minion Dec 08 10:19:48 testnode systemd[1]: Starting The Salt Minion... Dec 08 10:19:48 testnode systemd[1]: Started The Salt Minion. Dec 08 10:20:38 testnode salt-minion[1865]: [ERROR ] Problem executing 'test.ping': Executor '[direct_call]' is not available journalctl -xe has no related entries :-( relevant module found: /usr/lib/python3.8/site-packages/salt/executors/direct_call.py python3: 3.8.12 -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 1187313] New: selinux-policy-targeted breaks StandardOutput=tty
by bugzilla_noreply＠suse.com 02 Dec '21

02 Dec '21

https://bugzilla.suse.com/show_bug.cgi?id=1187313 Bug ID: 1187313 Summary: selinux-policy-targeted breaks StandardOutput=tty Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de CC: kubic-bugs(a)opensuse.org Found By: --- Blocker: --- Services with StandardOutput=tty (like MicroOS-Firstboot) fail to start when the targeted policy is enforced: Jun 11 13:57:05 f195.suse.de systemd[1183]: MicroOS-firstboot.service: Failed to set up standard input: Permission denied Jun 11 13:57:05 f195.suse.de kernel: audit: type=1400 audit(1623419825.264:7): avc: denied { watch watch_reads } for pid=1183 comm="(irstboot)" path="/dev/console" dev="devtmpfs" ino=12 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:console_device_t:s0 tclass=chr_file permissive=0 Jun 11 13:57:05 f195.suse.de systemd[1183]: MicroOS-firstboot.service: Failed at step STDIN spawning /usr/libexec/MicroOS-firstboot: Permission denied The Fedora policy allows that for TTYs, so should probably do the same for console_device_t: https://github.com/fedora-selinux/selinux-policy/commit/f4a7e3a562499916c83… -- You are receiving this mail because: You are on the CC list for the bug.

1 13