November 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1202059] AUDIT-0: ruby3.1-rubygem-d-installer: review of D-Bus services org.opensuse.DInstaller (and friends)
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1202059 https://bugzilla.suse.com/show_bug.cgi?id=1202059#c19 --- Comment #19 from Matthias Gerstner <matthias.gerstner(a)suse.com> --- I checked the current RPM from YaST:Head:D-Installer/rubygem-d-installer. The points raised in this bug have not yet been addressed, however: - the file /etc/dbus-1/system.d/org.opensuse.DInstaller.conf should be installed in /usr/share/dbus-1/system.d instead. - in this file, access to the D-Bus service should be restricted to root or a dedicated user that is supposed to run the installer. Currently there is still a <policy context="default"> that allows every user to invoke the service. Instead I would expect something like <policy user="root">. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205258] Multi-step transactions for transactional updates
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205258 https://bugzilla.suse.com/show_bug.cgi?id=1205258#c4 --- Comment #4 from Stefan Hundhammer <shundhammer(a)suse.com> --- Ignatz Forster is taking over from here. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205258] Multi-step transactions for transactional updates
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205258 Ignaz Forster <iforster(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |iforster(a)suse.com Component|Installation |MicroOS Assignee|yast2-maintainers(a)suse.de |iforster(a)suse.com QA Contact|jsrain(a)suse.com |qa-bugs(a)suse.de -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205258] Multi-step transactions for transactional updates
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205258 https://bugzilla.suse.com/show_bug.cgi?id=1205258#c3 --- Comment #3 from Stefan Hundhammer <shundhammer(a)suse.com> --- Don't worry about that; you have no way of knowing those details. We'll find somebody to take care of this. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205258] Multi-step transactions for transactional updates
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205258 https://bugzilla.suse.com/show_bug.cgi?id=1205258#c2 --- Comment #2 from Eric Levy <contact(a)ericlevy.name> --- I understand about the category. I am not familiar with the layout of the reporting system. I probably made a few mistakes, and the system may have made some choices automatically. I agree the issue is not related to YaST, and would be happy to see the report processed in the most appropriate way. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205261] dracut/hooks/emergency...ESP's FAT serial number in initrd halts boot in dracut emergency shell after rsync migration to new GPT system disk
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205261 https://bugzilla.suse.com/show_bug.cgi?id=1205261#c6 --- Comment #6 from Antonio Feijoo <antonio.feijoo(a)suse.com> --- (In reply to Felix Miata from comment #4) > (In reply to Felix Miata from comment #3) > > What man page covers usr/lib/dracut/hooks/emergency? > > man /etc/dracut.conf.d/10-persistent_policy.conf is unhelpful. > > Many many hours' work documenting and reporting here, and I just now found > man dracut.cmdline. With rd.hostonly=0 the original initrds are usable. :p Oops, you found it before I wrote it :) So, does this solved your problem? If so, feel free to close this bug. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1203481] AUDIT-1: libcap: consider re-introducing pam_cap for explicit opt-in
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1203481 https://bugzilla.suse.com/show_bug.cgi?id=1203481#c12 Matthias Gerstner <matthias.gerstner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution|--- |WONTFIX --- Comment #12 from Matthias Gerstner <matthias.gerstner(a)suse.com> --- Well it seems there is no easy way to optionally include this module in the mainline, and we don't want to fully include it again for the known reasons. I will close this bug; if you're interested in installing this from an unofficial project on the open build service I can give you more information about this. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205261] dracut/hooks/emergency...ESP's FAT serial number in initrd halts boot in dracut emergency shell after rsync migration to new GPT system disk
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205261 https://bugzilla.suse.com/show_bug.cgi?id=1205261#c5 Antonio Feijoo <antonio.feijoo(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |antonio.feijoo(a)suse.com --- Comment #5 from Antonio Feijoo <antonio.feijoo(a)suse.com> --- (In reply to Felix Miata from comment #3) > (In reply to Antonio Feijoo from comment #2) > > I recommend > > you to create a new conf snippet with a higher number, because this will be > > overwritten after a dracut update. > > I haven't touched it. Wouldn't changing it from "by-uuid" to "by-label" just > change the usr/lib/dracut/hooks/emergency failure from a wrong ID to a wrong > label? Maybe I misunderstood you, so the partitions of your new disk have different labels than the original one. > Is this recommendation just an aside for future use? It was just to test if this would solve your problem, but I'm afraid it won't regarding my previous comment. Anyway, in your case it does not seem to be correct to use by-uuid as disk persistent policy in dracut. > Once a Grub menu selection has been made, there's no need for anything > to read the ESP again before init completes (absent any encrypted > filesystems), is there? I agree, and I think the issue you're experiencing is this: https://github.com/dracutdevs/dracut/issues/2044 You can try the `rd.hostonly=0` cmdline option. > What man page covers usr/lib/dracut/hooks/emergency? I don't understand why this internal hook should be covered. For regular hooks see `man dracut.modules`. > man /etc/dracut.conf.d/10-persistent_policy.conf is unhelpful. `man dracut.conf` covers what the persistent_policy option. Why the distro default is "by-uuid" is explained in the 10-persistent_policy.conf file. But of course it can be overridden depending on the specific use case. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205258] Multi-step transactions for transactional updates
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205258 https://bugzilla.suse.com/show_bug.cgi?id=1205258#c1 --- Comment #1 from Stefan Hundhammer <shundhammer(a)suse.com> --- Eric, thank you for your very elaborate and well though-out idea. This is not really for the YaST installer; I'll check where to forward this to, so it doesn't get lost. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204607] Version 1.9.1-2.1 of irqbalance generates journal error
by bugzilla_noreply＠suse.com 10 Nov '22

10 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204607 https://bugzilla.suse.com/show_bug.cgi?id=1204607#c17 --- Comment #17 from Dirk Mueller <dmueller(a)suse.com> --- the "deactivated successfully" means that the service exited with exit code 0. which means it is no longer coredumping, which was the issue in this bugreport. there are valid reasons where irqbalance thinks it has nothing to do, so the deactivation is not necessarily a problem. if it is new behavior then it is worth a separate bugreport for investigation. -- You are receiving this mail because: You are on the CC list for the bug.

1 0