February 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 766076] New: Throughout the period during resumption from hibernation ugly text mode screen is seen
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=766076 https://bugzilla.novell.com/show_bug.cgi?id=766076#c0 Summary: Throughout the period during resumption from hibernation ugly text mode screen is seen Classification: openSUSE Product: openSUSE 12.2 Version: Beta 1 Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: badshah400(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=494089) --> (http://bugzilla.novell.com/attachment.cgi?id=494089) /boot/grub2/grub.cfg file User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20100101 Firefox/13.0 While Suspending to disc/hibernation, with the plymouth integration, a pretty graphical screen very similar to the plymouth boot-up screen is seen. However, when resuming from hibernation, a black text mode screen is seen with textual indication of progress (10%, 20%, etc). It would be great to fix this so that during resumption from hibernation also the pretty plymouth graphical screen is displayed. Reproducible: Always Steps to Reproduce: 1. 2. 3. -- 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 841384] New: Plymouth does not ask for disk unlock password on VGA console if serial console is also present
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=841384 https://bugzilla.novell.com/show_bug.cgi?id=841384#c0 Summary: Plymouth does not ask for disk unlock password on VGA console if serial console is also present Classification: openSUSE Product: openSUSE Factory Version: 13.1 Beta 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: tittiatcoke(a)gmail.com ReportedBy: ptesarik(a)suse.com QAContact: qa-bugs(a)suse.de Found By: L3 Blocker: --- I'm booting with the following kernel command line: 2013-09-19T22:33:27.356031+02:00 hananiah kernel: [ 0.000000] Kernel command line: BOOT_IMAGE=/vmlinuz-3.11.1-1.g1383321-desktop root=/dev/mapper/Factory-Root resume=/dev/disk/by-label/FACTORY-SWAP crashkernel=96M console=ttyS4,115200 console=tty0 splash=silent quiet showopts When the init script gets to asking the password to unlock my encrypted LVM2 volume, I can not enter it on the VGA console. It is only accepted over the serial console. -- 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 862197] New: kmymoney OFX plugin and maybe other do not work (OpenSUSE rpm packages)
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=862197 https://bugzilla.novell.com/show_bug.cgi?id=862197#c0 Summary: kmymoney OFX plugin and maybe other do not work (OpenSUSE rpm packages) Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Major Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: bogdan(a)hlevca.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36 When installed kmymoney from OpenSUSE rpm packages the OFX plugin and some others do not show up in the File menu. You can verify this by opening a File->Import menu and only QIF and Gnuchash show up. There should be a lot more: AqBanking, CSV, OFX. It is a Suse issue because I installed kmymoney from GIT sources and those menu items are available. Reproducible: Always Steps to Reproduce: 1. Open File->Import Actual Results: The menu shows only QIF and GNUCASH Expected Results: Should also show AqBanking, CSV, OFX. -- 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 862075] New: CTDB should include tmpfiles.d entry for /var/run/ctdb
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=862075 https://bugzilla.novell.com/show_bug.cgi?id=862075#c0 Summary: CTDB should include tmpfiles.d entry for /var/run/ctdb Classification: openSUSE Product: openSUSE Factory Version: 13.2 Milestone 0 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Samba AssignedTo: samba-maintainers(a)SuSE.de ReportedBy: tserong(a)suse.com QAContact: samba-maintainers(a)SuSE.de Found By: --- Blocker: --- /usr/sbin/ctdbd_wrapper (invoked by the ctdb systemd service file) creates /run/ctdb at runtime, but really this directory should be created via a tmpfiles.d entry as described at: http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#Creating_files… See /usr/lib/tmpfiles.d/samba.conf and the Samba spec file for how this was done for Samba. Please note that this may also arguably want fixing on pre-13.2 releases, although users are only likely to actually hit the problem when using CTDB in a Pacemaker cluster (where ctdbd_wrapper is not used), as opposed to using CTDB by itself. -- 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 826973] New: zypper: useless message about recommends
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=826973 https://bugzilla.novell.com/show_bug.cgi?id=826973#c0 Summary: zypper: useless message about recommends Classification: openSUSE Product: openSUSE Factory Version: 13.1 Milestone 2 Platform: x86-64 OS/Version: Linux Status: NEW Severity: Minor Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers(a)forge.provo.novell.com ReportedBy: jengelh(a)inai.de QAContact: qa-bugs(a)suse.de Found By: Beta-Customer Blocker: --- Created an attachment (id=545842) --> (http://bugzilla.novell.com/attachment.cgi?id=545842) /var/log/zypp*, tar -tf at.spec has a Recommends: smtp_daemon. The system however already has postfix installed thereby satisfying smtp_daemon, so zypper should not display the part about exim at all. # zypper in at Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW package is going to be installed: at The following package is recommended, but will not be installed due to conflicts or dependency issues: exim 1 new package to install. Overall download size: 57.8 KiB. After the operation, additional 116.3 KiB will be used. # rpm -q zypper libzypp libsolv-tools zypper-1.9.0-2.2.x86_64 libzypp-13.3.0-1.1.x86_64 libsolv-tools-0.3.0-2.2.x86_64 (factory du jour) # rpm -q --whatprovides smtp_daemon postfix-2.9.6-5.1.x86_64 -- 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 822964] New: with systemd ssh connections hang when doing a re-boot
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=822964 https://bugzilla.novell.com/show_bug.cgi?id=822964#c0 Summary: with systemd ssh connections hang when doing a re-boot Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: support(a)microtechniques.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20130518 Firefox/20.0 PaleMoon/20.1 Since upgrading to 12.3 with systemd about half my systems hang the ssh connection when I remotely re-boot the system. In earlier versions, there were several seconds after doing a shutdown -? now when you could do an 'exit' before the network went down. In 12.2, the system closed the connection for you, and you did not have to issue an 'exit'. In 12.3, the system does not always close the connection, and there is not enough time to issue the 'exit' yourself, leaving the terminal session hung. However, this does not happen for all of my systems, a few still behave in the 12.2 fashion. I am assuming that this is an systemd artifact, and not a change to the ssh daemon since all of the systems are running the same version of ssh. Reproducible: Sometimes Steps to Reproduce: 1. 2. 3. -- 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 15

[Bug 721663] New: udev: should we add deps between udev/libudev?
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=721663 https://bugzilla.novell.com/show_bug.cgi?id=721663#c0 Summary: udev: should we add deps between udev/libudev? Classification: openSUSE Product: openSUSE 12.1 Version: Milestone 5 Platform: All OS/Version: Linux Status: NEW Severity: Enhancement Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jengelh(a)medozas.de QAContact: qa(a)suse.de Found By: Beta-Customer Blocker: --- Prehistory: wanted to have a new systemd on 11.4, so I went to install that, its dependencies (newer versions of filesystem, mkinitrd, udev, etc.) and all xorg-*. Result: input in Xorg does not work, i.e. keypresses and mouse produce no events. Now, I know that half-updated systems are not particularly supported, but it shows that using develproject repositories (and their openSUSE_11.4 output mode) may have similar issues. Well, turns out that libudev0-166, which was still installed since no rpm requirements required its update, is incompatible with udev-173. Updating libudev0-166 to libudev0-173 resolves the Xorg kb/mouse issue. Since it seems that libudev is tied to udev, should we perhaps consider adding a manual Requires tag in some .spec file? -- 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 628298] New: api.o.o flakes out when remote bs_srcserver requests
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

http://bugzilla.novell.com/show_bug.cgi?id=628298 http://bugzilla.novell.com/show_bug.cgi?id=628298#c0 Summary: api.o.o flakes out when remote bs_srcserver requests Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: Major Priority: P5 - None Component: BuildService AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jengelh(a)medozas.de QAContact: adrian(a)novell.com Found By: Beta-Customer Blocker: --- When a OBS local instance is booted, the local scheduler queries the local srcserver for projpacks. # rcobssrcserver status Checking for obssrcserver and running processes: R 4287 29613 GET /getprojpack?withsrcmd5&withdeps&withrepos&withconfig&arch=x86_64 ~same line~ ...=i586 ~same line~ ...=sparcv9 ~same line~ ...=sparc64 All but one of these getprojpack calls hangs, that is, # strace -p 29613 read(4, ^C The srcserver logfile is usually empty: 2010-08-04 12:52:08: bs_srcserver started on port 5352 2010-08-04 12:52:12 [29613]: GET /getprojpack?withsrcmd5&withdeps&withrepos&withconfig&arch=x86_64 2010-08-04 12:52:12 [29615]: GET /getprojpack?withsrcmd5&withdeps&withrepos&withconfig&arch=sparcv9 2010-08-04 12:52:12 [29616]: GET /getprojpack?withsrcmd5&withdeps&withrepos&withconfig&arch=sparc64 2010-08-04 12:52:12 [29619]: GET /getprojpack?withsrcmd5&withdeps&withrepos&withconfig&arch=i586 reading config for Black_Ares:11.2-update/standard x86_64 reading config for Black_Ares:11.2-update/standard i586 reading config for Black_Ares:11.2-update/standard sparcv9 reading config for Black_Ares:11.3/standard sparc64 Without much traces. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

1 9

[Bug 811636] New: genisoimage -efi-boot option missing
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=811636 https://bugzilla.novell.com/show_bug.cgi?id=811636#c0 Summary: genisoimage -efi-boot option missing Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Enhancement Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: gratien.dhaese(a)it3.be QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.172 Safari/537.22 openSUSE 12.3 (and most likely previous version of openSUSE 12.*) ============= genisoimage-1.1.11-10.1.1.x86_64 genisoimage: unrecognized option '-efi-boot' Usage: genisoimage [options] -o file directory ... => -e FILE (option is missing) As a result it is not possible to create a bootable UEFI CD-ROM image. The -b option is not working for UEFI. Fedora 18 and Ubuntu 12.10 do have the -efi-boot option and booting UEFI ISO image does work on fedora 18 and ubuntu 12.10. Please upgrade the genisoimage package asap with -efi-boot option included. As a result of this Relax-and-Recover (http://www.relax-and-recover.org/) cannot create a bootable recovery ISO image on openSUSE where UEFI is active. fedora18 ======== $ rpm -q genisoimage genisoimage-1.1.11-14.fc18.x86_64 $ genisoimage -efi-boot I: -input-charset not specified, using utf-8 (detected in locale settings) genisoimage: Missing pathspec. Usage: genisoimage [options] -o file directory ... => -e FILE, -efi-boot FILE Set EFI boot image name ubuntu 12.10 ============ genisoimage 1.1.11-2ubuntu3 (Linux) # genisoimage -e genisoimage: option requires an argument -- 'e' => -e FILE, -efi-boot FILE Set EFI boot image name Reproducible: Always Steps to Reproduce: 1.genisoimage -efi-boot 2. 3. Actual Results: genisoimage: unrecognized option '-efi-boot' Usage: genisoimage [options] -o file directory ... Expected Results: $ genisoimage -efi-boot I: -input-charset not specified, using utf-8 (detected in locale settings) genisoimage: Missing pathspec. -- 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 16

[Bug 637481] New: ichain proxy: connections get stuck
by bugzilla_noreply＠novell.com 04 Feb '14

04 Feb '14

https://bugzilla.novell.com/show_bug.cgi?id=637481 https://bugzilla.novell.com/show_bug.cgi?id=637481#c0 Summary: ichain proxy: connections get stuck Classification: openSUSE Product: openSUSE.org Version: unspecified Platform: All OS/Version: Linux Status: NEW Severity: Major Priority: P5 - None Component: Infrastructure AssignedTo: mrueckert(a)novell.com ReportedBy: jengelh(a)medozas.de QAContact: lrupp(a)novell.com Found By: Beta-Customer Blocker: --- I have my own BS instance at ares.medozas.de[134.76.83.5], running schedulers for four architectures, and ~8000 package links (osc linkpac'd) to the openSUSE: namespace. When the schedulers start up, they do a /getprojpack on the local bs_srcserver, which in turn contacts api.opensuse.org due to <remoteurl>ing. This creates four connections, handled by srcserver child processes that are visible with `rcobssrcserver status`. It may take 20–25 minutes for one scheduler to do a cold start. The problem now is that the iChain proxy or any other security hardware that secretly sits between the Novell perimeter and api.opensuse.org causes _all but one_ of the connections to get stuck after 5–10 minutes. Running strace -p on one or more of the PIDs as returned by `rcobssrcserver status` sits "read(4, ", which is the socket to 195.135.221.33:443. Only one bssrc subprocess does continue scanning the projects and have constantly flowing open/read output I am aware that there is a "silent period", but it would be _at the end_ of project scanning, which I can be certain is not reached yet once it gets stuck. Since these connections are open for more than 15 minutes in general, it may not seem far fetched that it looks like a Slowloris proceeding to the proxy (but you can't really blame me for that, can you?). If this were however the case, the proxy should close the connection (scheduler will automatically retry later), not sit on it and do nothing. -- 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 7