March 2023 - openSUSE Kubic Bugs - openSUSE Mailing Lists

[Bug 1203393] New: microOS cloud-init (OpenStack variant) fails due to attempting systemd-network over NetworkManager
by bugzilla_noreply＠suse.com 21 Apr '23

21 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1203393 Bug ID: 1203393 Summary: microOS cloud-init (OpenStack variant) fails due to attempting systemd-network over NetworkManager Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: matt(a)traverse.com.au QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0 Build Identifier: When using an OpenStack-ContainerHost [aarch64] microOS Tumbleweed build (from https://en.opensuse.org/Portal:MicroOS) cloud-init will fail as it tries to create a file with a systemd-network UID. Despite NetworkManager being the microOS 'default', and systemd-network not being installed, cloud-init decides to create for systemd-networkd You do not even need to have a valid cloud-init source for this, the issue will occur on a 'fresh' system, verified by examining the log files after first boot ---------------------------------------------- 2022-09-14 06:54:40,414 - util.py[DEBUG]: Writing to /etc/systemd/network/10-cloud-init-eth0.network - wb: [644] 69 bytes 2022-09-14 06:54:40,416 - util.py[WARNING]: failed stage init-local 2022-09-14 06:54:40,417 - util.py[DEBUG]: failed stage init-local Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/cloudinit/util.py", line 1430, in chownbyname uid = pwd.getpwnam(user).pw_uid KeyError: "getpwnam(): name not found: 'systemd-network'" The above exception was the direct cause of the following exception: Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/cloudinit/cmd/main.py", line 689, in status_wrapper ret = functor(name, args) File "/usr/lib/python3.10/site-packages/cloudinit/cmd/main.py", line 398, in main_init init.apply_network_config(bring_up=bring_up_interfaces) [edited for brevity, I will attach the full log separately] OSError: Unknown user or group: "getpwnam(): name not found: 'systemd-network'" ---------------------------------------------- I built a custom microOS image (see https://build.opensuse.org/package/revisions/home:mcbridematt:branches:deve… ) with systemd-network installed and verified this "resolves" the issue. However, I haven't tried to diagnose why cloud-init wants to use networkd over NetworkManager. Reproducible: Always Steps to Reproduce: 1. Boot a microOS Tumbleweed VM with a cloud-init file (e.g cidata image) 2. Attempt to use system once it reaches the login prompt (for example, using credentials or SSH keys set in the supplied cloud-config) Actual Results: Login fails because cloud-init did not complete. No mention of the cloud-init failure is provided to the user at the console (except maybe the hostname not being configured by cloud-init) , it can only be discovered by examining the /var partition offline. The specific image I am using is: openSUSE-MicroOS.aarch64-16.0.0-OpenStack-Cloud-Snapshot20220911.qcow2 -- You are receiving this mail because: You are the assignee for the bug.

1 8

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

19 Apr '23

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

1 5

[Bug 1206277] New: Network document scanners do not work out of the box
by bugzilla_noreply＠suse.com 19 Apr '23

19 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1206277 Bug ID: 1206277 Summary: Network document scanners do not work out of the box Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: vortex(a)z-ray.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hello there I found out that network attached document scanners do not work on MicroOS out of the box. For my Canon TR4550 2 in 1 printer I had to add the following packages to make this workload work: - simple-scan (it's not on flathub) - sane-backends Then I configured sane to also use escl for network attached scanners to work by uncommenting the line: #escl in /etc/sane.d/dll.conf After a reboot simpel-scan was able to detect my network printer and successfully scanned the printer test page. I'd like to ask if this can be added to the base MicroOS image? Kind regards, V. -- You are receiving this mail because: You are the assignee for the bug.

1 1

[Bug 1209932] Connection to hotspot does not prompt for login/confirmation
by bugzilla_noreply＠suse.com 31 Mar '23

31 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209932 http://bugzilla.opensuse.org/show_bug.cgi?id=1209932#c2 Bj�rn Lie <bjorn.lie(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|GNOME |MicroOS Assignee|gnome-bugs(a)suse.de |kubic-bugs(a)opensuse.org --- Comment #2 from Bj�rn Lie <bjorn.lie(a)gmail.com> --- Moving to microos component in any case. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1208869] MicroOS - Urdu Lanuage (Pakistan) Keyboard,Formats, Language and Region Support, Arabic Keyboard (Pakistan) layout support
by bugzilla_noreply＠suse.com 31 Mar '23

31 Mar '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1208869 http://bugzilla.opensuse.org/show_bug.cgi?id=1208869#c1 Bj�rn Lie <bjorn.lie(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bjorn.lie(a)gmail.com, | |rbrown(a)suse.com Component|GNOME |MicroOS Assignee|gnome-bugs(a)suse.de |kubic-bugs(a)opensuse.org --- Comment #1 from Bj�rn Lie <bjorn.lie(a)gmail.com> --- Moving to microos - adding rbrown(a)suse.com to cc -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209824] systemctl restart rebootmgr not working
by bugzilla_noreply＠suse.com 28 Mar '23

28 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209824 Thorsten Kukuk <kukuk(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Component|MicroOS |Maintenance Assignee|kubic-bugs(a)opensuse.org |maintenance(a)opensuse.org -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209824] systemctl restart rebootmgr not working
by bugzilla_noreply＠suse.com 28 Mar '23

28 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209824 https://bugzilla.suse.com/show_bug.cgi?id=1209824#c5 --- Comment #5 from Thorsten Kukuk <kukuk(a)suse.com> --- (In reply to Andreas Vetter from comment #3) > (In reply to Thorsten Kukuk from comment #2) > > (In reply to Andreas Vetter from comment #1) > > > Two ways come to my mind to solve this: > > > 1) Set KillMode=control-group for rebootmgr.service > > > > This is the default... > > Aehm, not in this case: > schnuffi:~ # systemctl show rebootmgr.service | grep KillMode > KillMode=none That bug got fixed 2 years ago. You need rebootmgr 1.3 or newer. Looks like Maintenance did not release it for SLES/Leap and I don't know why it was not released via SLE Micro -> Leap Micro for Leap. This is a maintenance problem, nothing I can fix. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209824] systemctl restart rebootmgr not working
by bugzilla_noreply＠suse.com 28 Mar '23

28 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209824 https://bugzilla.suse.com/show_bug.cgi?id=1209824#c4 --- Comment #4 from Andreas Vetter <vetter(a)physik.uni-wuerzburg.de> --- On Leap 15.4 /usr/lib/systemd/system/rebootmgr.service has explicitly KillMode=none -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209824] systemctl restart rebootmgr not working
by bugzilla_noreply＠suse.com 28 Mar '23

28 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209824 https://bugzilla.suse.com/show_bug.cgi?id=1209824#c3 --- Comment #3 from Andreas Vetter <vetter(a)physik.uni-wuerzburg.de> --- (In reply to Thorsten Kukuk from comment #2) > (In reply to Andreas Vetter from comment #1) > > Two ways come to my mind to solve this: > > 1) Set KillMode=control-group for rebootmgr.service > > This is the default... Aehm, not in this case: schnuffi:~ # systemctl show rebootmgr.service | grep KillMode KillMode=none -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 1209824] systemctl restart rebootmgr not working
by bugzilla_noreply＠suse.com 28 Mar '23

28 Mar '23

https://bugzilla.suse.com/show_bug.cgi?id=1209824 https://bugzilla.suse.com/show_bug.cgi?id=1209824#c2 --- Comment #2 from Thorsten Kukuk <kukuk(a)suse.com> --- (In reply to Andreas Vetter from comment #1) > Two ways come to my mind to solve this: > 1) Set KillMode=control-group for rebootmgr.service This is the default... The question is, which of the libraries is doing the fork and why it is blocking the kill signals. Are there any more useful error messages around rebootmgr? I have never seen this on my MicroOS and Tumbleweed machines... -- You are receiving this mail because: You are the assignee for the bug.

1 0