March 2013 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 799496] New: PXE Boot of YaST not working, stops after DHCP request
by bugzilla_noreply＠novell.com 06 Mar '13

06 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=799496 https://bugzilla.novell.com/show_bug.cgi?id=799496#c0 Summary: PXE Boot of YaST not working, stops after DHCP request Classification: openSUSE Product: openSUSE Factory Version: 12.3 Beta 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: joschibrauchle(a)gmx.de QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.17 (KHTML, like Gecko) Chrome/24.0.1312.52 Safari/537.17 PXE booting 12.3-Beta1 using /oss/boot/x86_64/loader/initrd and /oss/boot/x86_64/loader/linux hangs after DHCP request. YaST never starts. PXE boot entry: --------------- LABEL openSUSE_12.3_INSTALL_AUTO_CONFIRM MENU LABEL Install openSUSE 12.3 with 12.3 AutoYaST (Confirm) KERNEL kernel123 APPEND initrd=initrd123 vga=0x31a ramdisk_size=512000 ramdisk_blocksize=4096 splash=silent quiet preloadlog=/dev/null showopts autoyast=nfs://<server>/ha/export/install/linux/opensuse/12.3/autoinstall/ install=nfs://<server>/ha/export/install/linux/opensuse/12.3/repos/oss y2confirm --------------- Using initrd and linux from 12.2 works. Reproducible: Always Steps to Reproduce: 1. PXE boot 12.3 Beta1 Actual Results: Hangs after DHCP request, YaST never starts Expected Results: YaST starts -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 30

[Bug 645652] New: Destructors of static variables not called during dlclose, ... sometimes ...
by bugzilla_noreply＠novell.com 06 Mar '13

06 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=645652 https://bugzilla.novell.com/show_bug.cgi?id=645652#c0 Summary: Destructors of static variables not called during dlclose, ... sometimes ... Classification: openSUSE Product: openSUSE 11.3 Version: Final Platform: i686 OS/Version: openSUSE 11.3 Status: NEW Severity: Normal Priority: P5 - None Component: Development AssignedTo: pth(a)novell.com ReportedBy: christoph.pesch(a)siemens.com QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.10) Gecko/20100914 SUSE/3.6.10-0.3.1 Firefox/3.6.10 Under unclear conditions, destructors of static variables in a shared object loaded with dlopen() are not called during dlclose() but later at program termination. The behavior toggles depending on whether std::vector<std::string> or std::deque<std::string> is used, the application is linked to boost_regex or not, dlopen() was invoked with RTLD_LAZY or RTLD_NOW, etc. Sometimes you need RTLD_NOW to see the problem, sometimes you can see it with RTLD_LAZY, too. I am not sure whether this problem is related to Bug 622977. The problem is not present in SUSE 10.2. It is present in openSUSE 11.3 with an older version of gcc (4.1.2) that I installed temporarily to investigate this problem. Therefore I guess it is a problem with the dynamic linker or libc. I wrote a small example which demonstrates the behavior (see attachment). You will need gcc, make and the boost libraries to reproduce it. The example includes source for a shared object which shows the expected behavior and for another shared object which shows the bug. The shared objects include a static variable which prints and flushes some output in the constructor and in the destructor. The main program prints some output, calls dlopen, prints some other output, calls dlclose and prints another output before it terminates. The expected order of output is 1. main (before dlopen), 2. Constructor (during dlopen) 3. main (after dlopen, before dlclose), 4. Destructor (during dlclose), 5. main (after dlclose). It works as expected in the first example. The second example adds an (unused) function that adds an element to a std::vector<std::string> and links boost_regex to the shared object. Now the order of output is 1. main (before dlopen), 2. Constructor (during dlopen) 3. main (after dlopen, before dlclose), 4. main (after dlclose), 5. Destructor (during program termination). The destructor is called too late. This behavior toggles if boost_regex is not linked to the shared object. It toggles again if the dlopen uses option RTLD_LAZY instead of RTLD_NOW. But I had other, more complicated examples, where I could see the same problem with RTLD_LAZY, too. Other examples (too complicated to include here) showed the problem with other boost libraries. Strange! Reproducible: Always Steps to Reproduce: 1. tar xvf dlclose_problem.tar 2. cd dlclose_problem 3. make 4. ./load_shared_object ./libshared_object1.so 5. ./load_shared_object ./libshared_object2.so Actual Results: pesch@kstbu027[~/src/c++/test/dlclose_problem]239: ./load_shared_object /libshared_object1.so before dlopen ... in SomeOutput() after dlopen, before dlclose ... in ~SomeOutput() after dlclose. pesch@kstbu027[~/src/c++/test/dlclose_problem]240: ./load_shared_object /libshared_object2.so before dlopen ... in SomeOutput() after dlopen, before dlclose ... after dlclose. in ~SomeOutput() Expected Results: pesch@kstbu027[~/src/c++/test/dlclose_problem]239: ./load_shared_object /libshared_object1.so before dlopen ... in SomeOutput() after dlopen, before dlclose ... in ~SomeOutput() after dlclose. pesch@kstbu027[~/src/c++/test/dlclose_problem]240: ./load_shared_object /libshared_object2.so before dlopen ... in SomeOutput() after dlopen, before dlclose ... in ~SomeOutput() after dlclose. pesch@kstbu027[~/src/c++/test/dlclose_problem]326: which gcc /usr/bin/gcc pesch@kstbu027[~/src/c++/test/dlclose_problem]327: gcc --version gcc (SUSE Linux) 4.5.0 20100604 [gcc-4_5-branch revision 160292] Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. pesch@kstbu027[~/src/c++/test/dlclose_problem]340: ls -latr /lib/ld-2.11.2.so -rwxr-xr-x 1 root root 143978 2010-07-19 12:10 /lib/ld-2.11.2.so pesch@kstbu027[~/src/c++/test/dlclose_problem]341: ldd libshared_object2.so linux-gate.so.1 => (0xffffe000) libboost_regex.so.1.42.0 => /usr/lib/libboost_regex.so.1.42.0 (0xb75ed000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb74fd000) libm.so.6 => /lib/libm.so.6 (0xb74d3000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb74b5000) libc.so.6 => /lib/libc.so.6 (0xb7349000) libicui18n.so.42 => /usr/lib/libicui18n.so.42 (0xb71a0000) libicuuc.so.42 => /usr/lib/libicuuc.so.42 (0xb7053000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7038000) /lib/ld-linux.so.2 (0xb773c000) libicudata.so.42 => /usr/lib/libicudata.so.42 (0xb60f1000) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 12

[Bug 806310] New: libz1-32bit doesn't obsolete latest zlib-32bit
by bugzilla_noreply＠novell.com 06 Mar '13

06 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=806310 https://bugzilla.novell.com/show_bug.cgi?id=806310#c0 Summary: libz1-32bit doesn't obsolete latest zlib-32bit Classification: openSUSE Product: openSUSE 12.3 Version: RC 1 Platform: Other OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: mvyskocil(a)suse.com ReportedBy: suse-beta(a)cboltz.de QAContact: qa-bugs(a)suse.de Found By: Beta-Customer Blocker: --- (using Factory, last updated some days ago) It looks like libz1-32bit doesn't obsolete the latest version of zlib-32bit that was available in Factory (and probably also in openSUSE 12.2). # rpm -q libz1-32bit zlib-32bit libz1-32bit-1.2.7-8.1.x86_64 zlib-32bit-1.2.7-3.5.x86_64 # rpm -q --conflicts libz1-32bit # rpm -q --obsoletes libz1-32bit zlib-32bit < 1.2.7 # rpm -qi zlib-32bit Name : zlib-32bit Version : 1.2.7 Release : 3.5 Architecture: x86_64 Install Date: Mi 03 Okt 2012 16:57:21 CEST This causes two problems: a) zypper doesn't propose to install libz1-32bit automatically - I have to explicitely "zypper in libz1-32bit" b) when doing this, zypper doesn't propose to delete zlib-32bit This means I end up with libz1-32bit _and_ zlib-32bit installed. The main problem with this is that both own the same files: # rpm -ql libz1-32bit /lib/libz.so.1 /lib/libz.so.1.2.7 # rpm -ql zlib-32bit /lib/libz.so.1 /lib/libz.so.1.2.7 Looks like renaming a package without doing a version upgrade isn't the best idea - at least it makes adding a correct Obsoletes interesting[tm]. Interestingly, this seems to affect only the -32bit package. The 64bit zlib package was correctly replaced by libz1 - but I have no idea how and why ;-) (FYI: I usually use "zypper dup", only if dup comes up with too many conflicts, I use "zypper up".) Note: according to software.o.o, openSUSE 12.2 also came with zlib 1.2.7. This means this bug might also affect people who upgrade from 12.2 to 12.3. Michal: you renamed the package, therefore I'll assign this bugreport to you ;-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 5

[Bug 779361] New: installer does not recognize Tumbleweed and current repos
by bugzilla_noreply＠novell.com 06 Mar '13

06 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=779361 https://bugzilla.novell.com/show_bug.cgi?id=779361#c0 Summary: installer does not recognize Tumbleweed and current repos Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: 64bit OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: bluedzins(a)wp.pl QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:14.0) Gecko/20100101 Firefox/14.0.1 By definition Tumbleweed and current repos are always valid for given version of openSUSE. This was the goal of those repos, that instead of adding repo targeting (for example) 12.1 I use "current" and when I upgrade to newest version, this will be still the appropriate repo. The installer however does not only recognize it, but also instead of simply disabling it, tries to remove it (never, ever try to remove user's data, unless user explicitly says so). So it is a double bug here. Reproducible: Always Steps to Reproduce: 1. Install 12.1 2. add current or TW repo 3. upgrade to 12.2 4. observe the installer tries to remove those repos Expected Results: TW and current repos should stay intact, all others repos should be DISABLED. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 17

[Bug 800742] New: Gnome 3.6: screen stays locked with "authentication error"
by bugzilla_noreply＠novell.com 06 Mar '13

06 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=800742 https://bugzilla.novell.com/show_bug.cgi?id=800742#c0 Summary: Gnome 3.6: screen stays locked with "authentication error" Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: GNOME AssignedTo: bnc-team-gnome(a)forge.provo.novell.com ReportedBy: kkaempf(a)suse.com QAContact: qa-bugs(a)suse.de Found By: Development Blocker: --- I'm running Gnome 3.6 (from obs GNOME:/STABLE:/3.6/openSUSE_12.2) on 12.2 and regularly get locked out by the gnome screen lock. If the gnome screen lock runs for a while (usually hours), the password input field stays disabled and "authentication error" is shown below. The only way out currently is to restart gdm. Note that this doesn't happen if the screen lock runs for a short time (approx up to 1hr). Environment: corporate workstation, authentication via nis/ypbind -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 10

[Bug 807514] New: Failed loade i915
by bugzilla_noreply＠novell.com 06 Mar '13

06 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=807514 https://bugzilla.novell.com/show_bug.cgi?id=807514#c0 Summary: Failed loade i915 Classification: openSUSE Product: openSUSE 12.3 Version: RC 2 Platform: Other OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: bili(a)suse.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- After I startup, there are some message in console. FATAL: Error inserting i915 (/lib/modules/3.7.9-1.1-desktop/kernel/drivers/gpu/drm/i915/i915.ko): No such device. When I try to insmod manually, it prompt a lot of "Unknow symbol drm_xxxxx (err 0)" message in dmesg. It's the drm's bug? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 3

[Bug 781810] New: xorg driver intel 2.20: Option XvMC does not work
by bugzilla_noreply＠novell.com 05 Mar '13

05 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=781810 https://bugzilla.novell.com/show_bug.cgi?id=781810#c0 Summary: xorg driver intel 2.20: Option XvMC does not work Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: PC OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: X.Org AssignedTo: bnc-team-xorg-bugs(a)forge.provo.novell.com ReportedBy: comes(a)naic.edu QAContact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0 In the latest intel driver 2.20 there is a bug that makes the driver ignore the option XvMC in the xorg config file. A detailed explanation of the bug can be found here: http://lists.freedesktop.org/archives/intel-gfx/2012-September/020630.html The fix is available here: http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c2ca1c5… Please apply. Reproducible: Always Steps to Reproduce: 1.Add Option "XvMC" "on" in /etc/X11/xorg.conf.d/50-device.conf 2. 3. Actual Results: Option "XvMC" "on" is ignored Expected Results: Option "XvMC" "on" should work -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 2

[Bug 804329] New: xterm crashes when selecting "Huge" font
by bugzilla_noreply＠novell.com 05 Mar '13

05 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=804329 https://bugzilla.novell.com/show_bug.cgi?id=804329#c0 Summary: xterm crashes when selecting "Huge" font Classification: openSUSE Product: openSUSE 12.3 Version: RC 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: X.Org AssignedTo: bnc-team-xorg-bugs(a)forge.provo.novell.com ReportedBy: koenig(a)linux.de QAContact: xorg-maintainer-bugs(a)forge.provo.novell.com Found By: --- Blocker: --- pressing CTRL right-mouse-button in xterm and selecting "Huge" font gives xterm: warning, error event received: X Error of failed request: BadAlloc (insufficient resources for operation) Major opcode of failed request: 45 (X_OpenFont) Serial number of failed request: 672 Current serial number in output stream: 673 and xterm terminates ;-(( the bold version for "font6" in /usr/share/X11/app-defaults/XTerm (identical to 12.2) does not work anymore in xterm: $ grep font6 /usr/share/X11/app-defaults/XTerm *fontMenu*font6*Label: Huge !*VT100.font6: 10x20 *VT100.font6: -misc-fixed-medium-r-normal-*-20-200-75-75-c-100-iso10646-1 !*VT100.utf8Fonts.font6: -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 $ xlsfonts -fn -misc-fixed-medium-r-normal-*-20-200-75-75-c-100-iso10646-1 -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 BUT: $ xlsfonts -fn -misc-fixed-bold-r-normal-*-20-200-75-75-c-100-iso10646-1 xlsfonts: pattern "-misc-fixed-bold-r-normal-*-20-200-75-75-c-100-iso10646-1" unmatched -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 6

[Bug 807614] New: Evolution segfaults when used to pull news (nntp) automatically
by bugzilla_noreply＠novell.com 05 Mar '13

05 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=807614 https://bugzilla.novell.com/show_bug.cgi?id=807614#c0 Summary: Evolution segfaults when used to pull news (nntp) automatically Classification: openSUSE Product: openSUSE 12.3 Version: RC 2 Platform: x86-64 OS/Version: SUSE Other Status: NEW Severity: Normal Priority: P5 - None Component: Evolution AssignedTo: bnc-team-evolution(a)forge.provo.novell.com ReportedBy: zaitor(a)opensuse.org QAContact: lakhil(a)novell.com Found By: --- Blocker: --- Created an attachment (id=528281) --> (http://bugzilla.novell.com/attachment.cgi?id=528281) Full backtrace from run in gdb. evolution-3.6.3-1.2.1 evolution-data-server-3.6.3-1.2.1 Add forums.opensuse.org as nntp server, pull news. - set "pull" to every 10 min. Leave the client, watch it crash. Backtrace from gdb attached. [New Thread 0x7fff37fff700 (LWP 6865)] [New Thread 0x7fff3d7d1700 (LWP 6866)] (evolution:6646): camel-nntp-provider-CRITICAL **: camel_nntp_stream_set_mode: assertion `is != NULL' failed Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff37fff700 (LWP 6865)] camel_nntp_raw_commandv (store=store@entry=0xb611a0, cancellable=cancellable@entry=0x17d81e0, error=error@entry=0x7fff37ffe880, line=line@entry=0x7fff37ffe998, fmt=fmt@entry=0x7fffd9bb9cf7 "group %s", ap=ap@entry=0x7fff37ffe738) at camel-nntp-store.c:1544 1544 camel-nntp-store.c: No such file or catalog. (gdb) thread apply all bt -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 2

[Bug 773559] New: Tumbleweed: With Kernel 3.5.0 USB keyboard doesn't work to input LVM password during boot
by bugzilla_noreply＠novell.com 05 Mar '13

05 Mar '13

https://bugzilla.novell.com/show_bug.cgi?id=773559 https://bugzilla.novell.com/show_bug.cgi?id=773559#c0 Summary: Tumbleweed: With Kernel 3.5.0 USB keyboard doesn't work to input LVM password during boot Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: openSUSE 12.1 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers(a)forge.provo.novell.com ReportedBy: veniastra(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=500345) --> (http://bugzilla.novell.com/attachment.cgi?id=500345) dmesg output from system running 3.5.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.3 (KHTML, like Gecko) Chrome/22.0.1218.0 Safari/537.3 SUSE/22.0.1218.0 The USB keyboard does not work upon boot when prompted input the LVM password. It did however work as expected in both the BIOS and GRUB. It is also recognised as being connected by the kernel, as can be seen by this snipped of dmesg: [ 3.268034] usb 5-2: new low-speed USB device number 3 using uhci_hcd [ 3.456915] usb 5-2: New USB device found, idVendor=046a, idProduct=0011 [ 3.470104] usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0 Where 046a:0011 is in fact the keyboard, as can be seen by lsusb: sh-4.2$ lsusb Bus 002 Device 004: ID 046d:0809 Logitech, Inc. Webcam Pro 9000 Bus 003 Device 002: ID 413c:8140 Dell Computer Corp. Wireless 360 Bluetooth Bus 005 Device 002: ID 046d:c041 Logitech, Inc. G5 Laser Mouse Bus 005 Device 004: ID 046a:0011 Cherry GmbH G83 (RS 6000) Keyboard Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub The keyboard is a simple Cherry G83, a mechanical keyboard as plain as a keyboard can be, no media keys etc. are present. I specify this because even though it sounds like https://bugzilla.novell.com/show_bug.cgi?id=741451, I am not sure this is a driver/mkinitrd issue. Reproducible: Always Steps to Reproduce: 1. Use an encrypted LVM containing the / partition 2. Connect an external usb keyboard 3. Boot Actual Results: USB Keyboard does not work, no option to input LVM password unless a built-in keyboard (laptop) is present Expected Results: USB Keyboard works, LVM password can be typed in openSUSE Tumbleweed x86_64 updated from 12.1 Kernel version according to `uname -r`: 3.5.0-35-desktop Since this is a laptop, I am lucky enough to still be able to boot. I am writing this from the booted machine that is affected. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 35