November 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1204929] dracut-pre-udev complains about missing group rpc:rpc
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204929 https://bugzilla.suse.com/show_bug.cgi?id=1204929#c12 Antonio Feijoo <antonio.feijoo(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #12 from Antonio Feijoo <antonio.feijoo(a)suse.com> --- (In reply to Thomas Blume from comment #11) > So, most probably the chown shouldn't be necessary. > > I case of: > > https://bugzilla.suse.com/show_bug.cgi?id=1177461#c39 > > it seems that /run/rpcbind was already present with wrong permissions. > So, I guess an "rm -rf /run/rpcbind" instead of a chown in the initrd would > do. Thanks Thomas. The /run/rpcbind directory is created by root in the initrd (see comment #6 - https://github.com/dracutdevs/dracut/blob/master/modules.d/95nfs/nfs-start-…), that's why the chown is done after. Then, IIUC we can avoid the mkdir and the chown, because rpcbind will create /run/rpcbind if it does not exist, right? And, does the same apply to the /var/lib/rpcbind directory (see https://github.com/dracutdevs/dracut/blob/master/modules.d/95nfs/parse-nfsr…), could we skip that mkdir & chown? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204929] dracut-pre-udev complains about missing group rpc:rpc
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204929 https://bugzilla.suse.com/show_bug.cgi?id=1204929#c11 Thomas Blume <thomas.blume(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(thomas.blume@suse | |.com) | --- Comment #11 from Thomas Blume <thomas.blume(a)suse.com> --- (In reply to Antonio Feijoo from comment #9) > (In reply to Stefan Hundhammer from comment #7) > > Please notice that the check condition is if the "rpcbind" command is > > available, not if the "rpc" user group exists. > > Thomas, I see you maintain rpcbind. Do you know if the rpcbind command > always requires the rpc user and group to own /run/rpcbind? This solved > https://bugzilla.suse.com/show_bug.cgi?id=1177461#c39 Hi Antonio, /run/rpcbind is actually RPCBIND_STATEDIR where it writes its state files in case of a warmstart (this is configured in rpcbind.service via the -w parameter). It would create the directory itself on startup: --> mkdir_warmstart(int uid) { /* Already exists? */ if (access(RPCBIND_STATEDIR, X_OK) == 0) return; if (mkdir(RPCBIND_STATEDIR, 0770) == 0) { int fd = open(RPCBIND_STATEDIR, O_RDONLY | O_DIRECTORY | O_NOFOLLOW); if (fd >= 0) { if (fchown(fd, uid, -1) < 0) { syslog(LOG_ERR, "mkdir_warmstart: open failed '%s', errno %d (%s)", ..< I guess in that case it will have the UID and GID of the rpcbind binary. When I create /run/rpcbind with a different uid before the rpcbind startup, I get an error: --> Nov 07 10:25:28 localhost systemd[1]: Starting RPC Bind... Nov 07 10:25:28 localhost rpcbind[13885]: mkdir_warmstart: mkdir failed '/run/rpcbind', errno 17 (File exists) --< The same is true when I remove the rpc user: --> Nov 07 10:21:45 localhost rpcbind[13614]: cannot get uid of 'rpc': Success Nov 07 10:21:45 localhost systemd[1]: rpcbind.service: Main process exited, code=exited, status=1/FAILURE --< So, most probably the chown shouldn't be necessary. I case of: https://bugzilla.suse.com/show_bug.cgi?id=1177461#c39 it seems that /run/rpcbind was already present with wrong permissions. So, I guess an "rm -rf /run/rpcbind" instead of a chown in the initrd would do. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204001] New: qemu-linux-user 7.1 regression with glibc 2.36
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204001 Bug ID: 1204001 Summary: qemu-linux-user 7.1 regression with glibc 2.36 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Virtualization:Other Assignee: virt-bugs(a)suse.de Reporter: dmueller(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Qemu 7.1 dropped the linux/fs.h includes which broke a lot of essential ioctl emulations in qemu-linux-user, as they were ifdef'ed but the condition it is testing against is no longer defined. this was reported by Andreas upstream here: https://lists.nongnu.org/archive/html/qemu-devel/2022-10/msg00091.html and let to this patch series which fixes it up: https://lists.gnu.org/archive/html/qemu-devel/2022-10/msg00351.html would be nice to include that in tumbleweed asap as the 7.1.0 update is now no longer able to build any package on emulated architectures as the post-build step is leveraging FIGETBSZ which leads to errors like: [ 786s] ... saving built packages [ 787s] RPMS/riscv64/apache2-debuginfo-2.4.54-7.1.riscv64.rpm [ 787s] RPMS/riscv64/apache2-debuginfo-2.4.54-7.1.riscv64.rpm: FIGETBSZ failed: Function not implemented -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 1205009] Preserving priorities of existing package repositories during software upgrade in a Live system
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205009 Stefan Hundhammer <shundhammer(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED URL| |https://trello.com/c/2FLHtt | |1a Assignee|yast2-maintainers(a)suse.de |yast-internal(a)suse.de -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205009] Preserving priorities of existing package repositories during software upgrade in a Live system
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205009 https://bugzilla.suse.com/show_bug.cgi?id=1205009#c8 --- Comment #8 from Stefan Hundhammer <shundhammer(a)suse.com> --- Moving to our Trello task queue for further discussion and a decision. Notice that this is not a promise that we will actually implement this. ;-) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205009] Preserving priorities of existing package repositories during software upgrade in a Live system
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205009 https://bugzilla.suse.com/show_bug.cgi?id=1205009#c7 --- Comment #7 from Stefan Hundhammer <shundhammer(a)suse.com> --- So, if we choose to offer such a feature, we need to harden it against casual misuse. One possibility might be to put that whole thing into a small sub-workflow: Offer to "keep the old repos with their old priority and change the URLs to point to the new release", then do that URL-change in a semi-automatic way (search and replace the old release, say, "15.4", with the new one, say, "15.5"), and offer each one for manual editing. Possibly we should also try to access those URLs to check that the target actually exists. Just offering a very simplistic "keep the old repos and let me handle it manually" would be leaving too many users out in the rain IMHO. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205009] Preserving priorities of existing package repositories during software upgrade in a Live system
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205009 https://bugzilla.suse.com/show_bug.cgi?id=1205009#c6 --- Comment #6 from Stefan Hundhammer <shundhammer(a)suse.com> --- When you use that list of old repos for the purpose of editing the URLs to point to the newer release, then I do see a valid use case for this. But in the more general case, this might result in an accident waiting to happen: When we offer to keep the old repos, and they also keep their priority (probably by default), not-so-advanced users may be tempted to just keep them and then NOT change the URLs to point to the newer release (because they don't know that that's what they should do). And then they will end up with a bunch of repos with higher priority (because by default we add the new repos with a very low priority, so any other priority will always be higher), so they'll get packages from those old repos pointing to the old release, and weird things will start to happen. A few very advanced users will know how to make good use of such a feature: Just keep their old repos, keep their priorities, and edit each of those URLs to point to the new release. For them, that would indeed be a handy shortcut to save some work. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205118] New: Move sudo config files to /usr/etc
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1205118 Bug ID: 1205118 Summary: Move sudo config files to /usr/etc Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: banderson19com(a)san.rr.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Per Bug #1152770, default configuration files provided by packages are supposed to be moved to /usr/etc and only admin managed files are to be placed in /etc. The 'sudo' package still puts its config files in /etc. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1201590] pcscd: incomplete Info.plist from pcsc-ccid package and regression in libusb-1_0-0 v1.0.24 (Can't get config descriptor)
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1201590 https://bugzilla.suse.com/show_bug.cgi?id=1201590#c13 Marcus Meissner <meissner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #13 from Marcus Meissner <meissner(a)suse.com> --- update is still waiting for qa. as this is non VUL bug the work should be done. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1200786] primary and secondary DNS are inverted
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1200786 https://bugzilla.suse.com/show_bug.cgi?id=1200786#c5 Jonathan Kang <songchuan.kang(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jonathan Kang <songchuan.kang(a)suse.com> --- Closing this. I've talked to upstream developers and they said this behaviour change is not intentional. But the new behaviour is the one they prefer now. User configured settings should be prioritized before automatically configured nameservers. -- You are receiving this mail because: You are on the CC list for the bug.

1 0