January 2013 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 796167] New: splitting of cryptsetup-mkinitrd broke booting systems that reside on an encrypted lvm
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=796167 https://bugzilla.novell.com/show_bug.cgi?id=796167#c0 Summary: splitting of cryptsetup-mkinitrd broke booting systems that reside on an encrypted lvm Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 1 Platform: x86-64 OS/Version: Other Status: NEW Severity: Critical Priority: P5 - None Component: Security AssignedTo: security-team(a)suse.de ReportedBy: cobexer(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20121226 Firefox/19.0 the initrd did not contain the programs necessary to do a cryptsetup luksOpen ... and thus the system was unable to access it's partitions and could not boot there were a lot of messages scrolling all over the screen for a few minutes: --- PARTIAL MODE. Incomplete logical volumes will be processed. Volume Group "system" not found ... Could not find /dev/mapper/system-root. Want me to fall back to /dev/system/root? (Y/n) --- installing cryptsetup-mkinitrd fixed the problem. why was this not installed by default??? 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 10

[Bug 781689] New: openSUSE should reuse existing EFI System Partition by default
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=781689 https://bugzilla.novell.com/show_bug.cgi?id=781689#c0 Summary: openSUSE should reuse existing EFI System Partition by default Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: arvidjaar(a)gmail.com QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0 While testing installation for https://bugzilla.novell.com/show_bug.cgi?id=781688 I noticed that default partition layout suggested by installer creates second EFI System Partition even if one already exists. While this appears to work, if you need to modify (or repair) Windows boot configuration (BCD) on such system, two system partitions make Windows quite unhappy. It completely ruined boot configuration until I hide (by changing partition type) the one created by SUSE. I think by default installer should reuse existing partition if it is already available for better compatibility with dual-boot systems. 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 20

[Bug 796588] New: No network printing on printers using CUPS 1.4.3 possible: "Unable to add document to print job."
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=796588 https://bugzilla.novell.com/show_bug.cgi?id=796588#c0 Summary: No network printing on printers using CUPS 1.4.3 possible: "Unable to add document to print job." Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: x86-64 OS/Version: openSUSE 12.2 Status: NEW Severity: Normal Priority: P5 - None Component: Printing AssignedTo: jsmeix(a)suse.com ReportedBy: bjoern.jacobs(a)gmx.net QAContact: jsmeix(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Firefox/17.0 I have a fresh installation of openSUSE 12.2 64 bit. We have several network printers which are accessible over one central cups server in version 1.4.3. I cannot print on these printers. My local cups (version 1.5.3 from standard repository) always shows me an error for the job: "Unable to add document to print job.". A colleague who uses Ubuntu told me he had the same error. The error is that the ipp backend of cups 1.5.3 is incompatible with the ipp backend of the cups server 1.4.3. In Ubuntu there was a patch which introduced a new backend called ipp14 so that by changing the connection string from ipp://.... to ipp14://... printing worked fine. See https://bugs.launchpad.net/ubuntu/+source/cups/+bug/945028/comments/56 I found no solution to this problem in openSUSE. I tried upgrading to version 1.5.4 from the Printing-repository, but the error is still there. Thanks, Björn Reproducible: Always Steps to Reproduce: 1. Have a cups print server in version 1.4.3 2. Have a computer running cups 1.5.3 3. Try to print a document on a printer 4. Go to cups web app on http://localhost:631, Jobs, see "Unable to add document to print job." Actual Results: Nothing printed Expected Results: Printer should print -- 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 798333] New: xmahjong failed to run
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=798333 https://bugzilla.novell.com/show_bug.cgi?id=798333#c0 Summary: xmahjong failed to run Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications AssignedTo: werner(a)suse.com ReportedBy: lazy.kent(a)opensuse.org QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Running xmahjong in terminal: % xmahjongg can't load tile font xmahjongg [1] 13357 exit 1 xmahjongg xmahjongg.pcf.gz is installed in /usr/share/fonts/misc/ , but... % ll xmahjongg.pcf.gz -r--r--r-- 1 root root 20 дек 18 00:53 xmahjongg.pcf.gz % gunzip xmahjongg.pcf.gz xmahjongg.pcf.gz: 0.0% -- replaced with xmahjongg.pcf % ll xmahjongg.pcf -r--r--r-- 1 kent users 0 дек 18 00:53 xmahjongg.pcf The font is empty 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 2

[Bug 769946] New: YaST2 Service::Enable[d]("foo") no longer works in case of systemd
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=769946 https://bugzilla.novell.com/show_bug.cgi?id=769946#c0 Summary: YaST2 Service::Enable[d]("foo") no longer works in case of systemd Classification: openSUSE Product: openSUSE 12.2 Version: Beta 2 Platform: All OS/Version: openSUSE 12.2 Status: NEEDINFO Severity: Normal Priority: P5 - None Component: YaST2 AssignedTo: msvec(a)suse.com ReportedBy: jsmeix(a)suse.com QAContact: jsrain(a)suse.com CC: badshah400(a)gmail.com, fcrozat(a)suse.com InfoProvider: fcrozat(a)suse.com Found By: Development Blocker: --- For the history see https://bugzilla.novell.com/show_bug.cgi?id=769346#c13 Michal Svec, I assigned this issue initially to you because according to https://github.com/yast/yast-yast2/blame/master/library/runlevel/src/Servic… you are one of those who currently work on Service.ycp. In the YaST printer module in printer/src/Printerlib.ycp I call Service::Enabled("cups") to test if the service cups is enabled to be started during boot and if it is not enabled I call Service::Enable("cups") to enable that the service cups is started during boot. It seems somehow this does not work if systemd is used. It works if SysVinit is used. As far as I see Service::Enable[d] is implemented in yast2/library/runlevel/src/Service.ycp and therein it seems it runs basically /sbin/chkconfig -l cups | /usr/bin/grep -q '[0-6]:on' When I run this on my openSUSE 12.2 beta2 test machine I get ---------------------------------------------------------------------------- # /sbin/chkconfig -l cups Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. cups 0:off 1:off 2:on 3:on 4:off 5:on 6:off # /sbin/chkconfig -l cups | /usr/bin/grep -q '[0-6]:on' \ && echo enabled || echo disabled Note: This output shows SysV services only and does not include native systemd services. SysV configuration data might be overridden by native systemd configuration. enabled ---------------------------------------------------------------------------- Nevertheless after a reboot, cupsd is not running. Some time ago crrodriguez(a)opensuse.org had added "complete systemd support" to the cups package which now provides /lib/systemd/system/cups.path /lib/systemd/system/cups.service /lib/systemd/system/cups.socket in addition to its traditional SysVinit setup via -------------------------------------------------------------------- %post %{fillup_and_insserv -ny cups cups} -------------------------------------------------------------------- in cups.spec which must stay there to be backward compatible. According to how I understand the above "Note:" in the chkconfig output it means that chkconfig is no longer the right tool for services which have a native systemd configuration. If my analysis is right, the question is must Service.ycp be adapted so that all the YaST modules which use it still work even if a service gets a native systemd configuration or must /sbin/chkconfig be adapted so that it also works even if a service gets a native systemd configuration or must all YaST modules which call Service::... functions be adapted to work even if a service gets a native systemd configuration or must something in the cups package be adapted so that it still works for both systems with SysVinit and with systemd? I do not know how to solve this because I am not a SysVinit expert and not at all a systemd expert. Frederic Crozat, could you provide uesful information how to solve this? -- 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 8

[Bug 798110] New: linuxrc segfaults with dud parameter
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=798110 https://bugzilla.novell.com/show_bug.cgi?id=798110#c0 Summary: linuxrc segfaults with dud parameter Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Installation AssignedTo: snwint(a)suse.com ReportedBy: lnussel(a)suse.com QAContact: jsrain(a)suse.com Found By: --- Blocker: --- tried to run installation with dud=http://.../some.rpm linuxrc segfaults after printing that it activates dhcp. no actual request arrives at the web server. -- 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 1

[Bug 798316] New: insserv-compat should not depend on perl
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=798316 https://bugzilla.novell.com/show_bug.cgi?id=798316#c0 Summary: insserv-compat should not depend on perl Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 1 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: lnussel(a)suse.com ReportedBy: snwint(a)suse.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- insserv-compat depends on perl (not just perl-base [via Pod::Usage]). That forces me to blow up the rescue system quite a bit. Could you reduce the dependency? -- 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 790724] New: LVM hangs in Creating logical Volume
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=790724 https://bugzilla.novell.com/show_bug.cgi?id=790724#c0 Summary: LVM hangs in Creating logical Volume Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 1 Platform: All OS/Version: SUSE Other Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: bwiedemann(a)suse.com QAContact: qa-bugs(a)suse.de CC: coolo(a)suse.com, dimstar(a)opensuse.org, fcrozat(a)suse.com Found By: System Test Blocker: --- as seen on openQA.o.o (e.g. in gnome tests) http://openqa.opensuse.org/openqa/permanent/bug/lvmcreateb.png install on LVM hangs indefinitely in Creating logical Volume last seen working 2012-11-05 first seen failing 2012-11-06 in between were updates to dbus, systemd, installation-images, aaa_base, sysconfig -- 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 798162] New: Init system doesn't wait for AutoFS to complete initialization
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=798162 https://bugzilla.novell.com/show_bug.cgi?id=798162#c0 Summary: Init system doesn't wait for AutoFS to complete initialization Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 1 Platform: All OS/Version: openSUSE 12.2 Status: ASSIGNED Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: lchiquitto(a)suse.com ReportedBy: lchiquitto(a)suse.com QAContact: qa-bugs(a)suse.de Found By: Development Blocker: --- Since we changed the systemd initialization mode of AutoFS from "forking" to "simple", the init system no longer waits for the automounter to be completely initialized before proceeding. This causes problems as this: # rcautofs restart; ls /automounted/volume redirecting to systemctl restart autofs ls: cannot access /automounted/volume: No such file or directory To properly fix the problem, we need to modify autofs to use systemd's notification features. The automounter can then notify systemd that it has finished initializing. While this is not implemented properly, I'm going to revert the changes. -- 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 798158] New: /etc/auto.master.d doesn't work when the / file system is XFS
by bugzilla_noreply＠novell.com 14 Jan '13

14 Jan '13

https://bugzilla.novell.com/show_bug.cgi?id=798158 https://bugzilla.novell.com/show_bug.cgi?id=798158#c0 Summary: /etc/auto.master.d doesn't work when the / file system is XFS Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 1 Platform: All OS/Version: openSUSE 12.2 Status: ASSIGNED Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: lchiquitto(a)suse.com ReportedBy: lchiquitto(a)suse.com QAContact: qa-bugs(a)suse.de Found By: Development Blocker: --- When /etc is on an XFS file system, dirent->d_type will always be equal to DT_UNKNOWN and all files in /etc/auto.masted.d/ will be filtered out by scandir(). -- 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