May 2016 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 902401] New: plymouth segfault
by bugzilla_noreply＠novell.com 15 Nov '19

15 Nov '19

http://bugzilla.opensuse.org/show_bug.cgi?id=902401 Bug ID: 902401 Summary: plymouth segfault Classification: openSUSE Product: openSUSE Factory Version: NO 13.2 BUGS!! Hardware: i686 OS: openSUSE 13.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: idonmez(a)suse.com Reporter: mpluskal(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- # systemd-coredumpctl gdb 169 TIME PID UID GID SIG EXE Čt 2014-10-23 14:42:07 CEST 169 0 0 11 /usr/sbin/plymouthd GNU gdb (GDB; openSUSE Factory) 7.8 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i586-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.opensuse.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... warning: /etc/gdbinit.d/gdb-heap.py: Adresář nebo soubor neexistuje Reading symbols from /usr/sbin/plymouthd...Reading symbols from /usr/lib/debug/usr/sbin/plymouthd.debug...done. done. [New LWP 169] b[Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `@usr/sbin/plymouthd --mode=boot --pid-file=/run/plymouth/pid --attach-to-sessio'. Program terminated with signal SIGSEGV, Segmentation fault. #0 ply_event_loop_stop_watching_signal (loop=0x7665642f, signal_number=signal_number@entry=28) at ply-event-loop.c:869 t869 ply-event-loop.c: Adresář nebo soubor neexistuje. (gdb) bt #0 ply_event_loop_stop_watching_signal (loop=0x7665642f, signal_number=signal_number@entry=28) at ply-event-loop.c:869 #1 0xb76febe7 in ply_terminal_close (terminal=0x99f4008) at ply-terminal.c:707 #2 0xb7717159 in ply_hashtable_foreach (hashtable=0x99f3dc8, func=0xb76feb10 <ply_terminal_close>, user_data=user_data@entry=0x99f3e18) at ply-hashtable.c:272 #3 0xb76fb0fc in ply_close_all_terminals (manager=0x99f3e18) at ply-device-manager.c:954 #4 0x0805396c in quit_splash (state=state@entry=0xbff95794) at main.c:1083 #5 0x08053a4f in dump_details_and_quit_splash (state=state@entry=0xbff95794) at main.c:1114 #6 0x08053ccf in on_quit (state=0xbff95794, retain_splash=false, quit_trigger=0x99f6ac0) at main.c:1349 #7 0x0804ee27 in ply_boot_connection_on_request (connection=0x9a028e0) at ply-boot-server.c:534 #8 0xb7713fc6 in ply_event_loop_handle_met_status_for_source (status=PLY_EVENT_LOOP_FD_STATUS_HAS_DATA, source=0x99f1af0, loop=0x99ef0b0) at ply-event-loop.c:1060 #9 ply_event_loop_process_pending_events (loop=loop@entry=0x99ef0b0) at ply-event-loop.c:1327 #10 0xb7714508 in ply_event_loop_run (loop=0x99ef0b0) at ply-event-loop.c:1359 #11 0x0804c424 in main (argc=4, argv=0xbff95ab4) at main.c:2357 (gdb) bt full #0 ply_event_loop_stop_watching_signal (loop=0x7665642f, signal_number=signal_number@entry=28) at ply-event-loop.c:869 node = 0x19 #1 0xb76febe7 in ply_terminal_close (terminal=0x99f4008) at ply-terminal.c:707 __func__ = "ply_terminal_close" #2 0xb7717159 in ply_hashtable_foreach (hashtable=0x99f3dc8, func=0xb76feb10 <ply_terminal_close>, user_data=user_data@entry=0x99f3e18) at ply-hashtable.c:272 i = 5 #3 0xb76fb0fc in ply_close_all_terminals (manager=0x99f3e18) at ply-device-manager.c:954 No locals. #4 0x0805396c in quit_splash (state=state@entry=0xbff95794) at main.c:1083 __func__ = "quit_splash" #5 0x08053a4f in dump_details_and_quit_splash (state=state@entry=0xbff95794) at main.c:1114 No locals. #6 0x08053ccf in on_quit (state=0xbff95794, retain_splash=false, quit_trigger=0x99f6ac0) at main.c:1349 __func__ = "on_quit" #7 0x0804ee27 in ply_boot_connection_on_request (connection=0x9a028e0) at ply-boot-server.c:534 retain_splash = false quit_trigger = 0x99f6ac0 server = 0x99f1688 command = 0x99f69f8 "Q" argument = 0x99f6b40 "" __PRETTY_FUNCTION__ = "ply_boot_connection_on_request" __func__ = "ply_boot_connection_on_request" #8 0xb7713fc6 in ply_event_loop_handle_met_status_for_source (status=PLY_EVENT_LOOP_FD_STATUS_HAS_DATA, source=0x99f1af0, loop=0x99ef0b0) at ply-event-loop.c:1060 next_node = 0x0 destination = 0x9a02a50 node = <optimized out> #9 ply_event_loop_process_pending_events (loop=loop@entry=0x99ef0b0) at ply-event-loop.c:1327 source = 0x99f1af0 is_disconnected = <optimized out> number_of_received_events = 1 i = 0 events = {{events = 1, data = {ptr = 0x99f1af0, fd = 161422064, u32 = 161422064, u64 = 161422064}}, {events = 4294967295, data = {ptr = 0xffffffff, fd = -1, u32 = 4294967295, u64 = 18446744073709551615}} <repeats 63 times>} __PRETTY_FUNCTION__ = "ply_event_loop_process_pending_events" #10 0xb7714508 in ply_event_loop_run (loop=0x99ef0b0) at ply-event-loop.c:1359 No locals. #11 0x0804c424 in main (argc=4, argv=0xbff95ab4) at main.c:2357 state = {loop = 0x99ef0b0, boot_server = 0x99f1688, boot_splash = 0x0, session = 0x99f27e0, boot_buffer = 0x99f17c8, progress = 0x99f3d60, keystroke_triggers = 0x99ef5e0, entry_triggers = 0x99ef5f0, entry_buffer = 0x99f0660, messages = 0x99f1678, command_parser = 0x99ef008, mode = PLY_MODE_BOOT, local_console_terminal = 0x99f40d8, device_manager = 0x99f3e18, deactivate_trigger = 0x0, quit_trigger = 0x99f6ac0, start_time = 2.9794491600000002, splash_delay = nan(0x8000000000000), kernel_command_line = "BOOT_IMAGE=/boot/vmlinuz-3.17.1-0.g5c4d099-default root=UUID=04f6a8f9-ec8e-4fd8-9d03-9159c16a0a32 resume=/dev/disk/by-id/ata-ST3200827A_5ND4PPCL-part1 splash=silent quiet showopts Y2DEBUG=1\n", '\000' <repeats 321 times>, kernel_command_line_is_set = 1, no_boot_log = 0, showing_details = 1, system_initialized = 1, is_redirected = 0, is_attached = 0, should_be_attached = 1, should_retain_splash = 0, is_inactive = 1, is_shown = 0, should_force_details = 0, override_splash_path = 0x0, system_default_splash_path = 0x99f3e80 "/usr/share/plymouth/themes/openSUSE/openSUSE.plymouth", distribution_default_splash_path = 0x99f3f80 "/usr/share/plymouth/themes/openSUSE/openSUSE.plymouth", default_tty = 0x805641f "/dev/tty7", number_of_errors = 0} exit_code = <optimized out> should_help = false no_boot_log = false no_daemon = false debug = false attach_to_session = true daemon_handle = 0x99ef5a0 mode_string = 0x99ef5a0 " " kernel_command_line = 0x0 tty = 0x0 device_manager_flags = <optimized out> sa = {__sigaction_handler = {sa_handler = 0x80529e0 <dosigaction>, sa_sigaction = 0x80529e0 <dosigaction>}, sa_mask = {__val = {0 <repeats 32 times>}}, sa_flags = -2147483648, sa_restorer = 0x0} __func__ = "main" -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 975879] New: plymouthd crashes in ply_event_loop_stop_watching_fd
by bugzilla_noreply＠novell.com 15 Nov '19

15 Nov '19

http://bugzilla.opensuse.org/show_bug.cgi?id=975879 Bug ID: 975879 Summary: plymouthd crashes in ply_event_loop_stop_watching_fd Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: daniel.lichtenberger(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- In my openSUSE Tumbleweed installation, plymouthd always coredumps during startup. Backtrace: #0 ply_event_loop_get_destination_from_fd_watch (loop=0x7974742f7665642f, watch=0x21) at ply-event-loop.c:449 #1 0x00007f0d1675920b in ply_event_loop_stop_watching_fd (loop=0x7974742f7665642f, watch=0x21) at ply-event-loop.c:750 #2 0x00007f0d165458f7 in ply_terminal_close () from /usr/lib64/libply-splash-core.so.4 #3 0x00007f0d1675cc53 in ply_hashtable_foreach (hashtable=0x180f8e0, func=0x7f0d16545870 <ply_terminal_close>, user_data=0x180ff20) at ply-hashtable.c:268 #4 0x000000000040c050 in quit_splash (state=state@entry=0x7ffd0872a000) at main.c:1064 #5 0x000000000040c8af in on_boot_splash_idle (state=0x7ffd0872a000) at main.c:1196 #6 0x00007f0d16759d2a in ply_event_loop_handle_timeouts (loop=0x180a150) at ply-event-loop.c:1192 #7 ply_event_loop_process_pending_events (loop=loop@entry=0x180a150) at ply-event-loop.c:1251 #8 0x00007f0d1675a340 in ply_event_loop_run (loop=0x180a150) at ply-event-loop.c:1310 #9 0x0000000000405454 in main (argc=<optimized out>, argv=<optimized out>) at main.c:2233 plymouth package version: 0.9.2-2.1 I also reported this at https://bugs.freedesktop.org/show_bug.cgi?id=94952, but later noticed that the stacktrace points to OpenSUSE patches (ply_close_all_terminals in quit_splash). -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 935864] New: zlib: package minizip?
by bugzilla_noreply＠novell.com 12 Nov '19

12 Nov '19

http://bugzilla.suse.com/show_bug.cgi?id=935864 Bug ID: 935864 Summary: zlib: package minizip? Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: tchvatal(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: security-team(a)suse.de Found By: --- Blocker: --- zlib contains contrib/minizip which at least by judging from the use of unzip.h is contained as copy in 30 other packages. What about building minizip as separate sub package? -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 911355] New: Job for spamd.service failed
by bugzilla_noreply＠novell.com 11 Nov '19

11 Nov '19

http://bugzilla.suse.com/show_bug.cgi?id=911355 Bug ID: 911355 Summary: Job for spamd.service failed Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: stephan.barth(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- After the upgrade from 12.3 I found out that spmad was not running anymore. When trying to start it manually I get: # /etc/init.d/spamd restart redirecting to systemctl restart spamd.service Job for spamd.service failed. See "systemctl status spamd.service" and "journalctl -xn" for details. Running the latter command yields: Dec 29 16:40:11 linux-wulv echo[6901]: Starting spamd: Dec 29 16:40:11 linux-wulv spamd[6903]: logger: removing stderr method Dec 29 16:40:11 linux-wulv spamd[6905]: config: no rules were found! Do you need to run 'sa-update'? Dec 29 16:40:12 linux-wulv spamd[6903]: child process [6905] exited or timed out without signaling production of a PID file: exit 255 at /us Dec 29 16:40:12 linux-wulv spamd[6903]: child process [6905] exited or timed out without signaling production of a PID file: exit 255 at /us Dec 29 16:40:12 linux-wulv systemd[1]: Failed to start Daemonized version of spamassassin. -- Subject: Unit spamd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit spamd.service has failed. -- -- The result is failed. # rpm -q perl-Mail-SpamAssassin perl-Mail-SpamAssassin-3.4.0-44.1.3.x86_64 # rpm -q spamassassin spamassassin-3.4.0-44.1.3.x86_64 Solution: Running sa-update manually makes spamd start with '/etc/init.d/spamd restart'. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 950955] New: Error Messages from rtkit-daemon caused by CONFIG_RT_GROUP_SCHED
by bugzilla_noreply＠novell.com 04 Nov '19

04 Nov '19

http://bugzilla.opensuse.org/show_bug.cgi?id=950955 Bug ID: 950955 Summary: Error Messages from rtkit-daemon caused by CONFIG_RT_GROUP_SCHED Classification: openSUSE Product: openSUSE Factory Version: 2015* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: Jan.Hebler(a)Kabeldeutschland.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- rtkit-daemon produces the following Error-Messages: ... Okt 19 07:06:19 tablette rtkit-daemon[3051]: Failed to make ourselves RT: Operation not permitted ... If i understand Lennart Poettering here https://bugzilla.redhat.com/show_bug.cgi?id=1229700 correct, the Kernel-Option CONFIG_RT_GROUP_SCHED should turned off. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 941758] New: grub-once isn't called at hibernate
by bugzilla_noreply＠novell.com 22 Oct '19

22 Oct '19

http://bugzilla.opensuse.org/show_bug.cgi?id=941758 Bug ID: 941758 Summary: grub-once isn't called at hibernate Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: tiwai(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Since the recent change of systemd, grub-once isn't called any longer, thus at thawing, the normal GRUB menu is shown instead of the direct boot to the target kernel. The regression was introduced in openSUSE:Factory/systemd changeset 215: Wed Feb 18 05:01:38 UTC 2015 - crrodriguez(a)opensuse.org .... - systemd-sleep-grub: moved to the grub2 package where it belongs as a suspend/resume hook (SR#286533) (drops prepare-suspend-to-disk.patch) However, SR#286533 was declined and it's lost since then. The fix would be either revert the change in systemd or put the hook properly into grub2 package. The latter method has a potential bug, however. systemd-sleep doesn't call hooks to restore when writing to /sys/power/state fails. That is, if we have a hook to set up grubenv, it'll left when the hibernation fails, and the next boot would go wrong. This didn't happen in the past because it invoked the grubenv setup in a different manner. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 969165] New: parted creates wrong protective mbr
by bugzilla_noreply＠novell.com 22 Oct '19

22 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=969165 Bug ID: 969165 Summary: parted creates wrong protective mbr Classification: openSUSE Product: openSUSE Tumbleweed Version: 2015* Hardware: Other OS: Other Status: NEW Severity: Minor Priority: P5 - None Component: Basesystem Assignee: puzel(a)suse.com Reporter: snwint(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: Development Blocker: --- The protective mbr parted creates has inconsistent data. The CHS value for the partition start is 0/0/1 (pointing to the MBR itself) but should be 0/0/2 (pointing to the partition). The LBA starting value of 1 is correct, however. (CHS values are 1-based.) UEFI spec also explicitly mentions the correct value 0/0/2. gptfdisk works correctly, btw. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 939248] New: gnome-shell not having correct SSH_AUTH_SOCK variable
by bugzilla_noreply＠novell.com 20 Oct '19

20 Oct '19

http://bugzilla.suse.com/show_bug.cgi?id=939248 Bug ID: 939248 Summary: gnome-shell not having correct SSH_AUTH_SOCK variable Classification: openSUSE Product: openSUSE Factory Version: 201505* Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: bnc-team-gnome(a)forge.provo.novell.com Reporter: vuntz(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Any process that I start through gnome-shell seems to have a SSH_AUTH_SOCK matching a ssh-agent process (probably started through the X11 session scripts). However, if I start a process through gnome-settings-daemon (like a terminal, through the shortcurt for that), it has SSH_AUTH_SOCK set to the path for gnome-keyring. The result is that any app I start through gnome-shell actually has, by default, not access to my ssh keys :/ (also, I thought I had fixed a long time ago the bit starting ssh-agent on gnome sessions -- this shouldn't happen because of the keyring) -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 939153] New: Thunderbird 38: Integrated Lightning calendar is not properly localized
by bugzilla_noreply＠novell.com 27 Sep '19

27 Sep '19

http://bugzilla.opensuse.org/show_bug.cgi?id=939153 Bug ID: 939153 Summary: Thunderbird 38: Integrated Lightning calendar is not properly localized Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Translations Assignee: ke(a)suse.com Reporter: lashkevi(a)landau.ac.ru QA Contact: ke(a)suse.com Found By: --- Blocker: --- Created attachment 641749 --> http://bugzilla.opensuse.org/attachment.cgi?id=641749&action=edit Snapshot for a fresh profile. Integrated Lightning in the Thundebird 38.1.0 from the last official update is not localized. Its whole UI is in English. Versions: MozillaThunderbird-38.1.0-70.57.1.x86_64 MozillaThunderbird-translations-common-38.1.0-70.57.1.x86_64 Steps to reproduce: 1. Update TB to 38.1. It removes the Lightning add-on substituting it by its integrated version as well as I understand. 2. Start TB in Russian (LANG=ru_RU.UTF-8 LANGUAGE=ru) locale. Actual results: Calendar (Lightning) menu items, config options and the whole UI is in English. Expected results: Calendar (Lightning) menu items, config options and UI should be in Russian. The issue is corrected after installing Lightning from a file (lightning-4.0.1-sm+tb-linux.xpi). But such workaround must make thundebird use more memory. The vanilla Russian version <https://download.mozilla.org/?product=thunderbird-38.1.0&os=linux64&lang=ru> does not show this issue, so that it is a problem of the OpenSUSE build. -- You are receiving this mail because: You are on the CC list for the bug.

1 35

[Bug 921221] New: Unable to install with UEFI Secure Boot if Windows is present
by bugzilla_noreply＠novell.com 26 Sep '19

26 Sep '19

http://bugzilla.opensuse.org/show_bug.cgi?id=921221 Bug ID: 921221 Summary: Unable to install with UEFI Secure Boot if Windows is present Classification: openSUSE Product: openSUSE Factory Version: 201502* Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Bootloader Assignee: jsrain(a)suse.com Reporter: rbrown(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Hardware: ASUS UX303LA with Windows 8.1, i7 5500U, 12GB RAM Steps to Reproduce: 1. Factory/Plain installation of Windows 8.1 2. Burn a Tumbleweed (or 13.2) USB stick - Tried with a NET, DVD, or Live ISO 3. Boot to it - Blue ncurses screen asking if you trust the SUSE Keys pops up 4. Click Yes 5. End up at a Grub2 command prompt, system refuses to boot into YaST - lots of different attempts to get it booted by setting linuxefi and initrdefi don't work 6. Clearing KEK, etc, in the Bios doesn't help 7. Trying different USB sticks doesn't help 8. The 'do you want to trust SUSEs Keys' ncurses window never appears again 9. Switching the BIOS to boot into Legacy mode, booting to a liveUSB in Legacy, wiping the hard drive and starting the process fresh works..but obviously, you have no opportunity to dual boot with Windows 8 Looks to me like there is something wrong with how we're currently trying to insert keys/shim/whatever into the EFI configuration present on a fresh Windows 8.1 install. This is a pretty serious problem if people want to easily install openSUSE on freshly purchased hardware. -- You are receiving this mail because: You are on the CC list for the bug.

1 12