July 2013 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 800699] New: /lib/mkinitrd/scripts/boot-luks.sh uses lvm but doesn't depend on it
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

https://bugzilla.novell.com/show_bug.cgi?id=800699 https://bugzilla.novell.com/show_bug.cgi?id=800699#c0 Summary: /lib/mkinitrd/scripts/boot-luks.sh uses lvm but doesn't depend on it Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jnelson-suse(a)jamponi.net QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0 /lib/mkinitrd/scripts/boot-luks.sh uses lvm components: (these are the last lines in that file) # Encrypted volume groups mounted by label or uuid will not # get recognized otherwise (bnc#722916) case "$root" in /dev/disk/by-label/*|/dev/disk/by-uuid/*) vgscan vgchange -a y ;; esac However it doesn't *depend* on them like it should (otherwise an error is generated). I'm just guessing, but perhaps it should have: #%programs: /sbin/vgscan /sbin/vgchange /sbin/lvm like boot-lvm2.sh does? 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 6

[Bug 798510] New: insserv does not enable service
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

https://bugzilla.novell.com/show_bug.cgi?id=798510 https://bugzilla.novell.com/show_bug.cgi?id=798510#c0 Summary: insserv does not enable service 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: werner(a)suse.com ReportedBy: bwiedemann(a)suse.com QAContact: qa-bugs(a)suse.de CC: fcrozat(a)suse.com Found By: Development Blocker: --- calling insserv sshd does not call systemctl enable sshd.service likely because #define SYSTEMD_SERVICE_PATH "/lib/systemd/system" but the dir moved to /usr/lib/systemd/system for some reason -- 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 735124] New: xine dont't uses ~/.lircrc
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

https://bugzilla.novell.com/show_bug.cgi?id=735124 https://bugzilla.novell.com/show_bug.cgi?id=735124#c0 Summary: xine dont't uses ~/.lircrc Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Major Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: s.newslists(a)googlemail.com QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2 Xine should use ~/.lircrc for key bindings and this worked in Opensuse 11.4. In General my lirc configuration works. For example the entry --> begin prog = irexec remote = Technisat_USB_HID_Dongle button = STOP repeat = 0 config = /usr/bin/qdbus org.kde.kmix /kmix/KMixWindow/actions/increase_volume com.trolltech.Qt.QAction.trigger end <-- is working like expected. But the entry --> begin remote = Technisat_USB_HID_Dongle button = -/-- prog = xine repeat = 0 config = ToggleFullscreen end <-- in the same file is not working. In 11.4 it worked exactly with this entry. I also tried to create the file from scratch with xine --keymap=lirc > ~/.lircrc resulting in the same -> it does not work. Reproducible: Always Steps to Reproduce: 1. Install xine and set up lirc 2. xine --keymap=lirc > ~/.lircrc 3. Fill out an entry 4. Restart xine and lirc and try Actual Results: Does not work Expected Results: 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 666494] New: umount failures during halt or reboot
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

https://bugzilla.novell.com/show_bug.cgi?id=666494 https://bugzilla.novell.com/show_bug.cgi?id=666494#c0 Summary: umount failures during halt or reboot Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: x86-64 OS/Version: openSUSE 11.2 Status: NEW Severity: Critical Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: andihartmann(a)freenet.de QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b10pre) Gecko/20110123 Firefox/4.0b10pre SeaMonkey/2.1b2pre If the system is rebooted or halted, it is possible, that there are errors during umounting the active filesystems. The errors occure on the filesystems with the following mountpoints: /var /home I put some debugcode (lsof) to the start / stopscripts (here to /lib/cryptsetup/boot.crypto.functions) to see, why the error occures (/var and /home are crypted). This is what I found: /var-filesystem: libvirtd blocks because of access to /var/run/nscd/passwd: libvirtd 6448 user4 mem REG 253,20 217016 164197 /var/run/nscd/passwd (nscd has been already shutdown) (I'm running virsh to manage kvm vm's. I don't use the global libvirtd, but a libvirtd for each user, which runs a vm) Another problem was kblankscr (KDE 4.4.4 release 3) kblankscr 15671 user mem REG 253,20 16240640 524984 /var/tmp/kdecache-gemeinsam/kpc/kde-icon-cache.data kblankscr 15671 user mem REG 253,20 4296704 524841 /var/tmp/kdecache-gemeinsam/kpc/kde-icon-cache.index kblankscr 15671 user mem REG 253,20 39056 377083 /var/cache/fontconfig/77e41c5059666d75f92e318d4be8c21e-x86-64.cache-2 kblankscr 15671 user mem REG 253,20 22792 376997 /var/cache/fontconfig/1890317d8a3fded7854d26fdd2e67c05-x86-64.cache-2 kblankscr 15671 user mem REG 253,20 12152 376999 /var/cache/fontconfig/c952848b32a83a3db68a27ab871288f2-x86-64.cache-2 kblankscr 15671 user mem REG 253,20 377544 376889 /var/cache/fontconfig/df311e82a1a24c41a75c2c930223552e-x86-64.cache-2 kblankscr 15671 user mem REG 253,20 681416 377089 /var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-x86-64.cache-2 This problem occured during halt started on the console while a KDE-session has still been running. /home-filesystem The home-filesystem was blocked by kdesud: kdesud 13272 user1 cwd DIR 253,23 3464 44891 /raid/home/user1/Documents kdesud 13272 user1 1w REG 253,23 108554 71 /raid/home/andreas/.xsession-errors This problem also occured during halt started on the console while a KDE-session has still been running. It seems, that the kill and term-script at the beginning of the reboot / halt procedure doesn't kill the processes described above. As consequence, the filesystems can't be unmounted. This should be fixed! These are the rpm-packages which are installed: sysvinit-2.86-215.3.1.x86_64 fuse-2.7.4-3.4.1.x86_64 device-mapper-1.02.31-11.3.1.x86_64 lvm2-2.02.45-11.3.1.x86_64 cryptsetup-1.0.7-10.1.x86_64 kdebase4-runtime-4.4.4-3.7.3.x86_64 Reproducible: Always Steps to Reproduce: 1. Take care, that kblankscr, libvirtd and kdesud are running. The init-script of libvirtd is disabled, because it isn't used. 2. Do a reboot / halt on the console. Actual Results: The umount of some of the filesystems wasn't possible, because kdesud, kblancscr and libvirtd are still running and have not been killed. Expected Results: I expect that the term and kill script, which has been running before umounting the filesystem does kill all the processes which could block the umounting of the filesystems. -- 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 39

[Bug 634681] New: Intel ICH10R / 82801JIR, md raid, LVM encrypted root creates unbootable system.
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

https://bugzilla.novell.com/show_bug.cgi?id=634681 https://bugzilla.novell.com/show_bug.cgi?id=634681#c0 Summary: Intel ICH10R / 82801JIR, md raid, LVM encrypted root creates unbootable system. Classification: openSUSE Product: openSUSE 11.3 Version: Final Platform: x86-64 OS/Version: openSUSE 11.3 Status: NEW Severity: Critical Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: edward.cullen(a)hp.com QAContact: jsrain(a)novell.com Found By: --- Blocker: --- User-Agent: Opera/9.80 (X11; Linux x86_64; U; en-GB) Presto/2.6.30 Version/10.60 During setup of an HP z600 workstation, configured with RAID 0, YaST will notify the user of an 'md comptible RAID' device, asking if md should be used to manage said device. Doing so makes LVM-based partitioning with encryption unusable. Reproducible: Always Steps to Reproduce: 1. Configure RAID 0 in the ICH10R setup. 2. Begin the installation. 3. When prompted to use md to manage the RAID, select 'yes'. 4. Create a /boot partition on the MD device - /dev/mdXXXp1 5. Create an encrypted LVM partion on the MD device - /dev/mdXXXp2 6. Create an LVM volume group in the LVM partition. 7. Create a root and a swap partition in the LVM volume group. 8. Complete setup. Actual Results: On reboot, MD will be started. There will then be repeated errors about being unable to find the LVM volume group, followed by the boot.crypto / LUKS unlock partition prompt. It will NOT be possible to unlock the partition, making booting the system impossible. Expected Results: LUKS prompts for password to unlock the partition and the system boots correctly. This issue is particularly vexing, as YaST itself is able to correctly detect, unlock and mount the partition setup! (E.g. if one re-runs the installation). Having done some poking around, I believe the issue is with the order of init scripts. boot.crypto-early starts before md and LVM. boot.crypto starts after md and LVM. There are two solutions that I believe are viable: 1. If md RAID is used, do NOT allow encrypted LVM partitions. 2. Modify boot.* scripts to reflect the order used by YaST during installation. Clearly, option 2 would be the better solution. This would require the following order of startup: 1. start md 2. unlock LVM partitions 3. start LVM partitions 4. unlock remaining partitions On thinking about this problem, I do not see it as unreasonable for the following reasons: 1. It is the way YaST works during setup. 2. md can be seen as a low-level (hardware) device, whereas LUKS/LVM/DM are software devices; one generally initialises hardware before software. 3. YaST creates a tree showing the volume hierarchy, so working out exactly in which order partitions need to be setup should be trivial (creating the tree is the hard part...) Marked as critical because: 1. Allows creation of a configuration that will always fail. 2. Potential to break a working system. -- 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 542539] New: xsane-0.997-1.5: memory leak
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

http://bugzilla.novell.com/show_bug.cgi?id=542539 Summary: xsane-0.997-1.5: memory leak Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: All OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: dcb314(a)hotmail.com QAContact: qa(a)suse.de Found By: --- I just had a look at factory package xsane-0.997-1.5 For source code file xsane-0.997/src/xsane-batch-scan.c around line 691, function xsane_batch_scan_create_list_entry, is the source code data = calloc(size, size); but I fail to find any matching call to free. Further, I find that the local variable "data" is essentially unused in the routine. Suggest delete local variable "data" to remove useless memory leak. -- 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 5

[Bug 515041] New: lirc-0.8.5-1.3:array index out of range
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

http://bugzilla.novell.com/show_bug.cgi?id=515041 Summary: lirc-0.8.5-1.3:array index out of range Classification: openSUSE Product: openSUSE 11.2 Version: Factory Platform: All OS/Version: openSUSE 11.1 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: dcb314(a)hotmail.com QAContact: qa(a)suse.de Found By: --- I just had a look at factory package lirc-0.8.5-1.3 In file lirc-0.8.5/daemons/hw_commandir.c around line 834, is the source code for(i=0;i<MAX_CHANNELS;i++) { next_signalq_per_channel[i] = -1; channels_en[i] = 0xff; but static char channels_en[MAX_DEVICES]; and lirc-0.8.5/daemons/hw_commandir.h:#define MAX_DEVICES 4 lirc-0.8.5/daemons/hw_commandir.h:#define MAX_CHANNELS 16 This looks like broken code because the array channels_en only has four entries, but 16 are written into it. Suggest code rework. -- 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 3

[Bug 805426] New: cryptsetup cannot remove LUKS keys for devices with a blocksize of 4096 bytes
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

https://bugzilla.novell.com/show_bug.cgi?id=805426 https://bugzilla.novell.com/show_bug.cgi?id=805426#c0 Summary: cryptsetup cannot remove LUKS keys for devices with a blocksize of 4096 bytes Classification: openSUSE Product: openSUSE 12.2 Version: Final Platform: All OS/Version: openSUSE 12.2 Status: NEW Severity: Major Priority: P5 - None Component: Security AssignedTo: security-team(a)suse.de ReportedBy: f+novell(a)congenio.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 I cannot remove (luksRemoveKey) or wipe (luksKillSlot) a LUKS key slot on a disk with a blocksize of 4096 bytes. I get errors like: #cryptsetup luksKillSlot /dev/volume/anything 1 Enter any remaining LUKS passphrase: Cannot wipe device /dev/volume/anything. This works when a device with a blocksize of 512 bytes is used. I think that this is major because it affects security: a known-to-be-compromised LUKS passphrase cannot be removed. Reproducible: Always Steps to Reproduce: 1. cryptsetup luksKillSlot /dev/volume/anything 1 2. enter any existing passphrase 3. Actual Results: Cannot wipe device /dev/volume/anything. Expected Results: Removed key This happens to be a fixed upstream error that has been reported and allegedly fixed already (cf. http://code.google.com/p/cryptsetup/issues/detail?id=129) However, even a cryptsetup 1.5.1 from openSUSE factory exhibits the same behaviour. -- 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 813863] New: boot-luks.sh never reuses LUKS passwords if plymouth is active
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

https://bugzilla.novell.com/show_bug.cgi?id=813863 https://bugzilla.novell.com/show_bug.cgi?id=813863#c0 Summary: boot-luks.sh never reuses LUKS passwords if plymouth is active Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader AssignedTo: jsrain(a)suse.com ReportedBy: arvidjaar(a)gmail.com QAContact: jsrain(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 If several encrypted containers are required for root, boot-luks.sh will ask password for every of them and one more time to round it off :) Fix follows. 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 15

[Bug 810104] New: boot_luks.sh does not reuse LUKS passphrase with plymouth
by bugzilla_noreply＠novell.com 05 Jul '13

05 Jul '13

https://bugzilla.novell.com/show_bug.cgi?id=810104 https://bugzilla.novell.com/show_bug.cgi?id=810104#c0 Summary: boot_luks.sh does not reuse LUKS passphrase with plymouth Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: t.zell(a)gmx.de QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 Firefox/19.0 boot_luks.sh does not reuse the LUKS passphrase for multiple devices even though this feature is (partially) implemented. Even worse, for n devices I have to enter the passphrase n+1 times. I've attached a suggested fix. Reproducible: Always Steps to Reproduce: 1. Pass several devices in the boot parameter "luks" 2. Boot 3. Wait for passphrase prompt -- 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