August 2014 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 882205] New: cobbler does not honor pxe_just_once:1 settings
by bugzilla_noreply＠novell.com 13 May '16

13 May '16

https://bugzilla.novell.com/show_bug.cgi?id=882205 https://bugzilla.novell.com/show_bug.cgi?id=882205#c0 Summary: cobbler does not honor pxe_just_once:1 settings Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: i686 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: s91066(a)yahoo.gr QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=594159) --> (http://bugzilla.novell.com/attachment.cgi?id=594159) Default Kickstart file. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0 I have the following setup: openSUSE 12.3 as a Cobbler server with cobbler 2.2.2 installed from openSUSE repos. - I have included official Red Hat 6.5 ISO as a distro. - Server has no firewall - Cobbler setup is completed and DHCP/TFTP are handled by cobbler - Target machines are VirtualBox VMs machines in a Windows 7 Host. Installation of Red Hat in a target machine is completed succesfuly, with the following problem: The Target Machine is PXE booting regardless of the pxe_just_once:1 setting in the /etc/cobbler/settings file. Reproducible: Always Steps to Reproduce: 1. Install cobbler from official repos. 2. Setup cobbler as with the uploaded setup 3. Add a new distro and configure it as described. 4. Kickstart a new server Actual Results: After reboot, the server boots from PXE, instead of local HDD. Expected Results: After reboot, the server should boot from the local HDD. cobbler distro report RHEL-6.5-x86_64 Name : RHEL-6.5-x86_64 Architecture : x86_64 TFTP Boot Files : {} Breed : redhat Comment : rhel6.5 Fetchable Files : {} Initrd : /srv/www/cobbler/ks_mirror/RHEL-6.5-x86_64/images/pxeboot/initrd.img Kernel : /srv/www/cobbler/ks_mirror/RHEL-6.5-x86_64/images/pxeboot/vmlinuz Kernel Options : {} Kernel Options (Post Install) : {} Kickstart Metadata : {'tree': 'http://@@http_server@@/cblr/links/RHEL-6.5-x86_64'} Management Classes : [] OS Version : rhel6 Owners : ['admin'] Red Hat Management Key : <<inherit>> Red Hat Management Server : <<inherit>> Template Files : {} ============================================================================= cobbler profile report RHEL-6.5-x86_64 Name : RHEL-6.5-x86_64 TFTP Boot Files : {} Comment : DHCP Tag : default Distribution : RHEL-6.5-x86_64 Enable PXE Menu? : 1 Fetchable Files : {} Kernel Options : {} Kernel Options (Post Install) : {} Kickstart : /var/lib/cobbler/kickstarts/sample.ks Kickstart Metadata : {} Management Classes : [] Management Parameters : <<inherit>> Name Servers : [] Name Servers Search Path : [] Owners : ['admin'] Parent Profile : Proxy : Red Hat Management Key : <<inherit>> Red Hat Management Server : <<inherit>> Repos : [] Server Override : <<inherit>> Template Files : {} Virt Auto Boot : 1 Virt Bridge : xenbr0 Virt CPUs : 1 Virt Disk Driver Type : raw Virt File Size(GB) : 5 Virt Path : Virt RAM (MB) : 512 Virt Type : qemu =========================================================================== cobbler system report --name=test Name : test TFTP Boot Files : {} Comment : Fetchable Files : {} Gateway : 192.168.0.254 Hostname : testcob1.home Image : IPv6 Autoconfiguration : False IPv6 Default Device : Kernel Options : {} Kernel Options (Post Install) : {} Kickstart : <<inherit>> Kickstart Metadata : {} LDAP Enabled : False LDAP Management Type : authconfig Management Classes : [] Management Parameters : <<inherit>> Monit Enabled : False Name Servers : ['192.168.0.254', '8.8.8.8'] Name Servers Search Path : [] Netboot Enabled : False Owners : ['admin'] Power Management Address : Power ID : Power Password : Power Management Type : ipmitool Power Username : Profile : RHEL-6.5-x86_64 Proxy : <<inherit>> Red Hat Management Key : <<inherit>> Red Hat Management Server : <<inherit>> Repos Enabled : False Server Override : <<inherit>> Status : testing Template Files : {} Virt Auto Boot : <<inherit>> Virt CPUs : <<inherit>> Virt Disk Driver Type : <<inherit>> Virt File Size(GB) : <<inherit>> Virt Path : <<inherit>> Virt RAM (MB) : <<inherit>> Virt Type : <<inherit>> Interface ===== : eth0 Bonding Opts : Bridge Opts : DHCP Tag : DNS Name : Master Interface : Interface Type : IP Address : 192.168.0.200 IPv6 Address : IPv6 Default Gateway : IPv6 MTU : IPv6 Secondaries : [] IPv6 Static Routes : [] MAC Address : Management Interface : True MTU : Subnet Mask : 255.255.255.0 Static : True Static Routes : [] Virt Bridge : -- 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 828693] New: Zarafa-spooler does not work when started by systemd
by bugzilla_noreply＠novell.com 03 May '16

03 May '16

https://bugzilla.novell.com/show_bug.cgi?id=828693 https://bugzilla.novell.com/show_bug.cgi?id=828693#c0 Summary: Zarafa-spooler does not work when started by systemd Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: ian.hodge(a)verrinus-consulting.ltd.uk QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=547291) --> (http://bugzilla.novell.com/attachment.cgi?id=547291) Output of strace User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; NET4.0C; .NET4.0E) When systemd is used to start zarafa-spooler the process starts but does not pickup and deliver any message from zarafa-server. If the spooler is started on the command line it works correctly. If systemd is replaced by sysvinit as the boot mechanism, the spooler also works correctly. This is true on openSUSE 12.1, 12.2 and 12.3 with zarafa 7.0.x and zarafa 7.1.x from the opensuse repository. I'm assuming this is a problem to do with the very limited execution environment systemd passes on to process it starts and that there is something special that the zarafa-spooler needs that isn't being provided by systemd. Note that all zarafa processes are still using /etc/init.d scripts rather than unit files. As it stands my mailserver does not survive a reboot as it needs manual intervention to get it to deliver mail. Reproducible: Always Steps to Reproduce: 1. # systemctl start zarafa-spooler.service 2. send an email from within zarafa 3. Actual Results: The mail will sit in outbox forever and not be delivered. Expected Results: Zarafa-spooler will pick up the mail and deliver it to the local MTA (postfix) for delivery. If the spooler is stopped and started on the command line ie. # systemctl stop zarafa-spooler.service # /usr/sbin/zarafa-spooler The mail is immediately picked up from the outbox and delivered. -- 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 692440] New: OpenVPN should have a sysconfig entry to pick which VPN configurations are enabled
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=692440 https://bugzilla.novell.com/show_bug.cgi?id=692440#c0 Summary: OpenVPN should have a sysconfig entry to pick which VPN configurations are enabled Classification: openSUSE Product: openSUSE 11.4 Version: Final Platform: Other OS/Version: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Network AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jmatejek(a)novell.com QAContact: qa(a)suse.de Found By: --- Blocker: --- in Debian/Ubuntu, it is possible to configure OpenVPN service to only start some of the available .confs in /etc/openvpn. This is useful when you have more than one openvpn config, such as home and work VPNs and you don't want to use them simultaneously. Also, their init script takes an optional argument that specifies name of the conf to start/stop openSUSE starts all OpenVPN confs automatically and you cannot choose which ones to use. It would be nice to have this feature. -- 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 14

[Bug 864302] New: GNU tar rpm cannot dealt with large uid_t
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=864302 https://bugzilla.novell.com/show_bug.cgi?id=864302#c0 Summary: GNU tar rpm cannot dealt with large uid_t Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: All OS/Version: openSUSE 13.1 Status: NEW Severity: Major Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: external.martin.konold(a)de.bosch.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36 SUSE/31.0.1650.63 Name : tar Version : 1.26 Release : 19.1.2 Cannot deal with large uid_t. Reason: Default format got changed from GNU to POSIX. Problem: In contrast to what the GNU tar documentation claims --format=posix cannot deal with large uids. Reproducible: Always Steps to Reproduce: 1. create directory hierarchy testdir/ with large uidnumber e.g. 20000001. 2. tar cvf deleteme.tar testdir/ 3. echo $? will give a 2. Actual Results: $? is 2 Expected Results: $? should be 0. tar cvf --format=gnu gives the expected result. This is a regression from older versions of OpenSuSE which used to have --format=gnu as a default format. E.g. OpenSuSE 11.3: km82rt@rt-z9854:~> tar --version tar (GNU tar) 1.23 km82rt@rt-z9854:~> tar –help | tail -5 *Dieses* „tar“ hat als Voreinstellung: --format=gnu -f- -b20 --quoting-style=escape --rmt-command=/usr/libexec/rmt --rsh-command=/usr/bin/rsh OpenSuSE 13.1: km82rt@rt-ccs7560:tmp> tar --version tar (GNU tar) 1.26 km82rt@rt-ccs7560:tmp> tar --help | tail -5 *This* tar defaults to: --format=posix -f- -b20 --quoting-style=escape --rmt-command=/usr/lib/rmt --rsh-command=/usr/bin/rsh The misleading documentation is available from http://www.gnu.org/software/tar/manual/html_section/Formats.html Format | UID File Size File Name Devn -------+----------------------------------------- gnu | 1.8e19 Unlimited Unlimited 63 oldgnu | 1.8e19 Unlimited Unlimited 63 v7 | 2097151 8GB 99 n/a ustar | 2097151 8GB 256 21 posix | Unlimited Unlimited Unlimited Unlimited Workaround: Go back to +export DEFAULT_ARCHIVE_FORMAT="GNU" -export DEFAULT_ARCHIVE_FORMAT="POSIX" in tar.spec and recreate the tar RPM. The current bug breaks many existing shell scripts which evaluate the exit code of tar. The bug is often triggered in setups using idmap_rid. For obvious reasons there is no way in large installation to change the uid to values which accomodate the buggy tar implementation. -- 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 14

[Bug 823292] New: Man page for sudo does not match version supplied
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=823292 https://bugzilla.novell.com/show_bug.cgi?id=823292#c0 Summary: Man page for sudo does not match version supplied Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: Documentation AssignedTo: ke(a)suse.com ReportedBy: michael(a)aperantos.com QAContact: ke(a)suse.com Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.29.13 (KHTML, like Gecko) Version/6.0.4 Safari/536.29.13 I normally use 'sudo -E -s' to gain a root shell retaining my user account's home directory as $HOME. As openSUSE sets the 'always_set_home' option in /etc/sudoers I had turned this off, but despite this it would set the home directory to the target user. After asking about this on the community forum ( https://forums.opensuse.org/english/get-technical-help-here/install-boot-lo… ) I discovered that the version of sudo provided with openSUSE is compiled with the set_home option enabled. Turning this option off in /etc/sudoers resulted in the expected behaviour. The man page provided in the default openSUSE installation states for set_home that "This flag is off by default." This is wrong and made it impossible to discover the cause of the unexpected behaviour. Ideally I do not think the program should be compiled in a non-standard way, especially when the default configuration of the /etc/sudoers file includes a stronger setting so it would only apply to those who customize their configuration. But as there will have been a decision made to make it this way, the documentation needs to be updated to reflect this difference. Reproducible: Always Steps to Reproduce: man sudo Actual Results: This flag is off by default. Expected Results: This flag is on by default. -- 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 13

[Bug 700229] New: telnet crashes glibc when using "-b" parameter
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=700229 https://bugzilla.novell.com/show_bug.cgi?id=700229#c0 Summary: telnet crashes glibc when using "-b" parameter Classification: openSUSE Product: openSUSE 11.4 Version: Factory Platform: x86-64 OS/Version: openSUSE 11.4 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: novell-web(a)zmi.at QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 I wanted telnet to source from another IP, using "-b" parameter: # telnet -b eth1 10.10.10.10 Trying 10.10.10.10... telnet: eth1: Name or service not known: Success Speicherzugriffsfehler I tried that twice, then looked into dmesg: [60254.321495] telnet[28275] general protection ip:7f733a452a63 sp:7fff6839fbe0 error:0 in libc-2.11.3.so[7f733a393000+164000] [60350.030095] telnet[29348] general protection ip:7f7169480a63 sp:7fff37e01070 error:0 in libc-2.11.3.so[7f71693c1000+164000] This is on openSUSE 11.4, but I first discovered it in 11.2, where it puts more details on the screen: # telnet -b eth0:1 10.127.128.5 25 Trying 10.127.128.5... telnet: eth0:1: Name or service not known: Success *** glibc detected *** telnet: munmap_chunk(): invalid pointer: 0x00007fff0a06ace8 *** ======= Backtrace: ========= /lib64/libc.so.6[0x7f825d605d06] /lib64/libc.so.6(freeaddrinfo+0x20)[0x7f825d64d510] telnet[0x7f825dd61939] telnet(main+0x34f)[0x7f825dd5a1ff] /lib64/libc.so.6(__libc_start_main+0xfd)[0x7f825d5b1a7d] telnet[0x7f825dd59d59] ======= Memory map: ======== 7f825cf6b000-7f825cf81000 r-xp 00000000 ca:01 16518 /lib64/libgcc_s.so.1 7f825cf81000-7f825d180000 ---p 00016000 ca:01 16518 /lib64/libgcc_s.so.1 7f825d180000-7f825d181000 r--p 00015000 ca:01 16518 /lib64/libgcc_s.so.1 7f825d181000-7f825d182000 rw-p 00016000 ca:01 16518 /lib64/libgcc_s.so.1 7f825d182000-7f825d18d000 r-xp 00000000 ca:01 3184 /lib64/libnss_files-2.10.1.so 7f825d18d000-7f825d38d000 ---p 0000b000 ca:01 3184 /lib64/libnss_files-2.10.1.so 7f825d38d000-7f825d38e000 r--p 0000b000 ca:01 3184 /lib64/libnss_files-2.10.1.so 7f825d38e000-7f825d38f000 rw-p 0000c000 ca:01 3184 /lib64/libnss_files-2.10.1.so 7f825d38f000-7f825d391000 r-xp 00000000 ca:01 17973 /lib64/libdl-2.10.1.so 7f825d391000-7f825d591000 ---p 00002000 ca:01 17973 /lib64/libdl-2.10.1.so 7f825d591000-7f825d592000 r--p 00002000 ca:01 17973 /lib64/libdl-2.10.1.so 7f825d592000-7f825d593000 rw-p 00003000 ca:01 17973 /lib64/libdl-2.10.1.so 7f825d593000-7f825d6e4000 r-xp 00000000 ca:01 3936 /lib64/libc-2.10.1.so 7f825d6e4000-7f825d8e4000 ---p 00151000 ca:01 3936 /lib64/libc-2.10.1.so 7f825d8e4000-7f825d8e8000 r--p 00151000 ca:01 3936 /lib64/libc-2.10.1.so 7f825d8e8000-7f825d8e9000 rw-p 00155000 ca:01 3936 /lib64/libc-2.10.1.so 7f825d8e9000-7f825d8ee000 rw-p 00000000 00:00 0 7f825d8ee000-7f825d92c000 r-xp 00000000 ca:01 3177 /lib64/libncurses.so.5.6 7f825d92c000-7f825db2b000 ---p 0003e000 ca:01 3177 /lib64/libncurses.so.5.6 7f825db2b000-7f825db2f000 r--p 0003d000 ca:01 3177 /lib64/libncurses.so.5.6 7f825db2f000-7f825db35000 rw-p 00041000 ca:01 3177 /lib64/libncurses.so.5.6 7f825db35000-7f825db53000 r-xp 00000000 ca:01 4324 /lib64/ld-2.10.1.so 7f825dd26000-7f825dd28000 rw-p 00000000 00:00 0 7f825dd4f000-7f825dd52000 rw-p 00000000 00:00 0 7f825dd52000-7f825dd53000 r--p 0001d000 ca:01 4324 /lib64/ld-2.10.1.so 7f825dd53000-7f825dd54000 rw-p 0001e000 ca:01 4324 /lib64/ld-2.10.1.so 7f825dd54000-7f825dd6a000 r-xp 00000000 ca:01 9058 /usr/bin/telnet 7f825df6a000-7f825df6b000 r--p 00016000 ca:01 9058 /usr/bin/telnet 7f825df6b000-7f825df6d000 rw-p 00017000 ca:01 9058 /usr/bin/telnet 7f825df6d000-7f825df9b000 rw-p 00000000 00:00 0 [heap] 7fff0a058000-7fff0a06d000 rw-p 00000000 00:00 0 [stack] 7fff0a098000-7fff0a099000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Abgebrochen Seems this bug dates a while back. While 11.2 is not in bugfix phase anymore, 11.3 and 11.4 should be fixed, please. Reproducible: Always Steps to Reproduce: 1. use "telnet -b eth0 <IP address>" Actual Results: crash in glibc 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 34

[Bug 823610] New: Recommended packages ignored when Installing from osb, works with manual download
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=823610 https://bugzilla.novell.com/show_bug.cgi?id=823610#c0 Summary: Recommended packages ignored when Installing from osb, works with manual download Classification: openSUSE Product: openSUSE 12.3 Version: Final Platform: x86-64 OS/Version: openSUSE 12.3 Status: NEW Severity: Normal Priority: P5 - None Component: libzypp AssignedTo: zypp-maintainers(a)forge.provo.novell.com ReportedBy: schubert.seb(a)gmail.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created an attachment (id=543062) --> (http://bugzilla.novell.com/attachment.cgi?id=543062) zypper.log when using repository User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.32 (KHTML, like Gecko) Chrome/27.0.1425.0 Safari/537.32 SUSE/27.0.1425.0 I want to install the package flac2all: https://build.opensuse.org/package/show?package=flac2all&project=home%3Aseb… which is only available in this very repository (my obs home repository). I thus added the home repository to my local list of repositories (see below for list of activated repositories). Installing from the repository does not take into account the recommended and suggested packages. Reproducible: Always Steps to Reproduce: 1. add home:sebschub repository 2. # zypper in flac2all Actual Results: Output of zypper (zypper.log as zypper.log_obs attached), nothing is said about recommended or suggested packages: Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW packages are going to be installed: flac flac2all 2 new packages to install. Overall download size: 554.1 KiB. After the operation, additional 1.6 MiB will be used. Expected Results: The expected results can be achieved by _manually_ downloading the rpm and installing it (zypper.log as zypper.log_manual attached): # zypper in /home/schubert/Downloads/flac2all-3.28-2.1.noarch.rpm Loading repository data... Reading installed packages... Resolving package dependencies... The following NEW packages are going to be installed: flac flac2all The following package is recommended, but will not be installed because it's unwanted (was manually removed before): vorbis-tools The following packages are suggested, but will not be installed: lame nero-aac 2 new packages to install. Overall download size: 554.1 KiB. After the operation, additional 1.6 MiB will be used. -- 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 4

[Bug 799644] New: Warning during installation over ssh (perl-bootloader)
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=799644 https://bugzilla.novell.com/show_bug.cgi?id=799644#c0 Summary: Warning during installation over ssh (perl-bootloader) Classification: openSUSE Product: openSUSE Factory Version: 12.3 Milestone 2 Platform: x86-64 OS/Version: Other Status: NEW Severity: Minor Priority: P5 - None Component: Installation AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: mpluskal(a)suse.com QAContact: jsrain(a)suse.com Found By: --- Blocker: --- What: 1) Start installation over ssh (usessh=1) on x86_64 uefi machine 2) Log via ssh 3) Following warning appears: *** Starting YaST2 *** Use of uninitialized value $r in substitution (s///) at /usr/lib/perl5/vendor_perl/5.16.2/Bootloader/Library.pm line 136 (#1) (W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a "" or a 0, but maybe it was a mistake. To suppress this warning assign a defined value to your variables. To help you figure out what was undefined, perl will try to tell you the name of the variable (if any) that was undefined. In some cases it cannot do this, so it also tells you what operation you used the undefined value in. Note, however, that perl optimizes your program anid the operation displayed in the warning may not necessarily appear literally in your program. For example, "that $foo" is usually optimized into "that " . $foo, and the warning will refer to the concatenation (.) operator, even though there is no . in your program. Perl-Bootloader: 2013-01-21 15:19:17 <3> yast-5562.1 Core::RunCommand.1642: Error: Command '/usr/sbin/grub2-efi-set-default '0' >/var/log/YaST2/y2log_bootloader 2>&1' failed with code 32512 and output: sh: /usr/sbin/grub2-efi-set-default: No such file or directory -- 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 9

[Bug 866010] New: df does not show all mounts
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

https://bugzilla.novell.com/show_bug.cgi?id=866010 https://bugzilla.novell.com/show_bug.cgi?id=866010#c0 Summary: df does not show all mounts Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: michael.kohnen(a)bayer.com QAContact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0 in /etc/fstab I have the local and network filesystems: /dev/disk/by-id/ata-ST1000DM003-1CH162_S1DBE6SN-part1 / ext4 acl,user_xattr 1 1 /dev/disk/by-id/ata-ST1000DM003-1CH162_S1DBE6SN-part2 swap swap defaults 0 0 /dev/disk/by-id/ata-ST1000DM003-1CH162_S1DBE6SN-part3 /local_data ext4 acl,user_xattr 1 2 10.248.18.151:/home /storage/home nfs rw,tcp,rsize=32768,wsize=32768,nfsvers=3,hard,bg,intr,suid 0 0 10.248.18.151:/prg /usr/prg nfs rw,tcp,rsize=32768,wsize=32768,nfsvers=3,hard,bg,intr,suid 0 0 10.248.18.151:/Databases /storage/Databases nfs rw,tcp,rsize=32768,wsize=32768,nfsvers=3,hard,bg,intr,suid 0 0 'mount' shows that the nfs-filesystems are mounted: .. 10.248.18.151:/prg on /usr/prg type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,nolock,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.248.18.151,mountvers=3,mountport=836,mountproto=tcp,local_lock=all,addr=10.248.18.151) rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime) 10.248.18.151:/home on /storage/home type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.248.18.151,mountvers=3,mountport=836,mountproto=tcp,local_lock=none,addr=10.248.18.151) 10.248.18.151:/Databases on /storage/Databases type nfs (rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=10.248.18.151,mountvers=3,mountport=836,mountproto=tcp,local_lock=none,addr=10.248.18.151) none on /var/lib/ntp/proc type proc (ro,nosuid,nodev,relatime) but 'df' does not show all mounts: Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf /dev/sda1 51473020 6294584 42540716 13% / devtmpfs 8188172 32 8188140 1% /dev tmpfs 8208660 0 8208660 0% /dev/shm tmpfs 8208660 6140 8202520 1% /run tmpfs 8208660 0 8208660 0% /sys/fs/cgroup tmpfs 8208660 6140 8202520 1% /var/lock tmpfs 8208660 6140 8202520 1% /var/run /dev/sda3 884926788 73796 839878196 1% /local_data 10.248.18.151:/prg 1074218752 408591424 665627328 39% /usr/prg 10.248.18.151:/home 512000 1024 510976 1% /storage/home in this case "/storage/Databases" is missing The filesystem itself is accessible. 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 12

[Bug 601779] New: 32bit 'tree' doesn't show files 2GB and larger
by bugzilla_noreply＠novell.com 28 Apr '16

28 Apr '16

http://bugzilla.novell.com/show_bug.cgi?id=601779 http://bugzilla.novell.com/show_bug.cgi?id=601779#c0 Summary: 32bit 'tree' doesn't show files 2GB and larger Classification: openSUSE Product: openSUSE 11.2 Version: Final Platform: x86 OS/Version: openSUSE 11.2 Status: NEW Severity: Normal Priority: P5 - None Component: Other AssignedTo: bnc-team-screening(a)forge.provo.novell.com ReportedBy: jc(a)ymmv.dk QAContact: qa(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100317 SUSE/3.5.9-0.1.1 Firefox/3.5.9 Hi On 32bit systems the 'tree' command dosn't show 'large' files. I have tested on a 64bit system as well, and the problem is only present on 32bit systems. I have done a fair amount of research, comparing compile-time arguments with those of 32bit Debian packages. In the end I think it comes down to the 'spec' file: In tree.spec the 'make' command is: %build make CFLAGS="$RPM_OPT_FLAGS" -which overrides the CFLAGS set in the Makefile: CFLAGS=-O2 -Wall -fomit-frame-pointer -DLINUX -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -which results in the binary being built with these flags instead: RPM_OPT_FLAGS="-O2 -g -m32 -march=i586 -mtune=i686 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables" Now; If I change the spec file so that; %build make -then the compiler gets the flags as set in the Makefile, and the resulting binary works with files larger than 2G. I'm guessing that it's desirable to get $RPM_OPT_FLAGS passed to the compiler, but I'm unsure as to how one would 'merge' this variable with $CFLAGS from the Makefile? As for the severity of the bug: It doesn't break the system, but the functionality of the command is seriously hampered by this. It seems reasonable (to me) that it's a packaging bug, and therefore it should be easily fixed. I have confirmation from the opensuse(a)opensuse.org list that the bug is present on 11.0, so it seems to be an 'old' problem... Kind Regards, Jon Clausen Reproducible: Always Steps to Reproduce: 1. get or create a file larger than 2GB I used 'dd' to create two files - one 2GB, one 1KB smaller: dd if=/dev/zero of=2G bs=1k count=2097152 dd if=/dev/zero of=2G-1k bs=1k count=2097151 2. use 'tree /path/to/large/file' 3. observe output Actual Results: output from 32bit system: jon@nx8220:~> ll tmp/largefiles/ total 4194304 -rw-r--r-- 1 jon users 2147483648 2010-04-30 12:50 2G -rw-r--r-- 1 jon users 2147482624 2010-04-30 12:52 2G-1k jon@nx8220:~> tree tmp/largefiles/ tmp/largefiles/ `-- 2G-1k 0 directories, 1 file Expected Results: output from 64bit system: jon@cnu8092slm:~> ll tmp/largefiles/ total 4194304 -rw-r--r-- 1 jon users 2147483648 2010-04-30 12:58 2G -rw-r--r-- 1 jon users 2147482624 2010-04-30 12:58 2G-1k jon@cnu8092slm:~> tree tmp/largefiles/ tmp/largefiles/ |-- 2G `-- 2G-1k 0 directories, 2 files AFAICT the flag that makes the difference is -D_FILE_OFFSET_BITS=64 - which makes the binary use *stat64() rather than *stat() when files are 'large'. On 64bit systems I suppose everything uses *stat64() anyways, which is why the problem only surfaces on 32bit systems... ? -- 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 17