Quantcast
Channel: CentOS Bug Tracker - Issues
Viewing all 19115 articles
Browse latest View live

0007592: Patch required to build upstream kernel for i686

$
0
0
When attempting to build kernel-3.10.0-123.6.3.el7 for i686, the builds were failing with the following error:<br /> <br /> kernel/sched/cputime.c: In function 'steal_account_process_tick':<br /> kernel/sched/cputime.c:273:3: error: implicit declaration of function 'jiffies_to_nsecs' [-Werror=implicit-function-declaration]<br /> this_rq()->prev_steal_time += cputime_to_nsecs(steal_ct);<br /> <br /> It seems that upstream (bless their hearts, as we say in Texas) backported these two patches:<br /> <br /> <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dee08a72deefac251267ed2717717596aa8b6818">https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dee08a72deefac251267ed2717717596aa8b6818</a> [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dee08a72deefac251267ed2717717596aa8b6818" target="_blank">^</a>]<br /> <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d8a9ce3f8ad2b546b9ebaf65de809da0793f11c5">https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d8a9ce3f8ad2b546b9ebaf65de809da0793f11c5</a> [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d8a9ce3f8ad2b546b9ebaf65de809da0793f11c5" target="_blank">^</a>]<br /> <br /> But they didn't backport the patch that actually implements jiffies_to_nsecs():<br /> <br /> <a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8fe8ff09ce3b5750e1f3e45a1f4a81d59c7ff1f1">https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8fe8ff09ce3b5750e1f3e45a1f4a81d59c7ff1f1</a> [<a href="https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8fe8ff09ce3b5750e1f3e45a1f4a81d59c7ff1f1" target="_blank">^</a>]<br /> <br /> With the last patch added, I am able to build kernel-3.10.0-123.6.3.el7 for i686 with "CONFIG_PARAVIRT=y".

0006828: Tracking for centosplus kernels for CentOS-7

$
0
0
Build and maintain centosplus kernels for EL7.

0007590: Default augeas installation is non-functional

$
0
0
With a default installation of augeas on centos 7 :<br /> <br /> $ augtool<br /> Failed to initialize Augeas<br /> error: Syntax error in lens definition<br /> /usr/share/augeas/lenses/dist/yum.aug:33.14-.37:Undefined variable Build.combine_three_opt<br /> /usr/share/augeas/lenses/dist/yum.aug:43.28-.35:Undefined variable entries<br /> /usr/share/augeas/lenses/dist/yum.aug:49.34-.40:Undefined variable record<br /> /usr/share/augeas/lenses/dist/yum.aug:58.22-.25:Undefined variable lns<br /> <br /> Installed packages :<br /> <br /> $ rpm -qa | grep augeas<br /> augeas-1.1.0-12.el7.x86_64<br /> python-augeas-0.4.1-5.el7.noarch<br /> augeas-libs-1.1.0-12.el7.x86_64<br /> ruby-augeas-0.5.0-1.el7.x86_64

0007526: permanent firewalld interface zone assignments not preserved across ifdown/ifup cycles

$
0
0
I originally posted this as a question to www.centos.org/forums: <a href="https://www.centos.org/forums/viewtopic.php?f=50&t=48045&sid=289e316d99bc8a55489bb0f79983222c#p204247">https://www.centos.org/forums/viewtopic.php?f=50&t=48045&sid=289e316d99bc8a55489bb0f79983222c#p204247</a> [<a href="https://www.centos.org/forums/viewtopic.php?f=50&t=48045&sid=289e316d99bc8a55489bb0f79983222c#p204247" target="_blank">^</a>]<br /> <br /> I've been trying to learn new centos 7 systemd and firewalld concepts over the past few days and came across this issue today when rebooting my server.<br /> <br /> I had previously setup firewalld to place eth0 and eth1 in the dmz and internal zones respectively w/ the following commands:<br /> <br /> sudo firewall-cmd --permanent --zone=public --remove-interface=eth1<br /> sudo firewall-cmd --permanent --zone=internal --add-interface=eth1<br /> <br /> on reboot I looked at the active zones and saw both devices were back in the public zone. after digging for a while I realized it was due to the following lines in the /etc/sysconfig/network-scripts/ifup-eth and ifup-post scripts:<br /> <br /> # Inform firewall which network zone (empty means default) this interface belongs to<br /> if [ -x /usr/bin/firewall-cmd -a "${REALDEVICE}" != "lo" ]; then<br /> /usr/bin/firewall-cmd --zone="${ZONE}" --change-interface="${DEVICE}" > /dev/null 2>&1<br /> fi<br /> <br /> so this effectively makes any "permanent" zone changes like the one I made above permanent only across firewalld restarts, but not machine restarts or interface up/down cycles.<br /> <br /> I added the ZONE setting to each device's config to fix my issue for now...<br /> <br /> but my question is, why is this done at all? the "default" ZONE value blows away the permanently set value. it seems like the script should at least check the current value of `firewall-cmd --get-zone-of-interface=eth0` and use that over ZONE?<br /> <br /> please let me know if I should report this upstream to bugzilla.redhat.com instead.

0007407: Firewalld not loading permanent rules at boot

$
0
0
When using CentOS 7, firewalld is not loading permanent rules at boot.<br /> <br /> Permanent rules have been added using firewall-cmd --permanent. I have verified the updates exist in /etc/firewalld/zones. I have also verified firewalld is enabled on boot.<br /> <br /> Upon reboot, firewalld does load. firewall-cmd --state returns "running." However, all interfaces are in the default zone.<br /> <br /> Reloading firewalld via firewall-cmd --reload loads the permanent rules as expected.

0006526: GSS api not working with MS Active Directory

$
0
0
GSS-TSIG stopped working (it worked in the past) with MS Active Directory so Windows can not register/update DNS records. This bug is very sneaky - no log in the logfile, after debugging enabled: "failed gss_inquire_cred: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Success."

0007593: rsyslog-5.8.10-8.el6.x86_64: incorrect order of command line parameters in startup of rsyslogd

$
0
0
rsyslog-5.8.10-8.el6.x86_64<br /> man rsyslogd :<br /> -c version<br /> Selects the desired backward compatibility mode. It must always <br /> be the first option on the command line, as<br /> it influences processing of the other options.<br /> <br /> /etc/init.d/rsyslog :<br /> # under 'start' section<br /> daemon --pidfile="$PIDFILE" $exec -i "$PIDFILE" $SYSLOGD_OPTIONS<br /> # and $SYSLOGD_OPTIONS is "-c 5" ( per /etc/sysconfig/rsyslog )<br /> <br /> which makes the '-c' option to be not the first option.

0007595: kernel crash during I/O after device removal

$
0
0
#0 [ffff8800578899c0] machine_kexec at ffffffff810411b1<br /> <a href="http://bugs.centos.org/view.php?id=1">0000001</a> [ffff880057889a18] crash_kexec at ffffffff810cf272<br /> <a href="http://bugs.centos.org/view.php?id=2">0000002</a> [ffff880057889ae8] oops_end at ffffffff815eabc8<br /> #3 [ffff880057889b10] die at ffffffff8101632b<br /> #4 [ffff880057889b40] do_trap at ffffffff815ea2a0<br /> #5 [ffff880057889b90] do_invalid_op at ffffffff81013134<br /> #6 [ffff880057889c40] invalid_op at ffffffff815f3ede<br /> [exception RIP: __blk_put_request+324]<br /> RIP: ffffffff81291814 RSP: ffff880057889cf0 RFLAGS: 00010006<br /> RAX: 0000000016200000 RBX: ffff8800218baf00 RCX: 00000000ffffffff<br /> RDX: ffff88000c232400 RSI: ffff8800218baf00 RDI: ffff880051858780<br /> RBP: ffff880057889d08 R8: 0000000000000246 R9: ffff88007fd97380<br /> R10: ffffea0000dd7180 R11: ffffffff811e75f0 R12: 0000000016200000<br /> R13: ffff8800518587b0 R14: ffff8800218baf00 R15: ffff88000835a078<br /> ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018<br /> <a href="http://bugs.centos.org/view.php?id=7">0000007</a> [ffff880057889d10] blk_put_request at ffffffff812918ab<br /> <a href="http://bugs.centos.org/view.php?id=8">0000008</a> [ffff880057889d38] sg_finish_rem_req at ffffffffa040d090 [sg]<br /> <a href="http://bugs.centos.org/view.php?id=9">0000009</a> [ffff880057889d60] sg_common_write at ffffffffa040ec39 [sg]<br /> <a href="http://bugs.centos.org/view.php?id=10">0000010</a> [ffff880057889e00] sg_new_write at ffffffffa040ef30 [sg]<br /> <a href="http://bugs.centos.org/view.php?id=11">0000011</a> [ffff880057889e68] sg_write at ffffffffa040f40f [sg]<br /> #12 [ffff880057889ef8] vfs_write at ffffffff811af7fd<br /> <a href="http://bugs.centos.org/view.php?id=13">0000013</a> [ffff880057889f38] sys_write at ffffffff811b0248<br /> <a href="http://bugs.centos.org/view.php?id=14">0000014</a> [ffff880057889f80] system_call_fastpath at ffffffff815f2799<br /> RIP: 00007f2ba3c721e0 RSP: 00007fff3dcafa20 RFLAGS: 00010202<br /> RAX: 0000000000000001 RBX: ffffffff815f2799 RCX: 000000000000006a<br /> RDX: 0000000000000058 RSI: 000000000355a1d4 RDI: 0000000000000004<br /> RBP: 0000000000000058 R8: 0000000000000200 R9: 0000000000000003<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000002fd2c36<br /> R13: 0000000001f2f0a0 R14: 0000000001f2f0a0 R15: 00007fff3dcafbe0<br /> ORIG_RAX: 0000000000000001 CS: 0033 SS: 002b

0007594: no creation of network bridge possible using ifcfg-files and service network

$
0
0
if you define a network bridge in e.g ifcfg-kvmbr0 script and start the the bridge interface:<br /> ifup kvmbr0 <enter><br /> you get the errormessage:<br /> "can't add kvmbr0 to bridge enp1s0: Operation not supported"<br /> <br /> after correction of the ifup-eth script with the bridge running you get a similiar errormessage:<br /> ifdown kvmbr0 <enter><br /> "can't delete kvmbr0 from enp10: Operation not supported"

0007596: systemctl start named.service does not automatically start named-chroot.service

$
0
0
In CentOS 6.x and earlier, installing bind-chroot would automatically start named in the chrooted environment when starting named normally, for example with "service named start".<br /> <br /> In CentOS 7, if you "systemctl start named.service" with bind-chroot installed, it will NOT start named-chroot.service, it will instead start named.service which runs named outside of the chrooted environment.<br /> <br /> To get named to start in the chrooted environment, you must make sure named.service is stopped, then start named-chroot.service explicitly with "systemctl start named-chroot.service".<br /> <br /> This is likely to confuse administrators who are used to the old behavior. If bind-chroot is installed, then "systemctl start named.service" should start named-chroot.service instead (possibly as a dependency?).<br /> <br /> At the very least, a startup warning should be issued with something like "bind-chroot is installed, but you started named.service rather than named-chroot.service. Did you mean to run 'systemctl start named-chroot'?", or something to that effect.

0007304: An Internal System Error has occured

$
0
0
Error Type: <class 'yum.Errors.MiscError'><br /> Error Value: xz compression not available<br /> File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3278, in <module><br /> main()<br /> File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 3275, in main<br /> backend.dispatcher(sys.argv[1:])<br /> File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 702, in dispatcher<br /> self.dispatch_command(args[0], args[1:])<br /> File : /usr/lib/python2.6/site-packages/packagekit/backend.py, line 589, in dispatch_command<br /> self.get_updates(filters)<br /> File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 2432, in get_updates<br /> self._check_init()<br /> File : /usr/share/PackageKit/helpers/yum/yumBackend.py, line 2839, in _check_init<br /> repo.repoXML<br /> File : /usr/lib/python2.6/site-packages/yum/yumRepo.py, line 1455, in <lambda><br /> repoXML = property(fget=lambda self: self._getRepoXML(),<br /> File : /usr/lib/python2.6/site-packages/yum/yumRepo.py, line 1447, in _getRepoXML<br /> self._loadRepoXML(text=self)<br /> File : /usr/lib/python2.6/site-packages/yum/yumRepo.py, line 1437, in _loadRepoXML<br /> return self._groupLoadRepoXML(text, self._mdpolicy2mdtypes())<br /> File : /usr/lib/python2.6/site-packages/yum/yumRepo.py, line 1413, in _groupLoadRepoXML<br /> self._commonRetrieveDataMD(mdtypes)<br /> File : /usr/lib/python2.6/site-packages/yum/yumRepo.py, line 1397, in _commonRetrieveDataMD<br /> local = misc.decompress(dl_local)<br /> File : /usr/lib/python2.6/site-packages/yum/misc.py, line 1086, in decompress<br /> _decompress_chunked(filename, out, ztype)<br /> File : /usr/lib/python2.6/site-packages/yum/misc.py, line 732, in _decompress_chunked<br /> raise Errors.MiscError, msg

0004100: RFE: centosplus kernel summary

$
0
0
This collects information from all centosplus kernel-related requests and serves as a log book for building an updated kernel.

0007597: Radeon driver with a Radeon R7 260X card: screen goes black during first reboot

$
0
0
I have a Asus P9X79-E-WS Motherboard , intel i7 4930K with a Asus R7260X-DC2OC-2GD5 graphics card.<br /> <br /> I had was using centos 6.5 and no issues with this Graphics card. I was upgrading to centos 7 and i even could not see the first page after the first reboot. I dual boot centos with windows 7. During installation, it is not asking where to put the boot loader and also not detecting windows 7. I have installed windows and centos to two separate disks. Centos 6.5 dual boots with no issues. <br /> <br /> During first reboot the monitor becomes black, sometimes the image comes back after 5 seconds, sometime not and I had to press reset(!).<br /> <br /> During boot a warning was shown:<br /> <br /> radeon 0000:01:00.0: Invalid ROM contents<br /> <br /> and the screen goes black. Sometimes after repeated reboot by pressing reset button it displays huge " 7 " on the screen and again goes black.

0007385: Official Centos 7 image on Amazon's EC2 Cloud

$
0
0
Hi,<br /> <br /> I hope it's ok to use this platform to request the above?<br /> <br /> Any idea on an eta for the above?<br /> <br /> Thanks<br /> <br /> Daniel

0007598: Process was Killed by signal 11 (SIGSEGV)

$
0
0
After last system update <br /> from 2 to 5 time in the twenty-four hours ABRT say:<br /> bash Process /bin/bash was Killed by signal 11 (SIGSEGV)<br /> coreutils Process /bin/cat was Killed by signal 11 (SIGSEGV)

0007599: Hibernation not working after installing Centos 7

$
0
0
Hibernation not working after fresh intallation of Centos. The kernel option "resume=/dev/sdxX" is not present. If I add by hand this option hibernation works flawlessly. Issue occurs only when installing from GnomeLive, KdeLive o livecd isos, not from DVD.iso.

0007554: mod_fcgid fails to load

$
0
0
After adding mod_fcgid, apache fails to load this module.<br /> <br /> # apachectl configtest<br /> httpd: Syntax error on line 263 of /etc/httpd/conf/httpd.conf: Cannot load modules/mod_fcgid.so into server: /etc/httpd/modules/mod_fcgid.so: undefined symbol: ap_unixd_setup_child

0007367: Anaconda doesn't add windows to grub, and destroy windows boot manager

$
0
0
I have two computers. One is a desktop, and the other is a laptop.<br /> <br /> First case:<br /> I had Linux mint grub installed on disk partition (legacy mbr), and have windows 8 bootable through UEFI. When I want to switch between Linux and Windows I choose the boot type between them. For instance, on windows, I choose UEFI. On Linux, I choose legacy booting. I do that because windows 8 deletes grub bootloader every time I update it.<br /> <br /> I installed CentOS on my laptop without using UEFI. The installer didn't detect windows 8, and it destroyed UEFI boot for windows. I was forced during the installation to create a partition of a type BIOS.<br /> <br /> <br /> Desktop case:<br /> I have windows 7, and had CentOS 6. After removing CentOS 6, and replaced it with 7, the installer didn't detect windows 7 either, and I had to do it manualy later. It was solved by following this link[1]<br /> <br /> 1-<a href="http://boringtalk.wordpress.com/2013/05/29/solving-the-problem-of-missing-windows-7-entry-in-grub2-on-fedora-18/">http://boringtalk.wordpress.com/2013/05/29/solving-the-problem-of-missing-windows-7-entry-in-grub2-on-fedora-18/</a> [<a href="http://boringtalk.wordpress.com/2013/05/29/solving-the-problem-of-missing-windows-7-entry-in-grub2-on-fedora-18/" target="_blank">^</a>]

0007600: Windows entry no present on grub menu after fresh install

$
0
0
No windows option in grub menu after fresh intallation of Centos. Issue occurs when installing from GnomeLive, KdeLive o livecd isos. I haven't tried from DVD.iso. The windows version doesn't matter (it occurs with windows 7 and 8). My system is UEFI capable, but UEFI is diabled. I'm using a MBR partition scheme.

0007601: no option to skip user creation

$
0
0
We've user accounts in ldap, only system users are local. Yet you can't get past the initial setup without creating a local user. <br /> <br /> This is an annoying regression from previous releases.
Viewing all 19115 articles
Browse latest View live




Latest Images