October 2024 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1227418] New: [Build 20240704] openQA test fails in journal_check
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1227418 Bug ID: 1227418 Summary: [Build 20240704] openQA test fails in journal_check Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://openqa.opensuse.org/tests/4320773/modules/jour nal_check/steps/21 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: forgotten_u0-bnvADNc(a)user.net Reporter: dimstar(a)opensuse.org QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: openQA Blocker: Yes ## Observation Every once in a while, I can see things like this in the journal: Jul 05 04:38:43.198898 localhost.localdomain systemd-coredump[3116]: Resource limits disable core dumping for process 3113 (boot-plugin). Jul 05 04:38:43.199870 localhost.localdomain systemd-coredump[3116]: Process 3113 (boot-plugin) of user 0 terminated abnormally without generating a coredump. I'm fully aware that this bug report is missing all relevant information, but the coredump being limited by resources makes it really hard to extract more info from openQA Hopefully you can find similar crashes in some other systems too openQA test in scenario microos-Tumbleweed-MicroOS-Image-x86_64-microos2microosnext@64bit fails in [journal_check](https://openqa.opensuse.org/tests/4320773/modules/journal_ch… ## Test suite description Boot from the latest published MicroOS image and transactional-update dup to snapshot under test. Make sure to use %BUILD% in the URL and file name to force a redownload for new builds. ## Reproducible Fails since (at least) Build [20240704](https://openqa.opensuse.org/tests/4319742) ## Expected result Last good: [20240703](https://openqa.opensuse.org/tests/4317737) (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 2

[Bug 1212947] Disable fbdev userspace interfaces and programs
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1212947 https://bugzilla.suse.com/show_bug.cgi?id=1212947#c4 --- Comment #4 from Thomas Zimmermann <tzimmermann(a)suse.com> --- Hi (In reply to Michal Suchanek from comment #3) > Note that /dev/fb* supports /sys/class/graphics/fb0/rotate, not aware of > anything like that for DRM. This interface depends on driver support and is not implemented by most drivers. > > That means that switching from FB to DRM interface is a regression for > people using the kernel interface to tell the application how to rotate the > output. > > Because the kernel interface exists many applications do not have > corresponding userspace option at all. The correct interface for console rotation is /sys/class/graphics/fbcon/{rotate,rotate_all}. These files will remain. The implementation is directly in fbcon and does not depend on individual drivers. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1227878] New: econf_readDirs crashes if one of the paths is NULL
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1227878 Bug ID: 1227878 Summary: econf_readDirs crashes if one of the paths is NULL Classification: openSUSE Product: openSUSE Tumbleweed Version: Slowroll Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: schubi(a)suse.com Reporter: sbrabec(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- If util-linux is configured with a plain ./configure, agetty crashes. The reason is simple: If ./configure is called without --with-vendordir=DIR on a system with libeconf, econf_readDirs is called with dist_conf_dir=0x0. And the code does not check for it before calling strdup(). Reading the code, the same is apparently valid for etc_conf_dir. And there are more occurrences of unsanitized strdup() calls on directory names. (gdb) bt #0 __strlen_evex () at ../sysdeps/x86_64/multiarch/strlen-evex-base.S:81 #1 0x00007f06d54aa752 in __GI___strdup (s=s@entry=0x0) at strdup.c:41 #2 0x00007f06d56fa26b in econf_readDirs (comment=0x41260f "#", delim=0x412601 "= \t", config_suffix=0x412605 "defs", config_name=0x412537 "login", etc_conf_dir=0x41260a "/etc", dist_conf_dir=0x0, result=0x41b630 <file>) at ../lib/libeconf.c:510 #3 econf_readDirs (result=result@entry=0x41b630 <file>, dist_conf_dir=dist_conf_dir@entry=0x0, etc_conf_dir=etc_conf_dir@entry=0x41260a "/etc", config_name=config_name@entry=0x412537 "login", config_suffix=config_suffix@entry=0x412605 "defs", delim=delim@entry=0x412601 "= \t", comment=0x41260f "#") at ../lib/libeconf.c:495 #4 0x0000000000409a18 in load_defaults () at lib/logindefs.c:257 #5 0x0000000000409cb5 in getlogindefs_bool (name=name@entry=0x41241a "LOGIN_PLAIN_PROMPT", dflt=dflt@entry=0) at lib/logindefs.c:326 #6 0x0000000000406b11 in main (argc=<optimized out>, argv=<optimized out>) at term-utils/agetty.c:490 (gdb) up #1 0x00007f06d54aa752 in __GI___strdup (s=s@entry=0x0) at strdup.c:41 41 size_t len = strlen (s) + 1; (gdb) up #2 0x00007f06d56fa26b in econf_readDirs (comment=0x41260f "#", delim=0x412601 "= \t", config_suffix=0x412605 "defs", config_name=0x412537 "login", etc_conf_dir=0x41260a "/etc", dist_conf_dir=0x0, result=0x41b630 <file>) at ../lib/libeconf.c:510 510 (*result)->parse_dirs[0] = strdup(dist_conf_dir); (gdb) l 505 return ret; 506 507 (*result)->parse_dirs_count = 2; 508 (*result)->parse_dirs = calloc((*result)->parse_dirs_count+1, sizeof(char *)); 509 (*result)->parse_dirs[(*result)->parse_dirs_count] = NULL; 510 (*result)->parse_dirs[0] = strdup(dist_conf_dir); 511 (*result)->parse_dirs[1] = strdup(etc_conf_dir); 512 513 return readConfigWithCallback(result, 514 config_name, (gdb) p dist_conf_dir $1 = 0x0 -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1231482] [Build 20241008-SELinux] openQA test fails in boot_into_snapshot: root: no shell: Permission denied
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231482 https://bugzilla.suse.com/show_bug.cgi?id=1231482#c12 --- Comment #12 from Fabian Vogt <fvogt(a)suse.com> --- Created attachment 878138 --> https://bugzilla.suse.com/attachment.cgi?id=878138&action=edit YaST installation logs The installation was performed in a separate openQA job, https://openqa.opensuse.org/tests/4547131#dependencies. That contains the YaST logs. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231813] [riscv64][Unmatched][regression] Hard lockup on reboot/poweroff
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231813 https://bugzilla.suse.com/show_bug.cgi?id=1231813#c1 --- Comment #1 from Andreas Schwab <schwab(a)suse.de> --- Worksforme. Do you have any extra hardware installed? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231482] [Build 20241008-SELinux] openQA test fails in boot_into_snapshot: root: no shell: Permission denied
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231482 https://bugzilla.suse.com/show_bug.cgi?id=1231482#c11 --- Comment #11 from Cathy Hu <cathy.hu(a)suse.com> --- > How I see it is that all this should be hidden from any installer. It's a special action needed by the specific solution (SELinux). the problem is that yast creates a snapshot after install and there is no mechanism for me on the selinux packaging side to relabel that. so it has to be done in the place where the snapshot was created unfortunately. > And it's definitely not "An Installer Bug", it might be a feature request though. But a feature request definitely needs a proper description. currently if a user enables selinux and tries to boot into the snapshot that was created by yast and is named "after installation", they will not be able to log in. could you point me to an example how i can describe that as a yast feature request? i have not done that before > Is it really YaST that creates a volume label during firstboot? I find that hard to believe. i think so, but let me know if i am wrong: https://github.com/yast/yast-installation/blob/master/src/lib/installation/… https://github.com/yast/yast-installation/blob/41dfed17b2e467697162d640708c… > There is no useful hint in *any* of the screenshots what is going on there. If there is a firstboot workflow, it's not part of those screenshots. But as it is, it leaves everything to wild guessing. I think you should be able to reproduce it with a tumbleweed image where you select "SELinux"->"enforcing" in yast and then install the system. then boot into the first snapshot named "after installation". thanks a lot people, i will check if i can give you more logs :) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231482] [Build 20241008-SELinux] openQA test fails in boot_into_snapshot: root: no shell: Permission denied
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231482 https://bugzilla.suse.com/show_bug.cgi?id=1231482#c10 --- Comment #10 from Stefan Hundhammer <shundhammer(a)suse.com> --- There are no y2logs at that openQA test case. There is no ISO there, just the .iso.sha256 file (?!?). There is no useful hint in *any* of the screenshots what is going on there. If there is a firstboot workflow, it's not part of those screenshots. But as it is, it leaves everything to wild guessing. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231482] [Build 20241008-SELinux] openQA test fails in boot_into_snapshot: root: no shell: Permission denied
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231482 https://bugzilla.suse.com/show_bug.cgi?id=1231482#c9 --- Comment #9 from Stefan Hundhammer <shundhammer(a)suse.com> --- Is it really YaST that creates a volume label during firstboot? I find that hard to believe. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1044785] openvpn with NetworkManager crashes on renegotiation
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1044785 https://bugzilla.suse.com/show_bug.cgi?id=1044785#c4 --- Comment #4 from Bruce Anderson <banderson19com(a)san.rr.com> --- (In reply to Jonathan Kang from comment #3) > (In reply to Bruce Anderson from comment #2) > > (In reply to Reinhard Max from comment #1) > > > Sounds like a problem of NetworkManager rather than OpenVPN. > > > Reassigning accordingly. > > > > > > Bruce, please check if the problem still exists in current Tumbleweed. > > > > I updated on February 17, 2018 and Tumbleweed still exhibits the problem. > > Can you still reproduce this in the latest Tumbleweed? My apologies but I switched from OpenVPN to WireGuard on all my VPN connections about 4 years ago and don't have any systems to test this on any more. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1231482] [Build 20241008-SELinux] openQA test fails in boot_into_snapshot: root: no shell: Permission denied
by bugzilla_noreply＠suse.com 22 Oct '24

22 Oct '24

https://bugzilla.suse.com/show_bug.cgi?id=1231482 https://bugzilla.suse.com/show_bug.cgi?id=1231482#c8 --- Comment #8 from Lukas Ocilka <locilka(a)suse.com> --- From that referenced code: # setfiles doesn't come with a stable command API and older versions # needs a different invocation syntax. On older versions the usage # information explicitly lists "setfiles -c policyfile" which is not # present in newer versions. As setfiles doesn't come with a simple # --version option, checking for this extra element in the usage # was the only pointer I could come up with to differentiate the # call options. I don't think this is "the right way" at all. How I see it is that all this should be hidden from any installer. It's a special action needed by the specific solution (SELinux). And it's definitely not "An Installer Bug", it might be a feature request though. But a feature request definitely needs a proper description. -- You are receiving this mail because: You are on the CC list for the bug.

1 0