January 2019 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1120852] New: SSSD may have incorrect service type
by bugzilla_noreply＠novell.com 06 Jan '19

06 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1120852 Bug ID: 1120852 Summary: SSSD may have incorrect service type Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: william(a)blackhats.net.au QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi, I recently have been testing samba 4.9.x from network:samba:STABLE on a leap 15.0 transactional server. I noticed that when I installed this, it updates ldb/tdb which is used by SSSD. The following error is experienced: (Sun Jan 6 11:22:44 2019) [sssd] [ldb] (0x0010): Failed to unlock db: ../ldb_tdb/ldb_tdb.c:147: Reusing ldb opend by pid 3344 in process 3345 / Protocol error This is referenced by the upstream ticket: https://pagure.io/SSSD/sssd/pull-request/3751 I note in the upstream ticket, that it implies that systemd should be starting sssd with interactive mode which avoids the issue, but cwrap hits this with daemon mode. The systemd unit file for sssd on suse ships with sssd in daemon mode. Should it perhaps be: [Service] EnvironmentFile=-/etc/sysconfig/sssd ExecStart=/usr/sbin/sssd -i -f # These two should be used with traditional UNIX forking daemons # consult systemd.service(5) for more details Type=simple PIDFile=/var/run/sssd.pid To match the "advice" of upstreams implementation? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1120838] Kubic transactional server may not allow external obs repos to be added
by bugzilla_noreply＠novell.com 06 Jan '19

06 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1120838 http://bugzilla.opensuse.org/show_bug.cgi?id=1120838#c3 --- Comment #3 from William Brown <william(a)blackhats.net.au> --- I have performed the following steps: # transactional-update shell # zypper ar obs://network:samba:STABLE network:samba:STABLE Guessed: platform = openSUSE_Leap_$releasever Adding repository 'network:samba:STABLE' .................................................................................................................................................................[done] Repository 'network:samba:STABLE' successfully added URI : https://download.opensuse.org/repositories/network:/samba:/STABLE/openSUSE_… Enabled : Yes GPG Check : Yes Autorefresh : No Priority : 99 (default priority) Repository priorities are without effect. All enabled repositories share the same priority. # zypper ref Retrieving repository 'network:samba:STABLE' metadata -------------------------------------------------------------------------------------------------------------------------------------------------------[\] Download (curl) error for 'https://download.opensuse.org/repositories/network:/samba:/STABLE/openSUSE_…': Error code: Curl error 60 Error message: SSL certificate problem: unable to get local issuer certificate Abort, retry, ignore? [a/r/i/...? shows all options] (a): ? a - Skip retrieval of the file and abort current operation. r - Try to retrieve the file again. i - Skip retrieval of the file and try to continue with the operation without the file. u - Change current base URI and try retrieving the file again. s - Disable SSL certificate authority check and continue. [a/r/i/...? shows all options] (a): s SSL certificate authority check disabled. Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving repository 'network:samba:STABLE' metadata -------------------------------------------------------------------------------------------------------------------------------------------------------[/] Download (curl) error for 'https://download.opensuse.org/repositories/network:/samba:/STABLE/openSUSE_…': Error code: Curl error 60 Error message: SSL certificate problem: unable to get local issuer certificate Abort, retry, ignore? [a/r/i/...? shows all options] (a): s SSL certificate authority check disabled. Abort, retry, ignore? [a/r/i/...? shows all options] (a): r Retrieving repository 'network:samba:STABLE' metadata -------------------------------------------------------------------------------------------------------------------------------------------------------[-] Warning: File 'repomd.xml' from repository 'network:samba:STABLE' is unsigned. Note: Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise. Note: File 'repomd.xml' is the repositories master index file. It ensures the integrity of the whole repo. Warning: We can't verify that no one meddled with this file, so it might not be trustworthy anymore! You should not continue unless you know it's safe. File 'repomd.xml' from repository 'network:samba:STABLE' is unsigned, continue? [yes/no] (no): yes Retrieving repository 'network:samba:STABLE' metadata ....................................................................................................................................................[done] Building repository 'network:samba:STABLE' cache .........................................................................................................................................................[done] Repository 'openSUSE-Leap-15.0-Non-Oss' is up to date. Repository 'openSUSE-Leap-15.0-Oss' is up to date. Repository 'openSUSE-Leap-15.0-Update' is up to date. Repository 'openSUSE-Leap-15.0-Update-Non-Oss' is up to date. All repositories have been refreshed. I then rebooted, and ran transactional-update, and no updates were proposed. I realised that this is due to the vendor change being required, so I did a shell + zypper update allow-vendor-change, which has installed the packages. I'd like to note that even still, all packages failed to verify with GPG regardless of the enabled repo above: Retrieving package samba-4.9.3+git.121.c328d5e9101-lp150.1.1.x86_64 (34/39), 724.5 KiB ( 1.6 MiB unpacked) Retrieving: samba-4.9.3+git.121.c328d5e9101-lp150.1.1.x86_64.rpm ...........................................................................................................................[done (259.4 KiB/s)] samba-4.9.3+git.121.c328d5e9101-lp150.1.1.x86_64.rpm: Header V3 DSA/SHA1 Signature, key ID 27daa6b9: NOKEY V3 DSA/SHA1 Signature, key ID 27daa6b9: NOKEY Looking for gpg key ID 27DAA6B9 in cache /var/cache/zypp/pubkeys. Repository network:samba:STABLE does not define additional 'gpgkey=' URLs. samba-4.9.3+git.121.c328d5e9101-lp150.1.1.x86_64 (network:samba:STABLE): Signature verification failed [4-Signatures public key is not available] Abort, retry, ignore? [a/r/i] (a): i I really appreciate your time with this issue. Perhaps transactional-update needs to inherit some of the addrepo and other repo commands similar to how it does pkg install? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1120851] New: Kernel 4.19 did not boot and gives a black screen
by bugzilla_noreply＠novell.com 05 Jan '19

05 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1120851 Bug ID: 1120851 Summary: Kernel 4.19 did not boot and gives a black screen Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: 32bit OS: SUSE Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: seppe.hoogzaad(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 793716 --> http://bugzilla.opensuse.org/attachment.cgi?id=793716&action=edit the .config used to compile the 4.20 kernel for the Dell D420 The kernel 4.19 did not boot, giving a black screen after a distribution update. I used the old 4.18 kernel to boot. This worked. I compiled the new 4.20 kernel myself. This worked. Since the kernels 4.18 and 4.20 both worked, i suspect that something in the .config of the 4.19 kernel is wrong. I can not boot the 4.19 kernel, so reading the /proc/config.gz is not possible for me. I therefore find it difficult to check this myself. I have included the .config i used to compile my working 4.20 kernel. This is a striped version of the .config of the 4.18 kernel. I have a Dell D420 with a Intel Mobile 945GM graphics controller, driven by the i915 kernel module. I use the X window, in case this might be relevant. Possible Duplicates: 1119621 I just bought a Dell Chromebook witch had a similar problem and might be a duplicate. The chromebook is a 64 bit machine, so this will get a separate bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1120186] New: HP Compaq nx8220 does not boot anymore (black screen only) starting with Linux kernel 4.19-1-pae (32bit)
by bugzilla_noreply＠novell.com 05 Jan '19

05 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1120186 Bug ID: 1120186 Summary: HP Compaq nx8220 does not boot anymore (black screen only) starting with Linux kernel 4.19-1-pae (32bit) Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: okurz(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 793239 --> http://bugzilla.opensuse.org/attachment.cgi?id=793239&action=edit "dmesg" and "hwinfo" output ## Observation On an installation of openSUSE Tumbleweed (32bit), a rather old HP Compaq nx8220, 4.18.12-1-pae boots successfully, all later versions, e.g. 4.19.1-1-pae do not work, only a black screen shows up after selecting the kernel entry from grub2, also when booting without any kernel command line parameters, the "recovery" entry. ## Problem Is this related to https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-FBDEV-Defer-… ? Trying with "nomodeset" kernel parameter ends with lightdm segfaulting in libc-2.27.so but I can reproduce the same on 4.18 when adding "nomodeset" so I assume that lightdm does not work with "nomodeset". ## Further details "dmesg" and "hwinfo" output attached. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1120838] Kubic transactional server may not allow external obs repos to be added
by bugzilla_noreply＠novell.com 05 Jan '19

05 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1120838 Ignaz Forster <iforster(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |WONTFIX -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1120838] Kubic transactional server may not allow external obs repos to be added
by bugzilla_noreply＠novell.com 05 Jan '19

05 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1120838 http://bugzilla.opensuse.org/show_bug.cgi?id=1120838#c2 Ignaz Forster <iforster(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |iforster(a)suse.com Resolution|WORKSFORME |FIXED --- Comment #2 from Ignaz Forster <iforster(a)suse.com> --- The problem is that the repository keys are stored in the RPM database - which is located on the read-only root file system. For the time being I'd recommend to select "trust temporarily" instead of "trust always" - this will avoid the error message (though the repository data will be refreshed in any case as you also noted). The repository key can be added permanently by: * Installing a package in interactive mode (only works if autorefresh is enabled for this repository AND transactional-update is the first command to refresh the repository, i.e. don't call `zypper ref` manually) * Setting ZYPPER_AUTO_IMPORT_KEYS to '1' in /etc/transactional-update.conf (not generally recommended for security reasons) * Calling `transactional-update shell` and adding the repository in there (requires a reboot) I'm sorry for this limitation: the repository handling is the last major nuisance in my eyes, but unfortunately I wasn't able to find a good solution for this yet. In practice I tend to just add the repository and call an interactive transactional-update command immediately afterwards (the first option of the list). -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1108511] 25 second delay logging into machine with ssh with dbus and pam_systemd errors in logs
by bugzilla_noreply＠novell.com 05 Jan '19

05 Jan '19

http://bugzilla.novell.com/show_bug.cgi?id=1108511 http://bugzilla.novell.com/show_bug.cgi?id=1108511#c4 --- Comment #4 from rens groenewegen <rens.groenewegen(a)xs4all.nl> --- apparently, this is related to the info here: https://www.freedesktop.org/wiki/Software/systemd/multiseat/ new feature of systemd ( yes, systemd is now becoming beyond version usable, the bells and whistles will make it collapse, or the proverbial wheel coming off of the car. ) and we go for a brand new invention of the wheel. round this time, hopefully -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1108511] 25 second delay logging into machine with ssh with dbus and pam_systemd errors in logs
by bugzilla_noreply＠novell.com 05 Jan '19

05 Jan '19

http://bugzilla.novell.com/show_bug.cgi?id=1108511 http://bugzilla.novell.com/show_bug.cgi?id=1108511#c3 rens groenewegen <rens.groenewegen(a)xs4all.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bnc-team-screening(a)forge.pr | |ovo.novell.com, | |rens.groenewegen(a)xs4all.nl Flags| |needinfo?(bnc-team-screenin | |g(a)forge.provo.novell.com) --- Comment #3 from rens groenewegen <rens.groenewegen(a)xs4all.nl> --- got this problem too. /var/log/messages : 2019-01-05T20:00:01.315397+01:00 vmhost1 cron[19578]: pam_unix(crond:session): session opened for user root by (uid=0) 2019-01-05T20:00:01.316446+01:00 vmhost1 systemd[1]: Started Login Service. 2019-01-05T20:00:02.135889+01:00 vmhost1 nmbd[2347]: [2019/01/05 20:00:02.135658, 0] ../source3/nmbd/nmbd_namequery.c:109(query_name_response) 2019-01-05T20:00:02.135930+01:00 vmhost1 nmbd[2347]: query_name_response: Multiple (2) responses received for a query on subnet 192.168.1.21 for name RGB<1d>. 2019-01-05T20:00:02.135949+01:00 vmhost1 nmbd[2347]: This response was from IP 192.168.1.20, reporting an IP address of 192.168.1.20. 2019-01-05T20:00:26.316928+01:00 vmhost1 dbus[1315]: [system] Failed to activate service 'org.freedesktop.login1': timed out ===> so, it is 24 seconds waiting for the freedesktop.login1 to time out apparently, systemd starts a desktop ( GUI) login, which of course will not work on ssh. my system runs no desktop ( runlevel 3 in old speak ) indeed, after restart of systemd-logind the 25 second delay goes away. does this help ? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1113300] blueman requires root authetication on bootup
by bugzilla_noreply＠novell.com 05 Jan '19

05 Jan '19

http://bugzilla.novell.com/show_bug.cgi?id=1113300 http://bugzilla.novell.com/show_bug.cgi?id=1113300#c5 --- Comment #5 from Maik Wagner <mail(a)maikwagner.de> --- (In reply to Maurizio Galli from comment #4) > The bug should be resolved Yes it is. The Authentication doesn't appear anymore on Startup. Blueman still complains that "Host is down" when connecting to my Bluetooth speakers though. Closing this bug is fine with me. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1120850] New: Virtualization:containers/minikube: Bug - possible packaging changes
by bugzilla_noreply＠novell.com 05 Jan '19

05 Jan '19

http://bugzilla.opensuse.org/show_bug.cgi?id=1120850 Bug ID: 1120850 Summary: Virtualization:containers/minikube: Bug - possible packaging changes Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: 3rd party software Assignee: containers-bugowner(a)suse.de Reporter: bryan.gartner(a)suse.com QA Contact: bnc-team-screening(a)forge.provo.novell.com CC: fcastelli(a)suse.com Found By: --- Blocker: --- Some possible/suggested packaging changes for minikube ... (currently using Leap 15 x86_64 as the base OS) General: - runtime requires kubectl (which is now a standalone package outside of non-visible kubernetes-client package) kubectl could not be found on your path. kubectl is a requirement for using minikube Somewhat unique (tied to trying to use minikube via -vm-driver=none for a local, non-VM install use case - NOTE: this is currently a very lightly documented use case upstream, so trial-and-error is still typical and WIP) - seems btrfs is not a supported fs (in this local mode), so had to re-install system with ext4 (probably an upstream fix required) - each version of minikube seems to have somewhat specific docker version requirements. [preflight] Some fatal errors occurred: [ERROR SystemVerification]: unsupported docker version: 18.09.0 For instance, the current package, 0.32.0-lp150.19.1 (in this non-VM use case) requires docker 18.06.1_ce. Of course this is available on OBS but requires the manual step to override an install of the latest docker - for this use case, it is suggested to also install socat [WARNING FileExisting-socat]: socat not found in system path With above workarounds, this is running now (both accessible via CLI and K8s dashboard): kubectl get nodes NAME STATUS ROLES AGE VERSION minikube Ready master 2h v1.12.4 kubectl get pods NAME READY STATUS RESTARTS AGE hello-node-6f6cbc4649-qg6nj 1/1 Running 0 2h Let me know if you'd like me to direct some of these issues upstream -- You are receiving this mail because: You are on the CC list for the bug.

1 0