Re: [CentOS] Hardware raid LSI Megaraid not working since Centos 6.6
Thank you for your help. Le 05/01/2015 19:10, John R Pierce a écrit : works here fine on the 9261, which is an OEM version of the same card with the connectors in a different orientation... you might check your LSI firmware revision. My firmware seems to be more up to date. Anyway, I will try to update firmware. I have to check how to do that. # dmesg |grep LSI scsi4 : LSI SAS based MegaRAID driver scsi 4:2:0:0: Direct-Access LSI MR9260-4i2.13 PQ: 0 ANSI: 5 # /opt/MegaRAID/MegaCli/MegaCli64 -ShowSummary -aAll System Operating System: Linux version 2.6.32-431.29.2.el6.x86_64 Driver Version: 06.700.06.00-rh1 CLI Version: 8.07.14 Hardware Controller ProductName : LSI MegaRAID SAS 9260-4i(Bus 0, Dev 0) SAS Address : 500605b008a30fc0 FW Package Version: 12.14.0-0167 Status: Optimal BBU BBU Type : iBBU Status: Healthy Enclosure Product Id: SGPIO Type : SGPIO Status: OK . . . -- Philippe BOURDEU d'AGUERRE AIME - Campus de l'INSA http://www.aime-toulouse.fr/ 135 av. de Rangueil Tél +33 561 559 885 31077 TOULOUSE Cedex 4 - FRANCE Fax +33 561 559 870 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] CentOS 6 Xen 4.4.1 packages available on virt6-testing / libvirt blktap2 problems
On Tue, Jan 06, 2015 at 12:15:25AM +0200, Pasi Kärkkäinen wrote: On Tue, Dec 16, 2014 at 10:29:53PM +0200, Pasi Kärkkäinen wrote: * xend is now disabled by default. You can enable it by running chkconfig. xend has been removed from the tree entirely in Xen 4.5, so this should (hopefully) serve as a wake-up-call for people to begin the transition over to xend. * A lot have things have changed -- please to test this so we can get a good idea what may have broken. I'll test soon. Thanks a lot! Ok I just used a couple of hours testing Xen 4.4.1 rpms on CentOS 6.6 with Linux 3.10 dom0 kernel. This session was all about xm/xend testing. I manually enabled xend first. What Works OK: - Manually creating/managing guests with xm and domU cfgfiles in /etc/xen and LVM volumes as storage (phy backend). - Manually creating/managing guests with xm and domU cfgfiles in /etc/xen and file images as storage (tap2:aio backend). - Using virt-install to install PV domUs using LVM volumes as storage (phy backend). - Using virt-manager to install PV domUs using LVM volumes as storage (phy backend). What doesn't work: - Using virt-manager to install PV domUs using file images as storage (tap:aio backend). Oh, and obviously virt-install fails aswell when trying to use file images, same problem as with virt-manager. Here's the virt-install commandline example you can use for testing: virt-install -d -n blktaptest01 -r 2048 --vcpus=2 --disk /var/lib/libvirt/images/blktaptest01.img,size=8 --vnc -p -b virbr0 -l http://ftp.funet.fi/pub/mirrors/centos.org/6.6/os/x86_64; obviously you need to have a working libvirt-setup before running that command, and the libvirt/dnsmasq virbr0 bridge as created by libvirtd: - yum install libvirt libvirt-daemon libvirt-daemon-network libvirt-driver-network libvirt-driver-xen virt-install virt-viewer virt-manager python-virtinst xorg-x11-xauth - service xend restart - service libvirtd restart This libvirt/blktap2 file images failure with Xen 4.4 rpms is a regression from Xen 4.2 rpms, where blktap2 works OK with libvirt/virt-install/virt-manager. The problem is most probably the fact that we had custom patches included in the xen4c6 libvirt rpms that we shipped with the Xen 4.2 rpms. We had to add two patches, one patch to fix the blktap2 backend type in libvirt, and one patch to fix the blktap2 backend type in virt-install or virt-manager, i'm not totally sure which one it was. Those patches should be included in the earlier libvirt source rpms, so we can check there. Or I can search thru my emails, because I hunted that down earlier aswell. It seems we still need those patches with the latest libvirt rpms too. The actual problem is libvirt/virt-manager tries to configure tap:aio: backend, which won't work. It needs to be tap2:aio. I get the exactly same behaviour with xm/xend. tap:aio stalls and fails. tap2:aio works OK. Ok so digging into the email archives it seems earlier we patched python-virtinst src.rpm, which seems to be the component used by both virt-install and virt-manager for new domain installations. So we need to modify the virtinst/VirtualDisk.py file and change the: DRIVER_TAP = tap to DRIVER_TAP = tap2 To change the default. After that change the libvirt generated domain xml looks like this, from both virt-install and virt-manager and works OK: disk type='file' device='disk' driver name='tap2' type='aio'/ source file='/var/lib/libvirt/images/blktaptest01.img'/ target dev='xvda' bus='xen'/ /disk (virsh dumpxml domain) -- Pasi ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS] When will CentOS Publish Errata?
On 2015-01-06, Somers-Harris, David | David | OPS david.somers-har...@mail.rakuten.com wrote: 1. Blatant screen scraping is a violation of the terms of service for RHN .. so where is a SOURCE of information for something like this: https://rhn.redhat.com/errata/RHSA-2014-2024.html If you read this: https://access.redhat.com/help/terms/ then, one can not just grab all the info on that errata page and distribute it .. which is why we LINK to it and not distribute it currently. So, the first issue is that one must find a source for the information that would go into the 'updateinfo.xml' file that is always maintained and is available to read and to redistribute. 2. If someone comes up with a place to get said data, THEN we could properly publish that data in some way. Thanks, Johnny Hughes Can't we just ask Red Hat if it's OK for CentOS to use the data for its updateinfo.xml? Is there some official communication channel between the CentOS Project and Red Hat? Maybe you missed the big announcement: http://lists.centos.org/pipermail/centos-announce/2014-January/020100.html -- Liam ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Hardware raid LSI Megaraid not working since Centos 6.6
On 06/01/2015 09:36, Philippe BOURDEU d'AGUERRE wrote: Thank you for your help. Le 05/01/2015 19:10, John R Pierce a écrit : works here fine on the 9261, which is an OEM version of the same card with the connectors in a different orientation... you might check your LSI firmware revision. My firmware seems to be more up to date. Anyway, I will try to update firmware. I have to check how to do that. # dmesg |grep LSI scsi4 : LSI SAS based MegaRAID driver scsi 4:2:0:0: Direct-Access LSI MR9260-4i2.13 PQ: 0 ANSI: 5 # /opt/MegaRAID/MegaCli/MegaCli64 -ShowSummary -aAll System Operating System: Linux version 2.6.32-431.29.2.el6.x86_64 Driver Version: 06.700.06.00-rh1 CLI Version: 8.07.14 Hardware Controller ProductName : LSI MegaRAID SAS 9260-4i(Bus 0, Dev 0) SAS Address : 500605b008a30fc0 FW Package Version: 12.14.0-0167 Status: Optimal BBU BBU Type : iBBU Status: Healthy Enclosure Product Id: SGPIO Type : SGPIO Status: OK . . . For info: # /opt/MegaRAID/MegaCli/MegaCli64 -ShowSummary -aAll System Operating System: Linux version 2.6.32-504.3.3.el6.x86_64 Driver Version: 06.803.01.00-rh1 CLI Version: 8.04.07 Hardware Controller ProductName : LSI MegaRAID SAS 9260-4i(Bus 0, Dev 0) SAS Address : 500605b0048274e0 FW Package Version: 12.15.0-0189 Status: Optimal BBU BBU Type : iBBU08 Status: Healthy Enclosure Product Id: SGPIO Type : SGPIO Status: OK -- Regards, Giles Coochey, CCNP, CCNA, CCNAS NetSecSpec Ltd +44 (0) 8444 780677 +44 (0) 7584 634135 http://www.coochey.net http://www.netsecspec.co.uk gi...@coochey.net ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS-virt] Xen4CentOS python-virtinst version issue, blktap2 problem
Hello, It seems currently when you yum update CentOS 6.6 Xen host you end up getting python-virtinst from c6 base repo: python-virtinst-0.600.0-24.el6.noarch and not from Xen4CentOS repo, because the version there is older: 0.600.0-19. .. which means the centos/xen-specific patch in python-virtinst is lost. (default to tap2 instead of tap1, to make blktap2 work out-of-the-box with virt-install and virt-manager when using file based images as disks for VMs). So.. who can build a new version of python-virtinst, with the blktap2 patch applied? -- Pasi ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
[CentOS] CentOS-announce Digest, Vol 119, Issue 1
Send CentOS-announce mailing list submissions to
centos-annou...@centos.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.centos.org/mailman/listinfo/centos-announce
or, via email, send a message with subject or body 'help' to
centos-announce-requ...@centos.org
You can reach the person managing the list at
centos-announce-ow...@centos.org
When replying, please edit your Subject line so it is more specific
than Re: Contents of CentOS-announce digest...
Today's Topics:
1. CEBA-2015:0002 CentOS 6 autofs BugFix Update (Johnny Hughes)
2. CEBA-2015:0006 CentOS 5 nss_db BugFix Update (Johnny Hughes)
3. CEBA-2015:0003 CentOS 6 dovecot BugFix Update (Johnny Hughes)
4. CEBA-2015:0005 CentOS 6 gdbm FASTTRACK BugFix Update
(Johnny Hughes)
5. CEBA-2015:0007 CentOS 7 mariadb BugFix Update (Johnny Hughes)
6. Improvements in the docker registry for CentOS (Jim Perrin)
7. CESA-2015:0008 Low CentOS 7 libvirt Security Update
(Johnny Hughes)
8. Infra - CentOS hardware move [cbs] (Fabian Arrotin)
--
Message: 1
Date: Mon, 5 Jan 2015 11:54:59 +
From: Johnny Hughes joh...@centos.org
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2015:0002 CentOS 6 autofs BugFix
Update
Message-ID: 20150105115459.ga34...@n04.lon1.karan.org
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2015:0002
Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0002.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
791e92b38ed363ee16ccb14e67886fa043fc61b78410e5458d8850aac0eb38e9
autofs-5.0.5-109.el6_6.1.i686.rpm
x86_64:
7bcd267ca01b2c066570f94f1995abe4914e3f200b01163904e6206776a78319
autofs-5.0.5-109.el6_6.1.x86_64.rpm
Source:
304e3d53ec5b2fafa76efb9ad403cfa58450ca62eda799fe8d4a4517eefaa3ce
autofs-5.0.5-109.el6_6.1.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
Message: 2
Date: Mon, 5 Jan 2015 11:44:01 +
From: Johnny Hughes joh...@centos.org
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2015:0006 CentOS 5 nss_db BugFix
Update
Message-ID: 20150105114401.ga20...@chakra.karan.org
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2015:0006
Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0006.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
b321179fd1a8daee28d28f2f13bd60effb39cf1cdf4304eedef58b78a0eb4eef
nss_db-2.2-38.el5_11.i386.rpm
x86_64:
b321179fd1a8daee28d28f2f13bd60effb39cf1cdf4304eedef58b78a0eb4eef
nss_db-2.2-38.el5_11.i386.rpm
c2b5f3a8a8035791ecca4ff65824b800e7bdb631ba9ece5422df6ef287f4ea37
nss_db-2.2-38.el5_11.x86_64.rpm
Source:
dccdca10a0dab429227be07c89a86e132818ead10015d00bd95a0bb79f3097dc
nss_db-2.2-38.el5_11.src.rpm
--
Johnny Hughes
CentOS Project { http://www.centos.org/ }
irc: hughesjr, #cen...@irc.freenode.net
--
Message: 3
Date: Mon, 5 Jan 2015 11:55:44 +
From: Johnny Hughes joh...@centos.org
To: centos-annou...@centos.org
Subject: [CentOS-announce] CEBA-2015:0003 CentOS 6 dovecot BugFix
Update
Message-ID: 20150105115544.ga34...@n04.lon1.karan.org
Content-Type: text/plain; charset=us-ascii
CentOS Errata and Bugfix Advisory 2015:0003
Upstream details at : https://rhn.redhat.com/errata/RHBA-2015-0003.html
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
i386:
f5dfa398b4a4814d0b3df88c08f438d027786a0b6c7fabd68457bd770015ec8f
dovecot-2.0.9-8.el6_6.4.i686.rpm
078ae9c95a9f2136d29b1688ec9dd15dd66df69767c24ada02836b09f8d5a6c5
dovecot-devel-2.0.9-8.el6_6.4.i686.rpm
374a25e24922394e495c00c40e13fd0c351ce0d8986352e735a48c7929e12a74
dovecot-mysql-2.0.9-8.el6_6.4.i686.rpm
6c3d38ef793830170c8c16d44df855f256ef12371ffa661756ff52e0fb714fbe
dovecot-pgsql-2.0.9-8.el6_6.4.i686.rpm
420a71aab3bb3217280308e261f3c9c953e443be745fee06ff5343ff58bfc4ab
dovecot-pigeonhole-2.0.9-8.el6_6.4.i686.rpm
x86_64:
f5dfa398b4a4814d0b3df88c08f438d027786a0b6c7fabd68457bd770015ec8f
dovecot-2.0.9-8.el6_6.4.i686.rpm
da78ffbf581dea0507ad136791af11ffd553490dce8244c8457242cbb20378b6
dovecot-2.0.9-8.el6_6.4.x86_64.rpm
32b47811c8eeb596ce5b892a877c250d2512f0a83ce2290fe091dc137b2fcadd
dovecot-devel-2.0.9-8.el6_6.4.x86_64.rpm
8669e89382754b87b36079d43d27944f2b3a0e2637b9d171874a0b04a24ae7f2
dovecot-mysql-2.0.9-8.el6_6.4.x86_64.rpm
a123529a8f012844ddd4eff3755800dd0a180b75ad669b966794aec09e22aee6
dovecot-pgsql-2.0.9-8.el6_6.4.x86_64.rpm
c064292f212fb4b4edef71f4c2518878b55f240c184265f78bc03f823875aedc
dovecot-pigeonhole-2.0.9-8.el6_6.4.x86_64.rpm
Source:
Re: [CentOS] Hardware raid LSI Megaraid not working since Centos 6.6
Le 06/01/2015 10:36, Philippe BOURDEU d'AGUERRE a écrit : Anyway, I will try to update firmware. I have updated firmware to version 12.15.0-0205. The problem remains :-( -- Philippe BOURDEU d'AGUERRE AIME - Campus de l'INSA http://www.aime-toulouse.fr/ 135 av. de Rangueil Tél +33 561 559 885 31077 TOULOUSE Cedex 4 - FRANCE Fax +33 561 559 870 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Radeon graphics problems with CentOS 6.6
-Original Message- From: Darby Vicker [mailto:darby.vic...@gmail.com] Sent: Tuesday, January 06, 2015 12:24 AM To: centos@centos.org Subject: Re: [CentOS] Radeon graphics problems with CentOS 6.6 On Sat, Jan 3, 2015 at 2:27 PM, Darby Vicker darby.vic...@gmail.com wrote: On Saturday, December 20, 2014, Darby Vicker darby.vic...@gmail.com wrote: I thought about trying centos 7. But in the end that doesn't really help me since I'm trying to keep my current centos 6 installation working. I don't really have the time/energy to reinstall everyting under CentOS 7 right now. I was able to get a 6.6 LiveCD built myself. The liveCD has the same problem - X doesn't work. I can boot the Basic Video option from the LiveCD and I can at least get to the desktop but there are several odd video problems when I do that. But I think that means that there is a genuine problem with Xorg on my hardware. Does anyone know who I should submit this bug to - AMD or Xorg? Any other ideas for workarounds in the mean time? The xorg ati developer doesn't think it's a driver problem. http://lists.x.org/archives/xorg-driver-ati/2014-December/026948.html Any other ideas for tracking this down? After a little more conversation with the ati developer, he thinks its a problem with the kernel. http://lists.x.org/archives/xorg-driver-ati/2015-January/026986.html He is suggesting I get in touch with the people who maintain the CentOS kernel. What is the best way to do this? Submit a bug on https://bugs.centos.org? Two things I think you should consider doing... 1) in your next post (and any bugs you open), include the `uname -a` of the last known to work correctly CentOS/RHEL kernel, and the `uname -a` of the first known to not work correctly CentOS/RHEL kernel and the respective versions of radeon | flrgx drivers. 2) try out elrepo's el6 kernel-lt kernel-ml and see if they work correctly for you. I suggest this, because for me it did workaround an issue with intel chips (I guess I need to see what it will take to get the elrepo folks to make just a back-ported intel driver from 3.17 [first known to work again, 3.16 does not]) . http://lists.centos.org/pipermail/centos/2014-November/147579.html Even when this disclaimer is not here: I am not a contracting officer. I do not have authority to make or modify the terms of any contract. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] When will CentOS Publish Errata?
On 01/06/2015 04:25 AM, Liam O'Toole wrote: On 2015-01-06, Somers-Harris, David | David | OPS david.somers-har...@mail.rakuten.com wrote: 1. Blatant screen scraping is a violation of the terms of service for RHN .. so where is a SOURCE of information for something like this: https://rhn.redhat.com/errata/RHSA-2014-2024.html If you read this: https://access.redhat.com/help/terms/ then, one can not just grab all the info on that errata page and distribute it .. which is why we LINK to it and not distribute it currently. So, the first issue is that one must find a source for the information that would go into the 'updateinfo.xml' file that is always maintained and is available to read and to redistribute. 2. If someone comes up with a place to get said data, THEN we could properly publish that data in some way. Thanks, Johnny Hughes Can't we just ask Red Hat if it's OK for CentOS to use the data for its updateinfo.xml? Is there some official communication channel between the CentOS Project and Red Hat? Maybe you missed the big announcement: http://lists.centos.org/pipermail/centos-announce/2014-January/020100.html Sure, but they aren't likely to let us. The purpose of CentOS within the Red Hat ecosystem is explained here: http://community.redhat.com/centos-faq/ CentOS is open source, so you can use it however you want and for what ever you are comfortable using it for .. however, giving special dispensation to violate terms of service of RHN to make CentOS more usable than it already is in the enterprise is not high on their priority list. They are not taking any action to make it in any way less usable, but they are also not going to do anything to make it easier either. What we need is a way to get that info from another place. Maybe the oval data, if it has all the required information and if the Terms of Service allow for that. Someone in the Community needs to research that and see if it is usable or if there is some other source for the information that can then be modified to create the updateinfo.xml file. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] CentOS 6 Xen 4.4.1 packages available on virt6-testing
On 12/15/2014 12:24 PM, George Dunlap wrote: At long last, I've got some beta CentOS 6 4.4.1 packages up on the CBS. Major updates include: * Update to Xen 4.4.1. Also includes all XSAs through 114 * Update to latest blktap 2.5 * Updated libvirt packages (1.2.10), which work well with libxl To use, add the following to a file in /etc/yum.repos.d: [virt-testing] name=CentOS-$releasever - virt-testing baseurl=http://cbs.centos.org/repos/virt6-testing/$basearch/os/ gpgcheck=0 enabled=1 Notes: * git repo with all the changes to xen can be found here: https://github.com/gwd/sig-virt-xen out/virt6/update-4.4.1-4 * The signing infrastructure is not in place, so the binaries are not signed. * xend is now disabled by default. You can enable it by running chkconfig. xend has been removed from the tree entirely in Xen 4.5, so this should (hopefully) serve as a wake-up-call for people to begin the transition over to xend. * A lot have things have changed -- please to test this so we can get a good idea what may have broken. -George George, I don't mind if xend is on or off, but the virt-manager (virt-install, etc.) that is included with the current xen4 tree will not work at all with libxl. We therefore do not have a GUI front end that can do libxl at this time. I might suggest leaving xend on for 4.4.x and we stabilize on 4.4.x on the production branch, and then start a testing branch that will be 4.5 (or newer) with a newer libvirt, virt-manager, qemu, etc. I thought maybe a new kernel as well, but based on this: https://www.kernel.org/category/releases.html It seems 3.10.x (at Sept 2016) is the best LTS kernel for support purposes. Thanks, Johnny Hughes signature.asc Description: OpenPGP digital signature ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] CentOS 6 Xen 4.4.1 packages available on virt6-testing
On 01/06/2015 08:54 AM, Johnny Hughes wrote: On 12/15/2014 12:24 PM, George Dunlap wrote: At long last, I've got some beta CentOS 6 4.4.1 packages up on the CBS. Major updates include: * Update to Xen 4.4.1. Also includes all XSAs through 114 * Update to latest blktap 2.5 * Updated libvirt packages (1.2.10), which work well with libxl To use, add the following to a file in /etc/yum.repos.d: [virt-testing] name=CentOS-$releasever - virt-testing baseurl=http://cbs.centos.org/repos/virt6-testing/$basearch/os/ gpgcheck=0 enabled=1 Notes: * git repo with all the changes to xen can be found here: https://github.com/gwd/sig-virt-xen out/virt6/update-4.4.1-4 * The signing infrastructure is not in place, so the binaries are not signed. * xend is now disabled by default. You can enable it by running chkconfig. xend has been removed from the tree entirely in Xen 4.5, so this should (hopefully) serve as a wake-up-call for people to begin the transition over to xend. * A lot have things have changed -- please to test this so we can get a good idea what may have broken. -George George, I don't mind if xend is on or off, but the virt-manager (virt-install, etc.) that is included with the current xen4 tree will not work at all with libxl. We therefore do not have a GUI front end that can do libxl at this time. I might suggest leaving xend on for 4.4.x and we stabilize on 4.4.x on the production branch, and then start a testing branch that will be 4.5 (or newer) with a newer libvirt, virt-manager, qemu, etc. I thought maybe a new kernel as well, but based on this: https://www.kernel.org/category/releases.html It seems 3.10.x (at Sept 2016) is the best LTS kernel for support purposes. So, I can't read :) .. 3.10.x stops in Sept 2016 Looks like jumping to 3.14.x would be required at some point, might as well try to do that in the testing branch as well. Thanks, JOhnny Hughes signature.asc Description: OpenPGP digital signature ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] CentOS 6 Xen 4.4.1 packages available on virt6-testing
On 01/06/2015 09:01 AM, Johnny Hughes wrote: On 01/06/2015 08:54 AM, Johnny Hughes wrote: On 12/15/2014 12:24 PM, George Dunlap wrote: At long last, I've got some beta CentOS 6 4.4.1 packages up on the CBS. Major updates include: * Update to Xen 4.4.1. Also includes all XSAs through 114 * Update to latest blktap 2.5 * Updated libvirt packages (1.2.10), which work well with libxl To use, add the following to a file in /etc/yum.repos.d: [virt-testing] name=CentOS-$releasever - virt-testing baseurl=http://cbs.centos.org/repos/virt6-testing/$basearch/os/ gpgcheck=0 enabled=1 Notes: * git repo with all the changes to xen can be found here: https://github.com/gwd/sig-virt-xen out/virt6/update-4.4.1-4 * The signing infrastructure is not in place, so the binaries are not signed. * xend is now disabled by default. You can enable it by running chkconfig. xend has been removed from the tree entirely in Xen 4.5, so this should (hopefully) serve as a wake-up-call for people to begin the transition over to xend. * A lot have things have changed -- please to test this so we can get a good idea what may have broken. -George George, I don't mind if xend is on or off, but the virt-manager (virt-install, etc.) that is included with the current xen4 tree will not work at all with libxl. We therefore do not have a GUI front end that can do libxl at this time. I might suggest leaving xend on for 4.4.x and we stabilize on 4.4.x on the production branch, and then start a testing branch that will be 4.5 (or newer) with a newer libvirt, virt-manager, qemu, etc. I thought maybe a new kernel as well, but based on this: https://www.kernel.org/category/releases.html It seems 3.10.x (at Sept 2016) is the best LTS kernel for support purposes. So, I can't read :) .. 3.10.x stops in Sept 2016 ARGH /// 2015 /// can't read OR type it seems Looks like jumping to 3.14.x would be required at some point, might as well try to do that in the testing branch as well. Thanks, JOhnny Hughes ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt signature.asc Description: OpenPGP digital signature ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Xen4CentOS python-virtinst version issue, blktap2 problem
On 01/06/2015 08:38 AM, Philippe-A. Lemelin wrote: On 15-01-06 09:21 AM, George Dunlap wrote: On Tue, Jan 6, 2015 at 11:42 AM, Pasi Kärkkäinen pa...@iki.fi wrote: Hello, It seems currently when you yum update CentOS 6.6 Xen host you end up getting python-virtinst from c6 base repo: python-virtinst-0.600.0-24.el6.noarch and not from Xen4CentOS repo, because the version there is older: 0.600.0-19. .. which means the centos/xen-specific patch in python-virtinst is lost. (default to tap2 instead of tap1, to make blktap2 work out-of-the-box with virt-install and virt-manager when using file based images as disks for VMs). So.. who can build a new version of python-virtinst, with the blktap2 patch applied? Looks like Johnny's built an updated version and placed it here: http://people.centos.org/hughesjr/xen4-test/ Maybe we can leave it there for a day or so for people to test it, and push it to the main xen4 repo at EOD tomorrow? -George I just successfully completed the installation of a CentOS guest with this version of python-virtinst. Thank you, Philippe-A. Lemelin I am doing a newer: 1. kernel from kernel.org (3.10.63), also the e1000e kernel module for that. 2. libvirt rolling in the last patch in this tree: http://libvirt.org/git/?p=libvirt.git;a=shortlog;h=refs/heads/v0.10.2-maint 3. newer xen-4.2.5 with all released XSAs 108 (including 116 .. but not 115 as it is not released) and that python-virtinstall I have already modified the the source code and I am building, I'll post when they are reading for testing. Thanks, Johnny Hughes signature.asc Description: OpenPGP digital signature ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
[CentOS-docs] removing/redirecting the Projects page
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We've decided to decomission the (old and unused) trac instance on projects.centos.org. We'll just redirect to git.centos.org instead (where all the fun happens). So, what to do with the http://wiki.centos.org/Projects page ? deleting it ? redireting to http://wiki.centos.org/SpecialInterestGroup (as now most of the things outside of Core happens through SIGs) Searching for opinions .. - -- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlSr/hMACgkQnVkHo1a+xU5NQACcC8/IV7ZEO4vw6J7SoP2Dp3Fi x8cAoJkZauCoC7x1rG7mcZ1tJ4lWx/lm =2+TO -END PGP SIGNATURE- ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS-virt] Xen4CentOS python-virtinst version issue, blktap2 problem
On Tue, Jan 06, 2015 at 01:44:13PM -0600, Johnny Hughes wrote: On 01/06/2015 12:47 PM, Pasi Kärkkäinen wrote: On Tue, Jan 06, 2015 at 12:23:28PM -0600, Johnny Hughes wrote: I am doing a newer: 1. kernel from kernel.org (3.10.63), also the e1000e kernel module for that. 2. libvirt rolling in the last patch in this tree: http://libvirt.org/git/?p=libvirt.git;a=shortlog;h=refs/heads/v0.10.2-maint 3. newer xen-4.2.5 with all released XSAs 108 (including 116 .. but not 115 as it is not released) and that python-virtinstall I have already modified the the source code and I am building, I'll post when they are reading for testing. OK, the RPMS I am going to release are now in: http://people.centos.org/hughesjr/xen4-test/ I am going to roll those into the main xen4 repo after some testing .. provide any feedback to this thread. With no negative feedback, this will likely go live tomorrow or Thursday if it works for the people who test it. Johnny: I tested the following: from http://people.centos.org/hughesjr/xen4-test/ - kernel-3.10.63-11.el6.centos.alt.x86_64.rpm - python-virtinst-0.600.0-25.el6.centos.alt.noarch.rpm And they worked OK, no problems found! I'll try to get the latest Xen 4.2.5-38 and libvirt 0.10.2.8-9 rpms tested soon aswell. -- Pasi I upgraded my current xen4centos test box with all the applicable packages in the link above and all my Xen VMs still start and run correctly. Good to hear! -- Pasi ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] CentOS 6 Xen 4.4.1 packages available on virt6-testing / libvirt blktap2 problems
On Tue, Jan 06, 2015 at 01:55:57PM -0600, Johnny Hughes wrote: Ok I just used a couple of hours testing Xen 4.4.1 rpms on CentOS 6.6 with Linux 3.10 dom0 kernel. This session was all about xm/xend testing. I manually enabled xend first. What Works OK: - Manually creating/managing guests with xm and domU cfgfiles in /etc/xen and LVM volumes as storage (phy backend). - Manually creating/managing guests with xm and domU cfgfiles in /etc/xen and file images as storage (tap2:aio backend). - Using virt-install to install PV domUs using LVM volumes as storage (phy backend). - Using virt-manager to install PV domUs using LVM volumes as storage (phy backend). What doesn't work: - Using virt-manager to install PV domUs using file images as storage (tap:aio backend). This libvirt/blktap2 file images failure with Xen 4.4 rpms is a regression from Xen 4.2 rpms, where blktap2 works OK with libvirt/virt-install/virt-manager. The problem is most probably the fact that we had custom patches included in the xen4c6 libvirt rpms that we shipped with the Xen 4.2 rpms. We had to add two patches, one patch to fix the blktap2 backend type in libvirt, and one patch to fix the blktap2 backend type in virt-install or virt-manager, i'm not totally sure which one it was. Those patches should be included in the earlier libvirt source rpms, so we can check there. Or I can search thru my emails, because I hunted that down earlier aswell. It seems we still need those patches with the latest libvirt rpms too. The actual problem is libvirt/virt-manager tries to configure tap:aio: backend, which won't work. It needs to be tap2:aio. I get the exactly same behaviour with xm/xend. tap:aio stalls and fails. tap2:aio works OK. Now with the new python-virtinst and then new kernel from here: http://people.centos.org/hughesjr/xen4-test/ But with the new libvirt-1.2 and xen 4.4 from this repo, everything seems to work with xend enabled. Yep, with the updated python-virtinst all works now, also with the Xen 4.4 rpms. Thanks a lot! -- Pasi ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS] Design changes are done in Fedora
On Mon, Jan 5, 2015 at 9:22 PM, Warren Young w...@etr-usa.com wrote: Docker will eat away at this problem going forward. You naturally will not already have Dockerized versions of apps built 10 years ago, and it may not be practical to create them now, but you can start insisting on getting them today so that your future OS changes don’t break things for you again. Yes, it is just sad that it is necessary to isolate your work from the disruptive nature of the OS distribution. But it is becoming clearly necessary. I built a CentOS7 to match my old CentOS5 pair. It can do the same thing, but there is no way to make them actively cluster together so the new one is aware of the outstanding leases at cutover or to have the ability to revert if the new one introduces problems. I believe that was ISC’s fault, not Red Hat’s. Agreed - and some of the value of Red Hat shows in the fact that the breakage is not packaged into a mid-rev update. Perhaps your point is that Red Hat should have either a) continued to distribute an 8-year-old version of dhcpd with EL7 [1], or b) somehow given you the new features of ISC dhcpd 4.2.5 without breaking anything? If so, I take this point back up at the end. Maybe document how you were supposed to deal with the situation, keeping your lease history intact and the ability to fail over during the transition. My point here is that there are people using RHEL that care about this sort of thing, but the system design is done in Fedora where I'm convinced that no one actually manages any machines doing jobs that matter or cares what the change might break. That is, the RHEL/Fedora split divided the community that originally built RH into people who need to maintain working systems and people who just want change. And they let the ones who want change design the next release. And those things span much longer that 10 years. If you are very young you might not understand that. My first look at the Internet was on a VT102. I refer not to a terminal emulator, but to something that crushes metatarsals if you drop it on your foot. I think I’ve got enough gray in my beard to hold my own in this conversation. So, after you've spent at least 10 years rolling out machines to do things as fast as you can, and teaching the others in your organization to spell 'chkconfig' and use 'system ...' commands, wouldn't you rather continue to be productive and do more instead of having to start over and re-do the same set of things over again just to keep the old stuff working? But if numbers impress you, if you count android/Dalvik which is close enough to be the stuff of lawsuits, there's probably more instances of running programs than anything else. There are more JavaScript interpreters in the world than Dalvik, ART,[2] and Java ® VMs combined. Perhaps we should rewrite everything in JavaScript instead? I'm counting the running/useful instances of actual program code, not the interpreters that might be able to run something. But JavaScript is on the rise mostly because the interpreters upgrade transparently and the hassle is somewhat hidden. If we consider only the *ix world, there are more Bourne-compatible shell script interpreters than Perl, Python, or Ruby interpreters. Why did anyone bother to create these other languages, and why do we spend time maintaining these environments and writing programs for them? We spend time 'maintaining' because the OS underneath churns. Otherwise we would pretty quickly have all of the programs anyone needs completed. I thought CPAN was approaching that long ago, or at least getting to the point where the new code you have to write to do about anything would take about half a page of calls to existing modules. Why even bother with ksh or Bash extensions, for that matter? The original Bourne shell achieved Turing-completeness in 1977. There is literally nothing we can ask a computer to do that we cannot cause to happen via a shell script. (Except run fast.) Well, Bourne didn't deal with sockets. My opinion is that you'd be better off switching to perl at the first hint of needing arrays/sockets or any library modules that already exist in CPAN instead of extending a shell beyond the basic shell-ish stuff. But nobody asked me about that. If you think I’m wrong about that, you probably didn’t ever use sharchives. Of course I used sharchives - and I value the fact that (unlike most other languages) things written in Bourne-compatible shell syntax at any time in the past will still run, and fairly portably - except perhaps for the plethora of external commands that were normally needed. Perl doesn't have quite as long a history but is just about as good at backwards compatibility. With the exception of interpolating @ in double-quoted strings starting around version 5, pretty much anything you ever wrote in perl will still work. I'm holding off on python and ruby
Re: [CentOS-virt] Xen4CentOS python-virtinst version issue, blktap2 problem
On Tue, Jan 06, 2015 at 12:23:28PM -0600, Johnny Hughes wrote: I am doing a newer: 1. kernel from kernel.org (3.10.63), also the e1000e kernel module for that. 2. libvirt rolling in the last patch in this tree: http://libvirt.org/git/?p=libvirt.git;a=shortlog;h=refs/heads/v0.10.2-maint 3. newer xen-4.2.5 with all released XSAs 108 (including 116 .. but not 115 as it is not released) and that python-virtinstall I have already modified the the source code and I am building, I'll post when they are reading for testing. OK, the RPMS I am going to release are now in: http://people.centos.org/hughesjr/xen4-test/ I am going to roll those into the main xen4 repo after some testing .. provide any feedback to this thread. With no negative feedback, this will likely go live tomorrow or Thursday if it works for the people who test it. Johnny: I tested the following: from http://people.centos.org/hughesjr/xen4-test/ - kernel-3.10.63-11.el6.centos.alt.x86_64.rpm - python-virtinst-0.600.0-25.el6.centos.alt.noarch.rpm And they worked OK, no problems found! I'll try to get the latest Xen 4.2.5-38 and libvirt 0.10.2.8-9 rpms tested soon aswell. -- Pasi ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] Xen4CentOS python-virtinst version issue, blktap2 problem
On 01/06/2015 12:47 PM, Pasi Kärkkäinen wrote: On Tue, Jan 06, 2015 at 12:23:28PM -0600, Johnny Hughes wrote: I am doing a newer: 1. kernel from kernel.org (3.10.63), also the e1000e kernel module for that. 2. libvirt rolling in the last patch in this tree: http://libvirt.org/git/?p=libvirt.git;a=shortlog;h=refs/heads/v0.10.2-maint 3. newer xen-4.2.5 with all released XSAs 108 (including 116 .. but not 115 as it is not released) and that python-virtinstall I have already modified the the source code and I am building, I'll post when they are reading for testing. OK, the RPMS I am going to release are now in: http://people.centos.org/hughesjr/xen4-test/ I am going to roll those into the main xen4 repo after some testing .. provide any feedback to this thread. With no negative feedback, this will likely go live tomorrow or Thursday if it works for the people who test it. Johnny: I tested the following: from http://people.centos.org/hughesjr/xen4-test/ - kernel-3.10.63-11.el6.centos.alt.x86_64.rpm - python-virtinst-0.600.0-25.el6.centos.alt.noarch.rpm And they worked OK, no problems found! I'll try to get the latest Xen 4.2.5-38 and libvirt 0.10.2.8-9 rpms tested soon aswell. -- Pasi I upgraded my current xen4centos test box with all the applicable packages in the link above and all my Xen VMs still start and run correctly. signature.asc Description: OpenPGP digital signature ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS-virt] CentOS 6 Xen 4.4.1 packages available on virt6-testing / libvirt blktap2 problems
On 01/05/2015 04:15 PM, Pasi Kärkkäinen wrote: On Tue, Dec 16, 2014 at 10:29:53PM +0200, Pasi Kärkkäinen wrote: * xend is now disabled by default. You can enable it by running chkconfig. xend has been removed from the tree entirely in Xen 4.5, so this should (hopefully) serve as a wake-up-call for people to begin the transition over to xend. * A lot have things have changed -- please to test this so we can get a good idea what may have broken. I'll test soon. Thanks a lot! Ok I just used a couple of hours testing Xen 4.4.1 rpms on CentOS 6.6 with Linux 3.10 dom0 kernel. This session was all about xm/xend testing. I manually enabled xend first. What Works OK: - Manually creating/managing guests with xm and domU cfgfiles in /etc/xen and LVM volumes as storage (phy backend). - Manually creating/managing guests with xm and domU cfgfiles in /etc/xen and file images as storage (tap2:aio backend). - Using virt-install to install PV domUs using LVM volumes as storage (phy backend). - Using virt-manager to install PV domUs using LVM volumes as storage (phy backend). What doesn't work: - Using virt-manager to install PV domUs using file images as storage (tap:aio backend). This libvirt/blktap2 file images failure with Xen 4.4 rpms is a regression from Xen 4.2 rpms, where blktap2 works OK with libvirt/virt-install/virt-manager. The problem is most probably the fact that we had custom patches included in the xen4c6 libvirt rpms that we shipped with the Xen 4.2 rpms. We had to add two patches, one patch to fix the blktap2 backend type in libvirt, and one patch to fix the blktap2 backend type in virt-install or virt-manager, i'm not totally sure which one it was. Those patches should be included in the earlier libvirt source rpms, so we can check there. Or I can search thru my emails, because I hunted that down earlier aswell. It seems we still need those patches with the latest libvirt rpms too. The actual problem is libvirt/virt-manager tries to configure tap:aio: backend, which won't work. It needs to be tap2:aio. I get the exactly same behaviour with xm/xend. tap:aio stalls and fails. tap2:aio works OK. Now with the new python-virtinst and then new kernel from here: http://people.centos.org/hughesjr/xen4-test/ But with the new libvirt-1.2 and xen 4.4 from this repo, everything seems to work with xend enabled. signature.asc Description: OpenPGP digital signature ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
Re: [CentOS] Design changes are done in Fedora
On Tue, 2015-01-06 at 16:07 -0700, Warren Young wrote: There is nothing new to be discovered in physics now. All that remains is more and more precise measurement.” — William Thomson, Lord Kelvin, 1900 Now means the current time. Now is not, and never will be, The (unknown) Future. In the real world of using computers productively for repetitive tasks, people want stability and perhaps faster running programmes. No one ever wants a major upset of being forced to use a different method to perform the same tasks. Young men are enthusiastic about implementing new ideas. Old men with substantially more experience wisely want to avoid disrupting well-running systems. Time is money. Disruptions waste money and cause errors. -- Regards, Paul. England, EU. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] reboot - is there a timeout on filesystem flush?
On Tue, Jan 6, 2015 at 6:12 PM, Les Mikesell wrote: I've had a few systems with a lot of RAM and very busy filesystems come up with filesystem errors that took a manual 'fsck -y' after what should have been a clean reboot. This is particularly annoying on remote systems where I have to talk someone else through the recovery. Is there some time limit on the cache write with a 'reboot' (no options) command or is ext4 that fragile? I'd say there's no limit in the amount of time the kernel waits until the blocks have been written to disk; driven by there parameters: vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 10 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 3000 vm.dirty_ratio = 20 vm.dirty_writeback_centisecs = 500 ie, if the data cached on RAM is older than 30s or larger than 10% available RAM, the kernel will try to flush it to disk. Depending how much data needs to be flushed at poweroff/reboot time, this could have a significant effect on the time taken. Regarding systems with lots of RAM, I've never seen such a behaviour on a few 192 GB RAM servers I administer. Granted, your system could be tuned in a different way or have some other configuration. TBH I'm not confident to give a definitive answer re the data not been totally flushed before reboot. I'd investigate: - Whether this happens on every reboot or just on some. - Whether your RAM is OK (the FS errors could come from that!). - Whether your disks/SAN are caching writes. (Maybe they are and the OS thinks the data has been flushed to disk, but they haven't) - filesystem mount options that might interfere (nobarrier, commit, data...) HTH ~f ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Tue, Jan 6, 2015 at 5:07 PM, Warren Young w...@etr-usa.com wrote: There are more JavaScript interpreters in the world than Dalvik, ART,[2] and Java ® VMs combined. Perhaps we should rewrite everything in JavaScript instead? I'm counting the running/useful instances of actual program code, I rather doubt you’ve done anything like actual research on this. Not really, but start with the number of running android devices - and I think it is reasonable to assume that they are running something, checking gmail, etc. It's safe enough to say that's a big number. If you’re trying to say that there’s more CPU-hours of JVM use on *ix than JS in browsers, that sort of elitist argument has been repeatedly defeated. Big Iron vs minicomputers, Unix workstations vs the PC, “real” Unix vs Linux, the PC vs the smartphone… No, I'm saying it pretty much owns the phone/tablet space and the examples of elasticsearch (and other lucene-based stuff), jenkins, etc. show it scales to the other end as well. Time and time again, the forces driving the end-user market end up taking over the hrumph hrumph serious computing market. This has already happened with JS vs Java in the “3 billion” space Oracle wants to claim, and I see no reason why it can’t eventually steamroll the *ix world, too, via node.js. node.js seems like the worst of all worlds - a language designed _not_ to speak to the OS directly with an OS library glued in. But it is a good example of how programmers think - if one says you shouldn't do something, it pretty much guarantees that someone else will. I think the real difference we have on this point is that I’m not actually serious when I propose that the whole world rewrite all software in My Favorite Language just to make my job easier. I'd settle for just not changing the languages in ways that break already written software. But even that seems too much to expect. JavaScript is on the rise mostly because the interpreters upgrade transparently and the hassle is somewhat hidden. No, JavaScript is on the rise because the web is on the rise, and it managed to secure the spot as the web’s scripting language through an accident of history. That is all. I think you are underestimating the way the working interpreters get to the users. And the way the code libraries mask the differences. If users were exposed to version incompatibilities the popularity would vanish. In fact, being able to actively detect and work around incompatibilities is a large part of the reason it is used at all. I thought CPAN was approaching that long ago, or at least getting to the point where the new code you have to write to do about anything would take about half a page of calls to existing modules. Ah yes, the ever-near future where everyone will plug a few Lego-like software blocks together and thereby construct any useful program they wish, while lacking any clue about what’s going on. That future’s been 5 years away for the past 5 decades. Not it the sense that there's nothing new to invent, but that every sysadmin in every organization and every home user should not need to invent new processes to manage their machines. It’s as likely today as ever — which is to say, “not” — and it isn’t the Fedora development community’s fault that we have not yet achieved this nirvana. Really? How have they made it any easier to manage your 2nd machine than your first? Software is “pure thought-stuff,” to quote Fred Brooks. We have very little constraint on the scope and range of things we can create in software. Any attempt to package software up into a usefully-small set of precisely-characterized little black boxes is a Quixotic dream. It is also purely reproducible. Do something right once and no one should ever have to waste that thought again. Why even bother with ksh or Bash extensions, for that matter? The original Bourne shell achieved Turing-completeness in 1977. There is literally nothing we can ask a computer to do that we cannot cause to happen via a shell script. (Except run fast.) Well, Bourne didn't deal with sockets. BSD Sockets didn’t exist in 1977. Precisely. Once there was close to a 1-1 mapping of shell and external commands to system calls. Now there isn't. In any case, you’re willfully ignoring the nature of *ix type shell script programming. A shell script’s “function library” is the set of all programs in the PATH. Drop nc/ncat/netcat/socat in the PATH, and suddenly your shell script knows how to talk to BSD sockets. It’s really no different than installing libnsl on a Solaris box. I wasn't ignoring it. I just was avoiding another rant about how those have not been maintained in a backwards compatible way either. Even though shell syntax is stable, the programs are usually just glue around an assortment of tools that no longer match section 1 of the unix manuals. No nc-alike here? Okay, echo the
Re: [CentOS] reboot - is there a timeout on filesystem flush?
On Jan 6, 2015, at 4:28 PM, Fran Garcia franchu.gar...@gmail.com wrote: On Tue, Jan 6, 2015 at 6:12 PM, Les Mikesell wrote: I've had a few systems with a lot of RAM and very busy filesystems come up with filesystem errors that took a manual 'fsck -y' after what should have been a clean reboot. This is particularly annoying on remote systems where I have to talk someone else through the recovery. Is there some time limit on the cache write with a 'reboot' (no options) command or is ext4 that fragile? I'd say there's no limit in the amount of time the kernel waits until the blocks have been written to disk; driven by there parameters: vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 10 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 3000 vm.dirty_ratio = 20 vm.dirty_writeback_centisecs = 500 ie, if the data cached on RAM is older than 30s or larger than 10% available RAM, the kernel will try to flush it to disk. Depending how much data needs to be flushed at poweroff/reboot time, this could have a significant effect on the time taken. Regarding systems with lots of RAM, I've never seen such a behaviour on a few 192 GB RAM servers I administer. Granted, your system could be tuned in a different way or have some other configuration. TBH I'm not confident to give a definitive answer re the data not been totally flushed before reboot. I'd investigate: - Whether this happens on every reboot or just on some. - Whether your RAM is OK (the FS errors could come from that!). - Whether your disks/SAN are caching writes. (Maybe they are and the OS thinks the data has been flushed to disk, but they haven't) - filesystem mount options that might interfere (nobarrier, commit, data...) This has been discussed to death on various lists, including the LKML... Almost every controller and drive out there now lies about what is and isn’t flushed to disk, making it nigh on impossible for the Kernel to reliably know 100% of the time that the data HAS been flushed to disk. This is part of the reason why it is always a Good Idea™ to have some sort of pause in the shut down to ensure that it IS flushed. This is also why server grade gear uses battery backed buffers, etc. which are supposed to allow drives to properly flush the data to disk. There is still a slim chance in these cases that the data still will not reach the platter before power off or reboot, especially in catastrophic cases. -- Gary L. Greene, Jr. Sr. Systems Administrator IT Operations Minerva Networks, Inc. Cell: +1 (650) 704-6633 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Jan 6, 2015, at 11:43 AM, Les Mikesell lesmikes...@gmail.com wrote: On Mon, Jan 5, 2015 at 9:22 PM, Warren Young w...@etr-usa.com wrote: So, after you've spent at least 10 years rolling out machines to do things as fast as you can, and teaching the others in your organization to spell 'chkconfig' and use 'system ...' commands, wouldn't you rather continue to be productive and do more instead of having to start over and re-do the same set of things over again just to keep the old stuff working? Having been through a bunch of these transitions already (SysV - Linux bingo - BSD - OS X…) it doesn’t greatly bother me. Given that I’ve spent more time on Red Hattish Linuxes than any other *ix, I suppose I’m more surprised it’s lasted as long as it has than I am upset that it’s changing again. There are more JavaScript interpreters in the world than Dalvik, ART,[2] and Java ® VMs combined. Perhaps we should rewrite everything in JavaScript instead? I'm counting the running/useful instances of actual program code, I rather doubt you’ve done anything like actual research on this. If you’re just buying Oracle’s bogus “3 billion” number uncritically, there are a bunch of problems with that, but I’d have to drag us off topic to discuss them. In any case, *ix falls into the noise floor if this is the scale you’re using to gauge the success of Java. If you’re trying to say that there’s more CPU-hours of JVM use on *ix than JS in browsers, that sort of elitist argument has been repeatedly defeated. Big Iron vs minicomputers, Unix workstations vs the PC, “real” Unix vs Linux, the PC vs the smartphone… Time and time again, the forces driving the end-user market end up taking over the hrumph hrumph serious computing market. This has already happened with JS vs Java in the “3 billion” space Oracle wants to claim, and I see no reason why it can’t eventually steamroll the *ix world, too, via node.js. Even if you wave a magic wand and get the JVM onto every *ix box — which is currently very much *not* the case — you’re ignoring the Tiobe numbers I posted in the previous reply. There’s plenty to argue about when it comes to Tiobe’s methodology, but not so much that you can scrape together anything like a majority for any single language. I think the real difference we have on this point is that I’m not actually serious when I propose that the whole world rewrite all software in My Favorite Language just to make my job easier. JavaScript is on the rise mostly because the interpreters upgrade transparently and the hassle is somewhat hidden. No, JavaScript is on the rise because the web is on the rise, and it managed to secure the spot as the web’s scripting language through an accident of history. That is all. Otherwise we would pretty quickly have all of the programs anyone needs completed. There is nothing new to be discovered in physics now. All that remains is more and more precise measurement.” — William Thomson, Lord Kelvin, 1900 Yes, *that* Kelvin. I thought CPAN was approaching that long ago, or at least getting to the point where the new code you have to write to do about anything would take about half a page of calls to existing modules. Ah yes, the ever-near future where everyone will plug a few Lego-like software blocks together and thereby construct any useful program they wish, while lacking any clue about what’s going on. That future’s been 5 years away for the past 5 decades. It’s as likely today as ever — which is to say, “not” — and it isn’t the Fedora development community’s fault that we have not yet achieved this nirvana. Even in electronics, where you have physics to constrain the set of possible realizations, we haven’t even approached this level of nirvana. For every Arduino success story, you have ten stories of cluebies who burned up their H bridge motor driver because they didn’t understand that P=I²R, and that R is almost never zero. (If R is zero, you’re dealing with cryogenics, so all you’ve done is shifted into a different class of cluebie errors that’s more likely to leave said cluebie injured.) Software is “pure thought-stuff,” to quote Fred Brooks. We have very little constraint on the scope and range of things we can create in software. Any attempt to package software up into a usefully-small set of precisely-characterized little black boxes is a Quixotic dream. Why even bother with ksh or Bash extensions, for that matter? The original Bourne shell achieved Turing-completeness in 1977. There is literally nothing we can ask a computer to do that we cannot cause to happen via a shell script. (Except run fast.) Well, Bourne didn't deal with sockets. BSD Sockets didn’t exist in 1977. In any case, you’re willfully ignoring the nature of *ix type shell script programming. A shell script’s “function library” is the set of all programs in the PATH. Drop nc/ncat/netcat/socat
Re: [CentOS] When will CentOS Publish Errata?
On 01/06/2015 12:03 PM, Liam O'Toole wrote: Thanks for all that. My contribution was in response to the question Is there some official communication channel between the CentOS Project and Red Hat? I should have trimmed more carefully and saved you some keystrokes. Nope. We're still air-gapped from the RHEL business units. We have lines of communication to other RH community projects, but nothing that would line up with this thread. -- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] dovecot move doesn't work
I'm running centos 6.6 with the default 2.0.9-xxx dovecot. I run sa-learn against my spam_to_learn folder, then I wan to move those emails to a learned_spam folder. when I do a doveadm -Dv move -u user learned_spam mailbox 'spam_to_learn' ALL I get this result: usage: doveadm [-Dv] [-f formatter] command [args] altmove [-u user|-A] [-S socket_path] search query auth [-a auth socket path] [-x auth info] user [password] config [doveconf parameters] director add|flush|map|remove|status dump [-t type] path expunge [-u user|-A] [-S socket_path] search query fetch[-u user|-A] [-S socket_path] fields search query force-resync [-u user|-A] [-S socket_path] mailbox help cmd import [-u user|-A] [-S socket_path] source mail location dest parent mailbox search query kick [-a anvil socket path] [-f] user mask[|]ip/bits log find|reopen|test mailbox create|delete|list|mutf7|rename|status|subscribe|unsubscribe penalty [-a anvil socket path] [ip/bits] purge[-u user|-A] [-S socket_path] pw [-l] [-p plaintext] [-r rounds] [-s scheme] [-u user] [-V] reload search [-u user|-A] [-S socket_path] search query sis deduplicate|find stop user [-a userdb socket path] [-x auth info] user mask [...] who [-a anvil socket path] [-1] [user mask] [ip/bits] this doesn't even list a move command, yet the dovecot pages show it and give examples. any suggestions? thanks, -chuck -- ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Jan 6, 2015, at 5:07 PM, Les Mikesell lesmikes...@gmail.com wrote: On Tue, Jan 6, 2015 at 5:07 PM, Warren Young w...@etr-usa.com wrote: There are more JavaScript interpreters in the world than Dalvik, ART,[2] and Java ® VMs combined. Perhaps we should rewrite everything in JavaScript instead? I'm counting the running/useful instances of actual program code, I rather doubt you’ve done anything like actual research on this. Not really, but start with the number of running android devices - and I think it is reasonable to assume that they are running something, checking gmail, etc. It's safe enough to say that's a big number. Sigh… I said I didn’t want to get into Oracle’s bogus 3 billion number, or how it’s exceeded by actual JS deployments. Just take it as read that I’ve thought through it, and I’m still sure JS has more deployments. Then apply my Tiobe argument to JS instead of Java: even if JS is significantly bigger than Java, it *still* doesn’t prove anything because it’s still a minority player, so there will continue to be a pressure to use something incompatible with it. There. Is. No. Nirvana. it pretty much owns the phone/tablet space and the examples of elasticsearch (and other lucene-based stuff), jenkins, etc. show it scales to the other end as well. :shakes head in disbelief: What continuum is a smartphone the other end of, exactly? The one in my pocket has multiple general-purpose GHz-class CPU cores, a few specialized coprocessors, several hundred megs of RAM, dozens of gigs of fast local storage, and several high-tech radios. Its raw processing power is on the order of 100 GFLOPS. This is the low end of…what…the Top 500 List from 1998? …except that my phone achieves that parity on a few watts, and doesn’t require a staff of acolytes to tend to its needs. This is a device that would make Captain Kirk jealous, but it’s just one of a billion. Bring. We are *so* spoiled. You want to talk about stupid-high deployment numbers? Let’s talk embedded. 18.1 billion eight-bitters shipped *last year*. http://goo.gl/UTXhuV The PIC10F200 is somewhere near what *I* call the low end: 16 bytes of RAM and a bit under 256 usable words of program memory. http://www.microchip.com/wwwproducts/Devices.aspx?dDocName=en019863 It’s definitely not the actual bottom, though. They still make 4-bitters. node.js seems like the worst of all worlds - a language designed _not_ to speak to the OS directly with an OS library glued in. JavaScript’s a better language than a lot of other scripting languages that have found widespread use. (Please, don’t ask. I *still* don’t want to start an advocacy flamewar.) The economic drive behind it is making it uncommonly fast for a dynamic scripting language. And if the resource hits of dynamic programming are a problem, why were we just talking about Perl? :) But it is a good example of how programmers think - if one says you shouldn't do something, it pretty much guarantees that someone else will. No, the thing you should not do is Jaxer: http://en.wikipedia.org/wiki/Aptana#Aptana_Jaxer node.js is a vastly better plan. it isn’t the Fedora development community’s fault that we have not yet achieved this nirvana. Really? How have they made it any easier to manage your 2nd machine than your first? I didn’t ask them to solve that problem. My company already solved it adequately, years ago, in a massive shell script. Thus my thoughtful treatment of the problem of the gap between shell and C; it was on my mind prior to this exchange. I’m kind of surprised to find that Puppet and Chef are not in EL7, though. I don’t really need either, having solved my particular automatic deployment problem already, but I thought they achieved sufficient popularity before the EL7 feature freeze. Oh, and in case you were wondering, yes, that massive shell script did require some adjustment to move it from EL5 to EL7. It took me a day or two, during which time I was also working on portability differences in the rest of the software. A few days of work to get back on track for the next 7 years; not too shabby. Look, I doubt I’m any happier about how they moved my cheese than you are. I’ve just chosen to go hunt down the cheese and hack a few blocks off, instead of yelling about how they shouldn’t have moved it. Software is “pure thought-stuff,” to quote Fred Brooks. We have very little constraint on the scope and range of things we can create in software. Any attempt to package software up into a usefully-small set of precisely-characterized little black boxes is a Quixotic dream. It is also purely reproducible. Do something right once and no one should ever have to waste that thought again. Arguably Smalltalk was GUIs and OO done right. Go spin up a Squeak VM and see if you still feel at home in that world: http://www.squeak.org/ Not only does technology
Re: [CentOS] Design changes are done in Fedora
On Jan 6, 2015, at 5:06 PM, Always Learning cen...@u62.u22.net wrote: On Tue, 2015-01-06 at 16:07 -0700, Warren Young wrote: There is nothing new to be discovered in physics now. All that remains is more and more precise measurement.” — William Thomson, Lord Kelvin, 1900 Now means the current time. Now is not, and never will be, The (unknown) Future. Yyyyeah. Let’s rewrite the quote with that interpretation: “We have already discovered everything we are going to discover up to and including February 18, 1900.” — William Thomson, Lord Kelvin, 1900 Not exactly the sparkling sort of statement we expect from one of the most brilliant scientists ever to walk the planet, is it? Rather on the vapid side, yes? Could it be that that is not actually what he meant? Don’t like Kelvin? ‘Kay, how about this one: “The advancement of the arts, from year to year, taxes our credulity and seems to presage the arrival of that period when human improvement must end.” — Henry J. Ellsworth, Commissioner of the U.S. Patent Office, in the office's 1843 Annual Report I think we’ll figure out something new to do with computers tomorrow. Certainly by Friday at latest. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Jan 6, 2015, at 6:49 PM, John R. Dennison j...@gerdesas.com wrote: On Tue, Jan 06, 2015 at 06:37:42PM -0700, Warren Young wrote: Noise removed. Quick question, if I may? What does this have to do with CentOS? Some people are annoyed that CentOS keeps changing on them, and keep going to greater and greater lengths to try and argue that CentOS should not change. I am explaining to them why this is not a productive view. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Tue, 2015-01-06 at 20:19 -0600, Les Mikesell wrote: Is there any centralized approach to converting something that worked on CentOS6 to run on CentOS7? Does the program that is supposed to try to automatically upgrade versions have any tricks hidden away to fix things so they work after the upgrade, and could any of them be run separately? Brilliant task to assign to Warren Young. That will keep him away from his disruptive improvements philosophy. -- Regards, Paul. England, EU. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Tue, Jan 6, 2015 at 7:52 PM, Warren Young w...@etr-usa.com wrote: On Jan 6, 2015, at 6:49 PM, John R. Dennison j...@gerdesas.com wrote: On Tue, Jan 06, 2015 at 06:37:42PM -0700, Warren Young wrote: Noise removed. Quick question, if I may? What does this have to do with CentOS? Some people are annoyed that CentOS keeps changing on them, and keep going to greater and greater lengths to try and argue that CentOS should not change. No one has said it should not change. Just that it breaks all users existing work when it changes in non-backwards compatible ways. I am explaining to them why this is not a productive view. The non-productive part is that every user who has ever built anything of non-stable components has to deal with the problem on an individual basis. Is there any centralized approach to converting something that worked on CentOS6 to run on CentOS7? Does the program that is supposed to try to automatically upgrade versions have any tricks hidden away to fix things so they work after the upgrade, and could any of them be run separately? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] reboot - is there a timeout on filesystem flush?
On Tue, Jan 6, 2015 at 6:37 PM, Gary Greene ggre...@minervanetworks.com wrote: Almost every controller and drive out there now lies about what is and isn’t flushed to disk, making it nigh on impossible for the Kernel to reliably know 100% of the time that the data HAS been flushed to disk. This is part of the reason why it is always a Good Idea™ to have some sort of pause in the shut down to ensure that it IS flushed. This is also why server grade gear uses battery backed buffers, etc. which are supposed to allow drives to properly flush the data to disk. There is still a slim chance in these cases that the data still will not reach the platter before power off or reboot, especially in catastrophic cases. This was a reboot from software, not a power drop. Does that do something to kill the disk cache if anything happened to still be there? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] When will CentOS Publish Errata?
On 01/05/2015 04:37 PM, Johnny Hughes wrote: 2. If someone comes up with a place to get said data, THEN we could properly publish that data in some way. get it, then validate it, then we can push it as known correct. -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] dovecot move doesn't work
Am 06.01.2015 um 23:55 schrieb Chuck Campbell: I'm running centos 6.6 with the default 2.0.9-xxx dovecot. I run sa-learn against my spam_to_learn folder, then I wan to move those emails to a learned_spam folder. when I do a doveadm -Dv move -u user learned_spam mailbox 'spam_to_learn' ALL I get this result: usage: doveadm [-Dv] [-f formatter] command [args] [ ... ] this doesn't even list a move command, yet the dovecot pages show it and give examples. The dovecot version provided by CentOS 6 simply does not have that feature implemented. The wiki.dovecot.org documentation reflects the current stable upstream status of things. any suggestions? You may use the dovecot22 package provided by the ghettoforge plus repository, providing dovecot release 2.2.15. thanks, -chuck Alexander ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] reboot - is there a timeout on filesystem flush?
On 01/06/2015 04:37 PM, Gary Greene wrote: This has been discussed to death on various lists, including the LKML... Almost every controller and drive out there now lies about what is and isn’t flushed to disk, making it nigh on impossible for the Kernel to reliably know 100% of the time that the data HAS been flushed to disk. This is part of the reason why it is always a Good Idea™ to have some sort of pause in the shut down to ensure that it IS flushed. That's pretty much entirely irrelevant to the original question. (Feel free to correct me if I'm wrong in the following) A filesystem has three states: Clean, Dirty, and Dirty with errors. When a filesystem is unmounted, the cache is flushed and it is marked clean last. This is the expected state when a filesystem is mounted. Once a filesystem is mounted read/write, then it is marked dirty. If a filesystem is dirty when it is mounted, then it wasn't unmounted properly. In the case of a journaled filesystem, typically the journal will be replayed and the filesystem will then be mounted. The last case, dirty with errors indicates that the kernel found invalid data while the filesystem was mounted, and recorded that fact in the filesystem metadata. This will normally be the only condition that will force an fsck on boot. It will also normally result in logs being generated when the errors are encountered. If your filesystems are force-checked on boot, then the logs should usually tell you why. It's not a matter of a timeout or some device not flushing its cache. Of course, the other possibility is simply that you've formatted your own filesystems, and they have a maximum mount count or a check interval. Use 'tune2fs -l' to check those two values. If either of them are set, then there is no problem with your system. It is behaving as designed, and forcing a periodic check because that is the default behavior. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] reboot - is there a timeout on filesystem flush?
On 2015-01-07, Gordon Messmer gordon.mess...@gmail.com wrote: Of course, the other possibility is simply that you've formatted your own filesystems, and they have a maximum mount count or a check interval. If Les is having to run fsck manually, as he wrote in his OP, then this is unlikely to be the cause of the issues he described in that post. There must be some sort of errors on the filesystem that caused the unattended fsck to exit nonzero. --keith -- kkel...@wombat.san-francisco.ca.us ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Tue, Jan 06, 2015 at 06:37:42PM -0700, Warren Young wrote: Noise removed. Quick question, if I may? What does this have to do with CentOS? John -- Spring is nature's way of saying, Let's party! -- Robin Williams (1952-), American actor and comedian pgpNiv125meno.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Tue, 2015-01-06 at 18:51 -0700, Warren Young wrote: I think we’ll figure out something new to do with computers tomorrow. Certainly by Friday at latest. You seem to forget. Computers were invented to perform repetitive tasks. Computer usage should be serving mankind - not making it more difficult for mankind. -- Regards, Paul. England, EU. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Design changes are done in Fedora
On Tue, Jan 06, 2015 at 06:52:48PM -0700, Warren Young wrote: Some people are annoyed that CentOS keeps changing on them, and keep going to greater and greater lengths to try and argue that CentOS should not change. I am explaining to them why this is not a productive view. It's not relevant in _any_ sense. CentOS is nothing more than (at it's core) a rebuild of RHEL. This type of nonsense should be directed to Red Hat in a Red Hat venue. It's nothing but off-topic noise here as CentOS will not deviate from its upstream in its core offerings. John -- Much of what looks like rudeness in hacker circles is not intended to give offense. Rather, it's the product of the direct, cut-through-the-bullshit communications style that is natural to people who are more concerned about solving problems than making others feel warm and fuzzy. http://www.catb.org/esr/faqs/smart-questions.html pgpehGCA0QykK.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] reboot - is there a timeout on filesystem flush?
I've had a few systems with a lot of RAM and very busy filesystems come up with filesystem errors that took a manual 'fsck -y' after what should have been a clean reboot. This is particularly annoying on remote systems where I have to talk someone else through the recovery. Is there some time limit on the cache write with a 'reboot' (no options) command or is ext4 that fragile? -- Les Mikesell lesmikes...@gmail.com ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-docs] removing/redirecting the Projects page
On 01/06/2015 05:24 PM, Fabian Arrotin wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, We've decided to decomission the (old and unused) trac instance on projects.centos.org. We'll just redirect to git.centos.org instead (where all the fun happens). So, what to do with the http://wiki.centos.org/Projects page ? deleting it ? redireting to http://wiki.centos.org/SpecialInterestGroup (as now most of the things outside of Core happens through SIGs) redirect to SIG, please. ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS] Radeon graphics problems with CentOS 6.6
On 01/05/2015 11:26 PM, John R Pierce wrote: On 1/5/2015 9:24 PM, Darby Vicker wrote: He is suggesting I get in touch with the people who maintain the CentOS kernel. that would be Red Hat, unless you're talking about the CentOS Plus kernel This is correct .. we rebuild the RHEL 6.6 kernel source code as is, if this is a kernel problem, we don't change it. But .. IF the kernel does NEED a change, then the CentOSPlus kernel would be the place where we have the ability to add patches and change something. We don't change the base OS kernel except to remove branding. AKemi Yagi is our CentOS Plus maintainer, and bug/patch requests can be entered here: http://bugs.centos.org/view.php?id=4586 But, we do not provide technical support .. we have a community forum and bugs system to allow the community to discuss and solve problems. We will try/roll in patches (into CentOS Plus kernel) to try and fix problems if a solution is proposed by the community. However, we don't do the research or development. What I am trying to convey is that CentOS rebuilds upstream source code and provides resources for the community to solve their own problems. CentOS does not provide SLA level support. That is what RHEL is for. We will be glad to help the community find the problem, and feed back the fix upstream to Red Hat so they can fix it in RHEL and then we can roll it into our main OS kernel. And we will provide a temporary fix in the CentOS Plus kernel. signature.asc Description: OpenPGP digital signature ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS-docs] the install url on wiki.centos.org homepage
hi, The install link on the wiki.centos.org homepage could potentially use some attention. Maybe just lose it and send similar attention to the /Documenation page instead ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh GnuPG Key : http://www.karan.org/publickey.asc ___ CentOS-docs mailing list CentOS-docs@centos.org http://lists.centos.org/mailman/listinfo/centos-docs
Re: [CentOS] Radeon graphics problems with CentOS 6.6
On Tue, Jan 6, 2015 at 9:24 AM, Johnny Hughes joh...@centos.org wrote: On 01/05/2015 11:26 PM, John R Pierce wrote: On 1/5/2015 9:24 PM, Darby Vicker wrote: He is suggesting I get in touch with the people who maintain the CentOS kernel. that would be Red Hat, unless you're talking about the CentOS Plus kernel This is correct .. we rebuild the RHEL 6.6 kernel source code as is, if this is a kernel problem, we don't change it. But .. IF the kernel does NEED a change, then the CentOSPlus kernel would be the place where we have the ability to add patches and change something. We don't change the base OS kernel except to remove branding. AKemi Yagi is our CentOS Plus maintainer, and bug/patch requests can be entered here: http://bugs.centos.org/view.php?id=4586 Actually, I ask that people open a new ticket for each request. :) Akemi ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] When will CentOS Publish Errata?
On 2015-01-06, Johnny Hughes joh...@centos.org wrote: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===4697670779706124595== Content-Type: multipart/signed; micalg=pgp-sha1; protocol=application/pgp-signature; boundary=MBFscW2dH0g022mxj8O937qiaWFFIRB5O This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MBFscW2dH0g022mxj8O937qiaWFFIRB5O Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 01/06/2015 04:25 AM, Liam O'Toole wrote: On 2015-01-06, Somers-Harris, David | David | OPS david.somers-har...@mail.rakuten.com wrote: 1. Blatant screen scraping is a violation of the terms of service for RHN .. so where is a SOURCE of information for something like this: https://rhn.redhat.com/errata/RHSA-2014-2024.html If you read this: https://access.redhat.com/help/terms/ then, one can not just grab all the info on that errata page and distribute it .. which is why we LINK to it and not distribute it currently. So, the first issue is that one must find a source for the information that would go into the 'updateinfo.xml' file that is always maintained and is available to read and to redistribute. 2. If someone comes up with a place to get said data, THEN we could properly publish that data in some way. Thanks, Johnny Hughes Can't we just ask Red Hat if it's OK for CentOS to use the data for its updateinfo.xml? Is there some official communication channel between the CentOS Project and Red Hat? =20 Maybe you missed the big announcement: =20 http://lists.centos.org/pipermail/centos-announce/2014-January/020100.h= tml =20 Sure, but they aren't likely to let us. The purpose of CentOS within the Red Hat ecosystem is explained here: http://community.redhat.com/centos-faq/ CentOS is open source, so you can use it however you want and for what ever you are comfortable using it for .. however, giving special dispensation to violate terms of service of RHN to make CentOS more usable than it already is in the enterprise is not high on their priority list. They are not taking any action to make it in any way less usable, but they are also not going to do anything to make it easier either. What we need is a way to get that info from another place. Maybe the oval data, if it has all the required information and if the Terms of Service allow for that. Someone in the Community needs to research that and see if it is usable or if there is some other source for the information that can then be modified to create the updateinfo.xml file. Thanks for all that. My contribution was in response to the question Is there some official communication channel between the CentOS Project and Red Hat? I should have trimmed more carefully and saved you some keystrokes. -- Liam ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS-virt] Xen4CentOS python-virtinst version issue, blktap2 problem
On Tue, Jan 06, 2015 at 09:38:53AM -0500, Philippe-A. Lemelin wrote: On 15-01-06 09:21 AM, George Dunlap wrote: On Tue, Jan 6, 2015 at 11:42 AM, Pasi Kärkkäinen pa...@iki.fi wrote: Hello, It seems currently when you yum update CentOS 6.6 Xen host you end up getting python-virtinst from c6 base repo: python-virtinst-0.600.0-24.el6.noarch and not from Xen4CentOS repo, because the version there is older: 0.600.0-19. .. which means the centos/xen-specific patch in python-virtinst is lost. (default to tap2 instead of tap1, to make blktap2 work out-of-the-box with virt-install and virt-manager when using file based images as disks for VMs). So.. who can build a new version of python-virtinst, with the blktap2 patch applied? Looks like Johnny's built an updated version and placed it here: http://people.centos.org/hughesjr/xen4-test/ Maybe we can leave it there for a day or so for people to test it, and push it to the main xen4 repo at EOD tomorrow? -George I just successfully completed the installation of a CentOS guest with this version of python-virtinst. Yep, it works for me too! -- Pasi Thank you, Philippe-A. Lemelin ___ CentOS-virt mailing list CentOS-virt@centos.org http://lists.centos.org/mailman/listinfo/centos-virt
