Re: [CentOS] CentOS 8 updates
On 13/05/2020 01:22, Bill Maidment wrote: Hi Is it my imagination/impatience, but I don't seem to have received any updates to CentOS 8 recently. I'm thinking particularly of firefox which was updated in CentOS 7 for a critical security update. Is there a backlog of CentOS 8 updates behind the 8.2 release? I noticed on a few occasions that my local mirroring had picked up and later deleted a lot of "tmp" files for CentOS 8, is that an indication that something is on the way? I understand that everyone is struggling with Covid19 restrictions, so just tell me to get back into my isolation if I'm just a bit too impatient. Correct. These are updates to CentOS 8.2 which is in the works. Once CentOS 8.2 has been released, the 8.2 updates will flow shortly afterwards. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Updating microcode_ctl froze Centos7
On 14/06/2020 17:09, Robin Lee wrote: On Fri, 2020-06-12 at 09:20 +0200, Robin Lee wrote: Today when I ran yum update two packages came up microcode_ctl and unbound-libs. The updating process went fine until it outputted Running transaction Updating : 2:microcode_ctl-2.1-61.6.el7_8.x86_64 then it just froze. I could no longer ssh to the machine and the console was just blank. I had to shut down it hard. It came back up seemingly fine. But yum update doesn't work anymore. It says "Error importing repomd.xml from base/7/x86_64: Damaged repomd.xml file" I looked at the logs, but journalctl only shows the latest boot on this machine. So I guess I have three questions - Any idea what happened with the update process? - How can I repair repomd.xml? No suggestions about the best way to restore repomd.xml? /Robin Try: yum --enablerepo=\* clean all ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 17/06/2020 18:38, Michael Kofler wrote: Hi, I am the author of said blog article. FIRST: It was never my intention to criticize the CentOS team. I appreciate the hard work you are doing. If my blog text (which is in German langugage) gave a wrong impression, I apologize. SECOND: I LOVE CentOS. Otherwise it would not matter to me. I use CentOS to teach Linux administration at university, I promote CentOS in my books and I use it personally on some servers. THIRD: It is a fact that the update gaps for CentOS 8 are currently too long for productive use. Basically, that's why I now warn against using CentOS 8 on live systems. --- One might argue, CentOS was never intended for productive use. Perhaps I misunderstood this. And with me all administrators of some million web servers running on CentOS. Hm. Time to rethink? As far as I'm aware that has always been the case. Johnny has never been slow in coming forward and saying if you need updates, or a service level agreement, or support then you should buy RHEL. That is what it is for. If not, then use CentOS for free. But don't use CentOS for free on production servers and then shout or act surprised when you don't have updates on a timescale you consider appropriate. Nothing has changed in this regard for as long as I've been a CentOS user or been involved in the CentOS community. If you are now having to rethink your approach then you probably either haven't given it sufficient thought in the first place or you originally came to the wrong conclusion. This is a non-issue. Nothing has changed. Things were exactly the same with CentOS 4, CentOS 5, CentOS 6, CentOS 7, and by it's very nature it will be the same in CentOS 9... The simple matter is it takes time to rebuild a complete OS and there will always be a lag. Either that is acceptable to you and you use it, or you purchase a RHEL license for your publicly facing infrastructure. The only issue here is people's unrealistic expectations, and to be fair the CentOS Project can hardly be accused of falsely raising peoples expectations having consistently stated it will be ready when it's done for at least the last 15 years. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 17/06/2020 20:06, Noam Bernstein via CentOS wrote: On Jun 17, 2020, at 3:02 PM, Phil Perry wrote: Nothing has changed in this regard for as long as I've been a CentOS user or been involved in the CentOS community. This is the essence of the question, to me. I agree that _in_principle_ nothing has changed, and I don't even see any disagreement with that in the list. However, there is a separate question, and that is whether _in_practice_ the lag between RHEL and CentOS updates has increased with CentOS 8. I don't know what the answer is, because I'm not paying attention since I'm far from adopting CentOS 8, but it's a legitimate (and in fact empirical) question. I get what you are saying, but what difference does it make if it has? What does it matter if the lag is 1 week, or 1 month, or more? The only reason it will matter to you is if you are trying to do something with CentOS that is time critical - e.g, publicly facing server that needs security updates, using CentOS on test servers to validate production releases for RHEL, etc. At which point you probably should be using RHEL if it is important to you, not CentOS, and it was a mistake to deploy CentOS in those roles in the first place. People need to hold their hands up and say, I took a gamble that CentOS would get updates out quick and I wouldn't get hacked in a week, and now updates are taking a lot longer my gamble is no longer paying off and I need to get myself a RHEL subscription or switch to Ubuntu or whatever other flavor you like the taste of. Coming here and complaining when (you) made a bet and lost doesn't achieve anything. On my home file server for example, which is not connected to the internet, what does it matter if the release is 1 month or 3 months out of date? I can install the server in the knowledge it's going to work, and be supported with updates for 10 years and I can largely forget about it. My el5 box ran for more than 10 years until the hardware eventually died. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Blog article about the state of CentOS
On 17/06/2020 21:05, Lamar Owen wrote: On 6/17/20 3:32 PM, Phil Perry wrote: On my home file server for example, which is not connected to the internet, what does it matter if the release is 1 month or 3 months out of date? I can install the server in the knowledge it's going to work, and be supported with updates for 10 years and I can largely forget about it. My el5 box ran for more than 10 years until the hardware eventually died. EL5... how modern... from a production application server VM, not internet-connected: [root@c6-2850 ~]# ssh root@10.1.x.y root@10.1.x.y's password: Last login: Tue Jan 28 19:53:32 2020 unknown terminal "xterm-256color" unknown terminal "xterm-256color" [root@localhost root]# cat /etc/centos-release CentOS Linux Advanced Server release 2.1AS (Slurm) [root@localhost root]# This one has to be hard reset every day or two (virsh reset rhel2.1) since the bridge to the guest just dies randomly, and a reboot inside the guest hangs hard before finishing the reboot. The hard reset has to manually load the ethernet kernel module after it's booted up so far; if the ethernet module loads too soon it will never connect haven't found the reason for that, either, just run a pinging script every fifteen minutes on the host to check for connectivity and 'virsh reset rhel2.1' when it fails. The appserver is hard reboot resilient, and the software does a very specific task, and there's no budget for a rewrite. At least I did upgrade it from Red Hat Linux 5.2 a couple of years ago (the RHL5.2 box, an old AMD K6/2-450 with 128MB of RAM, ran almost continuously for 20 years). Thanks, CentOS! Indeed! You have clearly had more success with the longevity of your hardware than me. I was plagued with expanding capacitors about 15 years ago which killed off most of my hardware at the time, and the replacements were taken out of service as they subsequently died meaning I'm exclusively running el7|8 now :-) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RPMFusion and NVIDIA driver problem
On 29/06/2020 07:36, Alessandro Baggi wrote: Hi list, I'm on C8.1 and I'm trying to install NVIDIA driver from rpmfusion-nonfree repository but it returns: package kmod-nvidia-3:440.82-2.el8.x86_64 requires kmod-nvidia-4.18.0-147.el8.x86_64 >= 3:440.82-2.el8, but none of the providers can be installed - conflicting requests - nothing provides kernel < 4.18.0-148.el8 needed by The package is looking for an el8.1 kernel to meet it's dependencies and can not find one. C8.2 has now been released, and as a result all 8.1 packages got moved to vault. If you enable the vault repo, yum will be able to find the kernel package it is looking for to meet the dependencies. However, if you do that you will have to boot to an old C8.1 series kernel for your nvidia drivers to work. kmod-nvidia-4.18.0-147.el8.x86_64-3:440.82-2.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) and uname -r returns: 4.18.0-193.6.3.el8_2.x86_64 Yes, you are running the latest 8.2 series kernel. Seems that RPMFusion needs an update. Waiting for this there is a way to install this package without fall in problems? Thank you in advance. Yes, seems that repo is stale. They need to release packages built against el8.2, which at least for RHEL have been out for 2 months now. A newer stable nvidia driver (440.100) was also released recently. The (not ideal) workaround is as stated above - enable CentOS vault repo and boot into an older el8.1 series kernel for now until they update packages. I would normally recommend you try the nvidia drivers from elrepo, but I have a vested interest as I maintain them Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RPMFusion and NVIDIA driver problem
On 30/06/2020 08:33, Alessandro Baggi wrote: Il 29/06/20 16:02, Phil Perry ha scritto: On 29/06/2020 07:36, Alessandro Baggi wrote: Hi list, I'm on C8.1 and I'm trying to install NVIDIA driver from rpmfusion-nonfree repository but it returns: package kmod-nvidia-3:440.82-2.el8.x86_64 requires kmod-nvidia-4.18.0-147.el8.x86_64 >= 3:440.82-2.el8, but none of the providers can be installed - conflicting requests - nothing provides kernel < 4.18.0-148.el8 needed by The package is looking for an el8.1 kernel to meet it's dependencies and can not find one. C8.2 has now been released, and as a result all 8.1 packages got moved to vault. If you enable the vault repo, yum will be able to find the kernel package it is looking for to meet the dependencies. However, if you do that you will have to boot to an old C8.1 series kernel for your nvidia drivers to work. kmod-nvidia-4.18.0-147.el8.x86_64-3:440.82-2.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) and uname -r returns: 4.18.0-193.6.3.el8_2.x86_64 Yes, you are running the latest 8.2 series kernel. Seems that RPMFusion needs an update. Waiting for this there is a way to install this package without fall in problems? Thank you in advance. Yes, seems that repo is stale. They need to release packages built against el8.2, which at least for RHEL have been out for 2 months now. A newer stable nvidia driver (440.100) was also released recently. The (not ideal) workaround is as stated above - enable CentOS vault repo and boot into an older el8.1 series kernel for now until they update packages. I would normally recommend you try the nvidia drivers from elrepo, but I have a vested interest as I maintain them Phil Hi Phil, thank you for your answer. I tried with this after installing ELrepo repository: yum --enablerepo=elrepo install kmod-nvidia but I get the same result for different version. Hi Alessandro, You will need to provide more information for me to be able to help, like the errors you received. As a general rule, try not to mix elrepo and rpmfusion repos, or if you have to, do so carefully and manage any conflicts manually. You can usually tell which point release kernel series a kmod is built for by the tag in their release (e.g, el8.2 packages will have the elrepo.el8_2 release tag), so you can ensure you are installing / updating the correct package for your system. Regards, Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RPMFusion and NVIDIA driver problem
On 01/07/2020 07:58, Alessandro Baggi wrote: Il 30/06/20 17:41, Phil Perry ha scritto: On 30/06/2020 08:33, Alessandro Baggi wrote: Il 29/06/20 16:02, Phil Perry ha scritto: On 29/06/2020 07:36, Alessandro Baggi wrote: Hi list, I'm on C8.1 and I'm trying to install NVIDIA driver from rpmfusion-nonfree repository but it returns: package kmod-nvidia-3:440.82-2.el8.x86_64 requires kmod-nvidia-4.18.0-147.el8.x86_64 >= 3:440.82-2.el8, but none of the providers can be installed - conflicting requests - nothing provides kernel < 4.18.0-148.el8 needed by The package is looking for an el8.1 kernel to meet it's dependencies and can not find one. C8.2 has now been released, and as a result all 8.1 packages got moved to vault. If you enable the vault repo, yum will be able to find the kernel package it is looking for to meet the dependencies. However, if you do that you will have to boot to an old C8.1 series kernel for your nvidia drivers to work. kmod-nvidia-4.18.0-147.el8.x86_64-3:440.82-2.el8.x86_64 (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) and uname -r returns: 4.18.0-193.6.3.el8_2.x86_64 Yes, you are running the latest 8.2 series kernel. Seems that RPMFusion needs an update. Waiting for this there is a way to install this package without fall in problems? Thank you in advance. Yes, seems that repo is stale. They need to release packages built against el8.2, which at least for RHEL have been out for 2 months now. A newer stable nvidia driver (440.100) was also released recently. The (not ideal) workaround is as stated above - enable CentOS vault repo and boot into an older el8.1 series kernel for now until they update packages. I would normally recommend you try the nvidia drivers from elrepo, but I have a vested interest as I maintain them Phil Hi Phil, thank you for your answer. I tried with this after installing ELrepo repository: yum --enablerepo=elrepo install kmod-nvidia but I get the same result for different version. Hi Alessandro, You will need to provide more information for me to be able to help, like the errors you received. As a general rule, try not to mix elrepo and rpmfusion repos, or if you have to, do so carefully and manage any conflicts manually. You can usually tell which point release kernel series a kmod is built for by the tag in their release (e.g, el8.2 packages will have the elrepo.el8_2 release tag), so you can ensure you are installing / updating the correct package for your system. Regards, Phil Hi Phil, thank you for your answer. Currently I need RPMFusion for some packages so I cannot remove it. About my previous error about the command with --enablerepo=elrepo it gives me errors because it tries to install again rpmfusion packages so adding --disablerepo=rpmfusion-nonfree-updated will permit to install the driver but currently I remain with nouveau to avoid conflicts between elrepo and RPMFusion. Thank you for your help. Hi Alessandro, I tend to manually manage situations like that using package exclusions where competing packages are available from 2 different repositories. Regards, Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Iptables rules not working
On 16/07/2020 16:48, Kaushal Shriyan wrote: Hi, I am running CentOS Linux release 8.2.2004 (Core) on a remote server. I am running the below iptables command to allow SSH port 22 from a specific source IP 219.91.200.59 iptables -A INPUT -m tcp -p tcp -s 219.91.200.59 --dport 22 -j ACCEPT service iptables save The above iptables ruleset is not working and I am still able to connect from the internet to SSH port 22. I look forward to hearing from you and thanks in advance. Best Regards, Kaushal EL8 does not use iptables by default - it's been replaced with nftables. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] After update to 8 (2004) ... system is unbootable - UEFI Secure boot
On 29/07/2020 19:43, Leon Fauster via CentOS wrote: Did you got managed to boot kernel-4.18.0-193.14.2.el8_2 or a newer one? I must still boot into kernel-4.18.0-147.8.1.el8_1.x86_64 ... and with the upcoming new kernel that depends on a new shim and grub2 package I wonder about the implications for my XPS hardware ... The following article discusses a way to add a hash for older kernels to the Allow List that should allow older kernels to continue to boot: https://access.redhat.com/security/vulnerabilities/grub2bootloader Quoting... Red Hat Enterprise Linux 8 Due to hardening within the kernel, which is released as part of these updates, previous Red Hat Enterprise Linux 8 kernel versions have not been added to shim’s allow list. If you are running with Secure Boot enabled, and the user needs to boot to an older kernel version, its hash must be manually enrolled into the trust list. This is achieved by executing the following commands: # pesign -P -h -i /boot/vmlinuz- # mokutil --import-hash # reboot ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Boot failed on latest CentOS 7 update
On 02/08/2020 16:26, Valeri Galtsev wrote: On the side note: it is Microsoft that signs one of Linux packages now. We seem to have made one more step away from “our” computers being _our computers_. Am I wrong? Valeri Microsoft are the Certificate Authority for SecureBoot and most SB-enabled hardware (most x86 hardware) comes with a copy of the Microsoft key preinstalled allowing binaries that are signed by Microsoft to work. In the case of linux, that is the shim which becomes the root of trust to load everything else. If you are not happy with that you can always become your own certificate authority by generating your own keys, install your signing keys in the hardware's firmware (MOK list) and sign stuff yourself to use on your own machine(s). However if you wish to distribute stuff to others and have it work seamlessly on hardware outside of your direct control and without the need for every user to import your CA SecureBoot signing key into the MOK list on every device, you would rely on Microsoft to sign SB related content. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Boot failed on latest CentOS 7 update
On 02/08/2020 19:54, John Pierce wrote: On Sun, Aug 2, 2020 at 11:45 AM Phil Perry wrote: On 02/08/2020 16:26, Valeri Galtsev wrote: On the side note: it is Microsoft that signs one of Linux packages now. We seem to have made one more step away from “our” computers being _our computers_. Am I wrong? Valeri Microsoft are the Certificate Authority for SecureBoot and most SB-enabled hardware (most x86 hardware) comes with a copy of the Microsoft key preinstalled allowing binaries that are signed by Microsoft to work. In the case of linux, that is the shim which becomes the root of trust to load everything else. If you are not happy with that you can always become your own certificate authority by generating your own keys, install your signing keys in the hardware's firmware (MOK list) and sign stuff yourself to use on your own machine(s). However if you wish to distribute stuff to others and have it work seamlessly on hardware outside of your direct control and without the need for every user to import your CA SecureBoot signing key into the MOK list on every device, you would rely on Microsoft to sign SB related content. now, does Microsoft have to sign each released module themselves, or will they issue a CA cert to an authorized OS creator, like RH, then let RH sign their own modules? EG,Microsoft RootCA -> Signed Package vs, Microsoft RootCA -> RH Child CA -> Signed Package I believe Microsoft signs the shim which then becomes the trusted authority and embeds RH (or CentOS) signing cert, so (I believe) every release of the shim needs to be signed by Microsoft. So it's not quite as efficient as MS signing a RH/CentOS CA key, but is not far off. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 shim fix failed
On 05/08/2020 10:40, Kenneth Porter wrote: Is there some way we could get the initrd rebuild to be more verbose, so that it doesn't appear to hang? It would be nice to get feedback that something is happening, especially on an older, slower system that takes a long time for this step. Not without hacking the underlying scripts that call dracut to increase the verbosity. You can run yum at a more verbose debug level, but it's not going to give you information on the state of individual rpm scriptlets. You could monitor the process in top where you should be able to see that it's still working. You can also monitor /var/log/messages where dracut activity is logged. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] rsync upgrade
On 06/08/2020 17:30, Jack Bailey via CentOS wrote: On 2020-08-06 08:45, J Martin Rushton via CentOS wrote: You'll need to upgrade to CentOS8. C7 is at rsync 3.1.2-10, and will not go above 3.1.2 ever. C8.2 is at 3.1.3-7, C8 will always be on 3.1.3 Martin Another option is to build rsync from source, which is what I did to try out the zstd compression. Or you could try rebuilding the latest fedora SRPM on el7 (or the RHEL8 SRPM if that is new enough for you). Sometimes it's straight forward, other times this approach may fail with newer build requirements than those provided by el7. Worth a try though. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Fixing grub/shim issue Centos 7
On 07/08/2020 10:01, Johnny Hughes wrote: On 8/7/20 3:46 AM, Nicolas Kovacs wrote: Le 07/08/2020 à 09:40, Alessandro Baggi a écrit : Probably many users have not updated their machines between the bug release and the resolution (thanks to your fast apply in the weekend, thank you) and many update their centos machines on a 2 months base (if not worst). I think also that many users of CentOS user base have not proclamed their disappointement/the issue on this list or in other channels. For example I simply updated in the wrong time. I'm using yum-cron to keep all my server updated on a daily basis. And my question "How could this have passed Q & A" was obviously directed at Red Hat... and *not* at Johnny Hughes and the CentOS team who do their best to deliver the best possible downstream system. I raise my morning coffee mug to your health, guys. Cheers, Niki I can assure you .. a BUNCH of testing was done. Because of the scope of this udpate, the CentOS team was looped in during the embargo stage (we normally are not .. Red Hat Engineering got permission to make this happen for this issue). Normally we see things that are open source only .. not embargoed content. Once the embargo gets lifted, the items become open source. Kudos to the RH team for making this happen. The CentOS team worked with the RHEL team on this update for several days (more than a week, for sure, maybe 2 weeks) I gained MUCH respect for all those guys .. especially Peter Jones. He is Mr.Secure Boot. I personally tested both the c8 and c7 solutions on several machines (All i have access to actually, including several personal machines that have secureboot). I saw some of the testing that happened on the RHEL side. It was extensive. I'll just add to Johnny's already comprehensive reply. As a member of the CentOS QA team, I personally tested the update on 3 physical machines and all worked fine. Moreover, the QA team was not able to replicate the issue on a single physical machine available to them - the first indication of a problem came from public reports. We give up a huge amount of our personal time and resources to ensure CentOS (and RHEL) are the very best products they can be. I'm unsure what more could have been done. Microsoft, Debian, Ubuntu and others also had issues with this .. so if you are losing trust, you are losing it with all OS vendors WRT this issue. All I can say is .. this issue was the hardest thing I have been involved with since starting with the CentOS Project 17 years ago. Obviously, everyone involved in this build would have prevented this from happening if they could have. Secureboot is complicated. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ZFS fails with latest C8 kernel
On 10/08/2020 07:43, Robert G (Doc) Savage via CentOS wrote: As if last weekend's UEFI debacle wasn't bad enough, it now seems the latest C8 kernel (4.18.0-193.14.2) is incompatible with the current ZFSOnLinux packages (0.8.4-1). When booted to the latest kernel, ZFS is inaccessible on my C8 storage server. When I back off to the prior kernel (4.18.0-193.6.3), all is well. If a local ZFS system is unavailable to the C8 kernel support folks, I'll be happy to assist them by volunteering my system as a lab rat. CentOS doesn't have 'C8 kernel support folks' because CentOS does not offer support. You would need to file a bug upstream with Red Hat, but I doubt they will be interested as they do not ship ZFS nor support it. I think you are likely on your own on this one. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A Request to Add module to CentOS Linux (3.10.0-1127.18.2.el7.x86_64) 7 (Core)
On 11/09/2020 07:59, Dedoep wrote: Hello John & Frank, We have tried both Centos8 and installing kernel-ml-5.8.6-2.el7.elrepo.x86_64.rpm but both options are too "bleeding" edge for our other middleware that still require the Centos 7 3.10.0-1127.18.2.el7.x86_64. Hence the request. Thanks I have tried backporting the module to el7 for you as requested at elrepo, but it is not trivial and so far I've not been able to get the code to compile cleanly. I'll see if I can have another look at it this weekend, but I'm not overly hopeful given the age of the el7 kernel. As others have said, it's never going to appear in the CentOS kernel as it's not present in upstream in RHEL7. Regards, Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A Request to Add module to CentOS Linux (3.10.0-1127.18.2.el7.x86_64) 7 (Core)
On 15/09/2020 05:28, Dedoep wrote: Hi Phil, Not sure if you've had time to look at this? As mentioned middleware, like docker-ce, is preventing us from moving to el8. Thanks Dan Hi Dan, I've succeeded in backporting mac802154_hwsim for you as a standalone kmod package for el7. I've updated your request here: https://elrepo.org/bugs/view.php?id=1035 Phil On Fri, Sep 11, 2020 at 10:33 PM Dedoep wrote: Hi Phil, ok that's great thanks. I have a colleague working through vroc/fake raid issues we're having when using kernel-ml-5.8.6-2.el7.elrepo.x86_64.rpm by switching to linux soft raid. Also we dont have a supported docker-ce for el8 yet. On Fri, Sep 11, 2020 at 9:10 PM Phil Perry wrote: On 11/09/2020 07:59, Dedoep wrote: Hello John & Frank, We have tried both Centos8 and installing kernel-ml-5.8.6-2.el7.elrepo.x86_64.rpm but both options are too "bleeding" edge for our other middleware that still require the Centos 7 3.10.0-1127.18.2.el7.x86_64. Hence the request. Thanks I have tried backporting the module to el7 for you as requested at elrepo, but it is not trivial and so far I've not been able to get the code to compile cleanly. I'll see if I can have another look at it this weekend, but I'm not overly hopeful given the age of the el7 kernel. As others have said, it's never going to appear in the CentOS kernel as it's not present in upstream in RHEL7. Regards, Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] storage for mailserver
On 16/09/2020 17:11, Michael Schumacher wrote: hi, I am planning to replace my old CentOS 6 mail server soon. Most details are quite obvious and do not need to be changed, but the old system was running on spinning discs and this is certainly not the best option for todays mail servers. With spinning discs, HW-RAID6 was the way to go to increase reliability and speed. Today, I get the feeling, that traditional RAID is not the best option for SSDs. I am reading that all RAID members in SSD-arrays age synchronously so that the risk of a massive failure of more than one disk is more likely than with HDDs. There are many other concerns like excessive write load compared to non-raid systems, etc. Is there any common sense what disk layout should be used these days? I have been looking for some kind of master-slave system, where the (one or many) SSD is taking all writes and reads, but the slave HDD runs in parallel as a backup system like in a RAID1 system. Is there any such system? Any thoughts? You can achieve this with a hybrid RAID1 by mixing SSDs and HDDs, and marking the HDD members as --write-mostly, meaning most of the reads will come from the faster SSDs retaining much of the speed advantage, but you have the redundancy of both SSDs and HDDs in the array. Read performance is not far off native write performance of the SSD, and writes mostly cached / happen in the background so are not so noticeable on a mail server anyway. I kind of stumbled across this setup by accident when I added an NVMe SSD to an existing RIAD1 array consisting of 2 HDDs. # cat /proc/mdstat Personalities : [raid1] md127 : active raid1 sda1[2](W) sdb1[4](W) nvme0n1p1[3] 485495616 blocks super 1.0 [3/3] [UUU] bitmap: 3/4 pages [12KB], 65536KB chunk See how we have 3 devices in the above RAID1 array, 2 x HDDs, marked with a (W) indicating they are in --write-mostly mode, and one SSD (MVMe) device. I just went for 3 devices in the array as it started life as a 2 x HDD array and I added the third SSD device, but you can mix and match to suit your needs. See the following article which may be helpful or search 'mdadm write-mostly' for more info. https://www.tansi.org/hybrid/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] storage for mailserver
On 17/09/2020 13:35, Michael Schumacher wrote: Hello Phil, Wednesday, September 16, 2020, 7:40:24 PM, you wrote: PP> You can achieve this with a hybrid RAID1 by mixing SSDs and HDDs, and PP> marking the HDD members as --write-mostly, meaning most of the reads PP> will come from the faster SSDs retaining much of the speed advantage, PP> but you have the redundancy of both SSDs and HDDs in the array. PP> Read performance is not far off native write performance of the SSD, and PP> writes mostly cached / happen in the background so are not so noticeable PP> on a mail server anyway. very interesting. Do you or anybody else have experience with this setup? Any test results to compare? I will do some testing if nobody can come up with comparisons. best regards --- Michael Schumacher Here's a few performance stats from my setup, made with fio. Firstly a RAID1 array from 2 x WD Black 1TB drives. Second set of figures are the same are for a RAID1 array with the same 2 WD Black 1TB drives and a WD Blue NVMe (PCIe X2) added into the array, with the 2 X HDDs set to --write-mostly. Sequential write QD32 147MB/s (2 x HDD RAID1) 156MB/s (1 x NVMe, 2 x HDD RAID1) The write tests give near identical performance with and without the SSD in the array as once any cache has been saturated, write speeds are presumably limited by the slowest device in the array. Sequential read QD32 187MB/s (2 x HDD RAID1) 1725MB/s (1 x NVMe, 2 x HDD RAID1) Sequential read QD1 162MB/s (2 x HDD RAID1) 1296MB/s (1 x NVMe, 2 x HDD RAID1) 4K random read 712kB/s (2 x HDD RAID1) 55.0MB/s (1 x NVMe, 2 x HDD RAID1) The read speeds are a completely different story, and the array essentially performs identically to the native speed of the SSD device once the slower HDDs are set to --write-mostly, meaning the reads are prioritized to the SSD device. The SSD NVMe device is limited to PCIe X2 hence why sequential read speeds top out at 1725MB/s. Current PCIe X4 devices should be able to double that. To summarize, a hybrid RAID1 mixing HDDs and SSDs will have write performance similar to the HDD (slowest device) and read performance similar to the SSD (fastest device) as long as the slower HDDs are added to the array with the --write-mostly flag set. Obviously these are synthetic I/O tests and may not reflect real world application performance but at least give you a good idea where the underlying bottlenecks may be. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] storage for mailserver
On 19/09/2020 19:19, Chris Schanzle via CentOS wrote: On 9/17/20 4:25 PM, Phil Perry wrote: On 17/09/2020 13:35, Michael Schumacher wrote: Hello Phil, Wednesday, September 16, 2020, 7:40:24 PM, you wrote: PP> You can achieve this with a hybrid RAID1 by mixing SSDs and HDDs, and PP> marking the HDD members as --write-mostly, meaning most of the reads PP> will come from the faster SSDs retaining much of the speed advantage, PP> but you have the redundancy of both SSDs and HDDs in the array. PP> Read performance is not far off native write performance of the SSD, and PP> writes mostly cached / happen in the background so are not so noticeable PP> on a mail server anyway. very interesting. Do you or anybody else have experience with this setup? Any test results to compare? I will do some testing if nobody can come up with comparisons. best regards --- Michael Schumacher Here's a few performance stats from my setup, made with fio. Firstly a RAID1 array from 2 x WD Black 1TB drives. Second set of figures are the same are for a RAID1 array with the same 2 WD Black 1TB drives and a WD Blue NVMe (PCIe X2) added into the array, with the 2 X HDDs set to --write-mostly. Sequential write QD32 147MB/s (2 x HDD RAID1) 156MB/s (1 x NVMe, 2 x HDD RAID1) The write tests give near identical performance with and without the SSD in the array as once any cache has been saturated, write speeds are presumably limited by the slowest device in the array. Sequential read QD32 187MB/s (2 x HDD RAID1) 1725MB/s (1 x NVMe, 2 x HDD RAID1) Sequential read QD1 162MB/s (2 x HDD RAID1) 1296MB/s (1 x NVMe, 2 x HDD RAID1) 4K random read 712kB/s (2 x HDD RAID1) 55.0MB/s (1 x NVMe, 2 x HDD RAID1) The read speeds are a completely different story, and the array essentially performs identically to the native speed of the SSD device once the slower HDDs are set to --write-mostly, meaning the reads are prioritized to the SSD device. The SSD NVMe device is limited to PCIe X2 hence why sequential read speeds top out at 1725MB/s. Current PCIe X4 devices should be able to double that. To summarize, a hybrid RAID1 mixing HDDs and SSDs will have write performance similar to the HDD (slowest device) and read performance similar to the SSD (fastest device) as long as the slower HDDs are added to the array with the --write-mostly flag set. Obviously these are synthetic I/O tests and may not reflect real world application performance but at least give you a good idea where the underlying bottlenecks may be. Too bad the 4k random write tests are missing above. 4k random writes QD1 with fsync=1 56.6kB/s (2 x HDD RAID1) 77.8kB/s (1 x NVMe, 2 x HDD RAID1) with fsync=1000 1431kB/s (2 x HDD RAID1) 1760kB/s (1 x NVMe, 2 x HDD RAID1) I have used SSD + HDD RAID1 configurations in dozens of CentOS desktops and servers for years and it works very well with the --write-mostly flag being set on the HDD. With most reads coming from the SSD, starting programs are much quicker. However, I find the write queue to be very, very small, so the system "feels" like a slow HDD system during writing. Yes, as per above, 4k random write performance is similar to that of a pure HDD RAID array. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 8 LSI SAS2004 Driver
On 20/09/2020 04:16, Akemi Yagi wrote: On Sat, Sep 19, 2020 at 8:04 PM William Markuske wrote: Hello, I've recently been given domain over a number of supermicro storage servers using Broadcom / LSI SAS2004 PCI-Express Fusion-MPT SAS-2 [Spitfire] (rev 03) to run a bunch of SSDs. I was attempting to do fresh installs of CentOS 8 and have come to find out that RedHat deprecated support for a number of HBAs for 8 including all running the SAS2004 chip. Does anyone know if there is a driver available for this chip from a third party repo? My google searches have led me to believe that EPEL 8 has a kmod-mpt3sas package but it does not seem to exist though multiple blogs have stated otherwise. If anyone knows if there is a solution for CentOS 8 that would be great or if I have to roll back to CentOS 7 for card support. Thanks, William It is ELRepo, not EPEL. :) http://elrepoproject.blogspot.com/2019/08/rhel-80-and-support-for-removed-adapters.html Akemi I'm pretty sure your device requires the kmod-mpt3sas driver from elrepo (not EPEL!), but would need to see the pci device id (from 'lspci -nn') to be sure. If you are installing to this device, disk ISO images for the driver are available for use at install time: https://elrepo.org/linux/dud/el8/x86_64/ Make sure you pick the image that matches the point release you are installing (e.g, el8.0, el8.1, el8.2 etc). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mail server troubles
On 09/10/2020 16:42, Ian Pilcher wrote: On 10/8/20 4:49 PM, Nicolas Kovacs wrote: The school's not happy because in their eyes I'm faulty of badly maintaining their mail server. As someone with school age children, I've observed that schools seem to have a vastly over-inflated view of the importance of their communications. I've provided my email address to my children's schools as an EMERGENCY contact method, and I've been receiving notifications of every single fund raising activity, athletic event, PTA meeting, etc., etc., ever since - despite multiple complaints. It seems likely to me that the school's emails are being reported as spam by their recipients. Tell them to look in the mirror. Further, you need to explain to them that *you* are only responsible for the policies which dictate which emails *you* accept. You can not mandate other people to accept your mail. It is their mail server and they are completely within their rights to run it how they see fit, and they will. Of course one hopes you are following industry best practices to aid your deliverability, but ultimately you are not in control of what others are willing to accept. If they do not understand this, flip it around and ask them how they feel about a spammer insisting you accept their spam and deliver it to all the staff and pupils. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Password manager for the command line ?
On 23/11/2020 11:42, Marek Blaha wrote: There is also a command line interface for keepass - if you wouldn't mind perl dependency. https://sourceforge.net/projects/kpcli/ -- Marek Blaha Red Hat Czech s.r.o. Software Engineer I've not personally used the CLI, but there is a command line interface for KeePassXC too, see here for usage: http://manpages.ubuntu.com/manpages/bionic/man1/keepassxc-cli.1.html Hope that helps. On Mon, Nov 23, 2020 at 9:24 AM Nicolas Kovacs wrote: Hi, On my workstation and my laptop I'm using KeePassXC to store login credentials for my websites. The database is stored in my OwnCloud share, so it's synchronized between my two computers. Ideally I'd like to have something similar for my servers, but command-line driven. I know these tools exist but I haven't tested them yet. What I have in mind is a command-line password manager that stores the database in an encrypted database - like KeePassXC - and then I could eventually store this file in a private Gitlab repo to centralize it and access it from all my servers. Can you recommend any particular command line password manager ? Any recommendations / caveats for this kind of setup ? Cheers from the locked down South of France, Niki ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Replacing SW RAID-1 with SSD RAID-1
On 23/11/2020 15:49, Frank Bures wrote: On 11/23/20 10:46 AM, Simon Matter wrote: Hi, I want to replace my hard drives based SW RAID-1 with SSD's. What would be the recommended procedure? Can I just remove one drive, replace with SSD and rebuild, then repeat with the other drive? I suggest to "mdadm --fail" one drive, then "mdadm --remove" it. After replacing the drive you can "mdadm --add" it. If you boot from the drives you also have to care for the boot loader. I guess this depends on how exactly the system is configured. Thanks, that's what I had in mind. Of course, I will rebuild grab2 after each iteration. Thanks Fra You could also grow the array to add in the new devices before removing the old HDDs ensuring you retain at least 2 devices in the array at any one time. For example, in an existing raid of sda1 and sdb1, add in sdc1 before removing sda1 and add sdd1 before removing sdb1, finally shrinking the array back to 2 devices: mdadm --grow /dev/md127 --level=1 --raid-devices=3 --add /dev/sdc1 mdadm --fail /dev/md127 /dev/sda1 mdadm --remove /dev/md127 /dev/sda1 mdadm /dev/md127 --add /dev/sdd1 mdadm --fail /dev/md127 /dev/sdb1 mdadm --remove /dev/md127 /dev/sdb1 mdadm --grow /dev/md127 --raid-devices=2 then reinstall grub to sdc and sdd once everything has fully sync'd: blockdev --flushbufs /dev/sdc1 blockdev --flushbufs /dev/sdd1 grub2-install --recheck /dev/sdc grub2-install --recheck /dev/sdd ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On 09/12/2020 03:26, Brendan Conoboy wrote: On Tue, Dec 8, 2020 at 4:19 PM Pete Biggs wrote: On Tue, 2020-12-08 at 17:54 -0500, Matthew Miller wrote: On Tue, Dec 08, 2020 at 03:15:17PM +, Pete Biggs wrote: "CentOS will become the developer playground" This one is categorically not the case. Even Fedora isn't a developer playground. Everything landing in CentOS Stream is actually *planned* (with emphasis intentional) to go in a future RHEL release. It's all the talk of SIGs and developing and testing and that Stream will be the centerpiece of that. That's what I meant. I don't know if I'd call SIGs a playground, but they're certainly an important venue for communities to explore variations. Previously, all the development around RHEL releases was done in secret, in the Red Hat black box. Now it's out of the box and can be watched. There may be some launch pains, but I expect the average quality of an update hitting CentOS Stream to be very high. I don't get that from the documents released today. If Stream is *not* a test-bed, then surely the code that appears in Stream must be fully formed in secret behind the scenes first. Yes, it will appear piecemeal rather than in one big chunk, but it has been categorically denied that Stream is not a RHEL 8.n+1 beta and is more a RHEL 8.n+1 RC/rolling release. I think maybe some of the nervousness about CentOS Stream comes from RHEL seeming opacity on its development model. As one of the architects of our development process I'd be happy to field questions. I'll start by making a two points in case they're in any way unclear: 1. Everything that goes into RHEL lands upstream first, then the patches are backported into the RHEL releases. 2. Most of the work we do or plan on doing is in bugzilla.redhat.com. If you go into the RHEL8 product queue today and file a bug you'll see "CentOS Stream" as a "Version" where an issue is encountered. I think what a lot of people are concerned about is the rolling-release aspect of this. There will be no definitive versioning of CentOS in the future - all you will be able to say is "fully updated" and it won't be possible to slot a CentOS system in to exactly match a RHEL version. Will third party RPMs built against RHEL 8.x be installable on a CentOS 8 Stream system? The answer is surely "it depends", but there are a lot of hardware vendors that target drivers to RHEL releases, which may well make CentOS non-viable for hardware that doesn't have drivers built in to the kernel. Generally if they follow the ABI guidelines I would expect it to work. Those are here: https://access.redhat.com/articles/rhel8-abi-compatibility For loadable kernel modules there's a kernel ABI. Hi Brendan, This point is *critical*, so I apologise in advance for the lengthy post, *you* are breaking the kernel ABI between RHEL8 and Stream. One of the main unique selling points of RHEL is the stability of it's kernel ABI. No other distro provides this. The very nature of rolling kernel updates in Stream breaks the kernel ABI and breaks compatibility between RHEL8 and Stream. What works on RHEL8 may not work on Stream. At the kernel level, the two products diverge in fundamental compatibility and are not compatible, are no longer the same. How bad is this divergence / breakage? Well, we know the kernel ABI will change from time to time, almost exclusively at new point releases due to the massive backporting work that goes into the RHEL kernel. And this is fine, we know it's coming, we know when it's coming, and we can plan for it's impact. It's a price well worth paying. To put this in context, at elrepo I currently help maintain around 50 3rd party kernel driver packages for RHEL8. When RH released RHEL8.3, every single package in our repository broke due to changes in the kernel ABI in the 6 month period between RHEL8.2 and RHEL8.3. It's not ideal, but we accept it as a price we pay for the otherwise excellent stability of the kernel ABI during the proceeding 6 months. As I said above, we know it's coming, we know when it's coming, and we can plan for it. Now contrast that with Stream. Every kernel update in Stream has the potential to break the kernel ABI causing packages built for RHEL to break. We don't know when that may happen (only that it will), we don't know how often it will happen, we have no idea which packages it will break. and we have no way to fix it. Consequently, elrepo has been unable to support Stream kernels. It is not just elrepo's users that the Stream kernels will affect. All OEM hardware manufacturers releasing 3rd party driver rpms as part of Red Hat's Driver Update Programme or otherwise will be similarly affected, and their driver updates will not be applicable to or compatible with CentOS Stream. In fact, RHEL's own driver update packages will likely need rebuilding against each Stream kernel update, although presumably you are in the unique po
Re: [CentOS] [EXT] Re: https://blog.centos.org/2020/12/future-is-centos-stream/
On 09/12/2020 17:32, Peter Georg wrote: On 09/12/2020 18.10, Brendan Conoboy wrote: On Wed, Dec 9, 2020 at 7:21 AM Phil Perry wrote: On 09/12/2020 03:26, Brendan Conoboy wrote: On Tue, Dec 8, 2020 at 4:19 PM Pete Biggs wrote: On Tue, 2020-12-08 at 17:54 -0500, Matthew Miller wrote: On Tue, Dec 08, 2020 at 03:15:17PM +, Pete Biggs wrote: "CentOS will become the developer playground" This one is categorically not the case. Even Fedora isn't a developer playground. Everything landing in CentOS Stream is actually *planned* (with emphasis intentional) to go in a future RHEL release. It's all the talk of SIGs and developing and testing and that Stream will be the centerpiece of that. That's what I meant. I don't know if I'd call SIGs a playground, but they're certainly an important venue for communities to explore variations. Previously, all the development around RHEL releases was done in secret, in the Red Hat black box. Now it's out of the box and can be watched. There may be some launch pains, but I expect the average quality of an update hitting CentOS Stream to be very high. I don't get that from the documents released today. If Stream is *not* a test-bed, then surely the code that appears in Stream must be fully formed in secret behind the scenes first. Yes, it will appear piecemeal rather than in one big chunk, but it has been categorically denied that Stream is not a RHEL 8.n+1 beta and is more a RHEL 8.n+1 RC/rolling release. I think maybe some of the nervousness about CentOS Stream comes from RHEL seeming opacity on its development model. As one of the architects of our development process I'd be happy to field questions. I'll start by making a two points in case they're in any way unclear: 1. Everything that goes into RHEL lands upstream first, then the patches are backported into the RHEL releases. 2. Most of the work we do or plan on doing is in bugzilla.redhat.com. If you go into the RHEL8 product queue today and file a bug you'll see "CentOS Stream" as a "Version" where an issue is encountered. I think what a lot of people are concerned about is the rolling-release aspect of this. There will be no definitive versioning of CentOS in the future - all you will be able to say is "fully updated" and it won't be possible to slot a CentOS system in to exactly match a RHEL version. Will third party RPMs built against RHEL 8.x be installable on a CentOS 8 Stream system? The answer is surely "it depends", but there are a lot of hardware vendors that target drivers to RHEL releases, which may well make CentOS non-viable for hardware that doesn't have drivers built in to the kernel. Generally if they follow the ABI guidelines I would expect it to work. Those are here: https://access.redhat.com/articles/rhel8-abi-compatibility For loadable kernel modules there's a kernel ABI. Hi Brendan, This point is *critical*, so I apologise in advance for the lengthy post, *you* are breaking the kernel ABI between RHEL8 and Stream. One of the main unique selling points of RHEL is the stability of it's kernel ABI. No other distro provides this. The very nature of rolling kernel updates in Stream breaks the kernel ABI and breaks compatibility between RHEL8 and Stream. What works on RHEL8 may not work on Stream. At the kernel level, the two products diverge in fundamental compatibility and are not compatible, are no longer the same. How bad is this divergence / breakage? Well, we know the kernel ABI will change from time to time, almost exclusively at new point releases due to the massive backporting work that goes into the RHEL kernel. And this is fine, we know it's coming, we know when it's coming, and we can plan for it's impact. It's a price well worth paying. To put this in context, at elrepo I currently help maintain around 50 3rd party kernel driver packages for RHEL8. When RH released RHEL8.3, every single package in our repository broke due to changes in the kernel ABI in the 6 month period between RHEL8.2 and RHEL8.3. It's not ideal, but we accept it as a price we pay for the otherwise excellent stability of the kernel ABI during the proceeding 6 months. As I said above, we know it's coming, we know when it's coming, and we can plan for it. Now contrast that with Stream. Every kernel update in Stream has the potential to break the kernel ABI causing packages built for RHEL to break. We don't know when that may happen (only that it will), we don't know how often it will happen, we have no idea which packages it will break. and we have no way to fix it. Consequently, elrepo has been unable to support Stream kernels. It is not just elrepo's users that the Stream kernels will affect. All OEM hardware manufacturers releasing 3rd party driver rpms as part of
Re: [CentOS] https://blog.centos.org/2020/12/future-is-centos-stream/
On 10/12/2020 03:55, Brendan Conoboy wrote: On Wed, Dec 9, 2020 at 6:07 PM Lamar Owen wrote: On 12/9/20 12:10 PM, Brendan Conoboy wrote: While I'm not sure how we'll get there, it seems like the mutually satisfying end result would be one where third party binary drivers work with CentOS Stream kernels. Let's see what we can do. So, I want to address this part a bit. In MANY cases, it's not a third-party driver that ELrepo packages; it's an in-kernel driver that Red Hat has decided to disable. Such as the megaraid_sas driver I need for my servers. Ah yes, that's a great call-out. I'm not sure what the plan is there (or if there is one), but to me it seems like the sort of thing a SIG would build. Well, yes, about 10 years too late for those discussions I'm afraid ;-) And besides, why on earth would Red Hat remove support for older hardware that you (understandably) no longer want to commit resources to maintaining, only to turn round and commit resources to maintaining them in a SIG? That's why you guys reached out to us (elrepo) in the first place. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream from bottom works, what is this?
On 10/12/2020 17:20, Matthew Miller wrote: On Thu, Dec 10, 2020 at 12:11:51PM -0500, Phelps, Matthew wrote: Yeah, I have some sysadmin friends already working on exactly this for their deployment in a large-scale academic setting. Do you not see the huge irony here? Why should a sysadmin have to do this? We shouldn't. Well, I don't think you have to. But it's open source and it's cool that you *can* do things like this if you want to. LOL, did you do that deliberately or did you honestly not get what Matthew (Phelps) was saying? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between CentOS Linux and CentOS Stream?
On 15/12/2020 15:29, Turritopsis Dohrnii Teo En Ming wrote: Good day from Singapore, What are the differences between CentOS Linux and CentOS Stream? At the moment, I only know that CentOS 8 support will end on 31 December 2021 while Red Hat Inc will shift its focus to CentOS Stream. Is CentOS Stream going to be very similar to Fedora Linux, shipping with the latest Linux Kernel like 5.10.1? No. Stream kernel updates will be updates on the (current) path from RHEL8.3 -> RHEL8.4 so the base kernel will always be 4.18.0 (for Stream tracking RHEL8) I am looking forward to hearing from you. Thank you. Some notable differences: 1. 5 Years support versus 10 years support on RHEL/CentOS Linux. 2. Kernel updates break 3rd party out-of-tree kernel drivers. 3. 'dnf downgrade foo' doesn't work as only latest/one copy of each package in Stream repository so no opportunity to downgrade/roll back broken packages. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between CentOS Linux and CentOS Stream?
On 15/12/2020 17:09, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote: On Dec 15, 2020, at 12:07 PM, Phil Perry wrote: 3. 'dnf downgrade foo' doesn't work as only latest/one copy of each package in Stream repository so no opportunity to downgrade/roll back broken packages. Really? I hadn't appreciated that. How does one the contribute back to RH/the community by checking at what point something broke? No idea. I assume it might be related to repository size, as once daily updates start flowing into Stream, repo size could get rather large rather quickly? But it doesn't sit well being asked to test (and feedback) on testing packages with no way to roll back / downgrade when things break. 'dnf downgrade' isn't something I (thankfully) have to use often, but when you need it, it's a lifesaver. Seems like a regression to me. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between CentOS Linux and CentOS Stream?
On 15/12/2020 17:13, Matthew Miller wrote: On Tue, Dec 15, 2020 at 05:09:39PM +, Bernstein, Noam CIV USN NRL (6393) Washington DC (USA) via CentOS wrote: 3. 'dnf downgrade foo' doesn't work as only latest/one copy of each package in Stream repository so no opportunity to downgrade/roll back broken packages. Really? I hadn't appreciated that. How does one the contribute back to RH/the community by checking at what point something broke? I don't know the answer here but it's a good point to raise. In Fedora, we don't keep all updates on our mirrors either, but we _do_ make them accessible forever from our build system (https://koji.fedoraproject.org/koji/), and there's a command-line tool for easily pulling the packages from a build. No disrespect Matthew, but this isn't fedora. On Enterprise Linux systems users expect long-established tools like 'yum/dnf downgrade' to just work, and when they don't, that's something that needs fixing. Users should not be expected to go rooting around on build systems trying to find old copies of packages to fix things that shouldn't have broken in the first place. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between CentOS Linux and CentOS Stream?
On 15/12/2020 17:51, Leon Fauster via CentOS wrote: Am 15.12.20 um 18:07 schrieb Phil Perry: 3. 'dnf downgrade foo' doesn't work as only latest/one copy of each package in Stream repository so no opportunity to downgrade/roll back broken packages. thanks to bring this up - this is a big issue. How could we communicate this? Bugzilla? Anyone listing here? Here you go: https://bugzilla.redhat.com/show_bug.cgi?id=1908047 At the moment the only way we have to feed back issues is to file bugs against Stream (which is actually under RHEL8 on bugzilla) as it is not currently possible to submit fixes. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What are the differences between CentOS Linux and CentOS Stream?
On 15/12/2020 18:35, Matthew Miller wrote: On Tue, Dec 15, 2020 at 06:21:17PM +, Phil Perry wrote: thanks to bring this up - this is a big issue. How could we communicate this? Bugzilla? Anyone listing here? Here you go: https://bugzilla.redhat.com/show_bug.cgi?id=1908047 At the moment the only way we have to feed back issues is to file bugs against Stream (which is actually under RHEL8 on bugzilla) as it is not currently possible to submit fixes. Thanks for filing that. I notice that Josh moved it to the "distribution" component rather than DNF -- that makes sense because it's not really an issue with the DNF package itself. Absolutely. Pretty simple to fix so lets see what happens :-) The CentOS team tells me that this is a good place to file anything similar that comes up. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] keepass for CentOS Linux OS
On 24/12/2020 00:09, Kaushal Shriyan wrote: On Thu, Dec 24, 2020 at 12:23 AM Richard wrote: Date: Wednesday, December 23, 2020 23:24:49 +0530 From: Kaushal Shriyan Are there any repos to download keepass password manager for CentOS Linux release 7.9.2009 (Core)? I am getting Service Unavailable when I hit https://apps.fedoraproject.org/packages/keepass as per https://keepass.info/download.html You can get this for CentOS-7 from the EPEL repo. Thanks Richard for the response. I have installed it on CentOS Linux release 7.9.2009 (Core) server. Is there a GUI for it to access it from a network similar to bitwarden (https://bitwarden.com/)? For example http://keepass.example.com. I am going through https://keepass.info/download.html rpm -qil keepassx2-2.0.3-2.el7.x86_64 Name: keepassx2 Version : 2.0.3 Release : 2.el7 Architecture: x86_64 Install Date: Thu 24 Dec 2020 05:26:30 AM IST Group : User Interface/Desktops Size: 1892119 License : GPLv2+ Signature : RSA/SHA256, Wed 30 Nov 2016 04:33:42 AM IST, Key ID 6a2faea2352c64e5 Source RPM : keepassx2-2.0.3-2.el7.src.rpm Build Date : Wed 30 Nov 2016 03:25:42 AM IST Build Host : buildhw-09.phx2.fedoraproject.org Relocations : (not relocatable) Packager: Fedora Project Vendor : Fedora Project URL : http://www.keepassx.org/ Summary : Cross-platform password manager Description : KeePassX is an application for people with extremly high demands on secure personal data management. KeePassX saves many different information e.g. user names, passwords, urls, attachemts and comments in one single database. For a better management user-defined titles and icons can be specified for each single entry. Furthermore the entries are sorted in groups, which are customizable as well. The integrated search function allows to search in a single group or the complete database. KeePassX offers a little utility for secure password generation. The password generator is very customizable, fast and easy to use. Especially someone who generates passwords frequently will appreciate this feature. The complete database is always encrypted either with AES (alias Rijndael) or Twofish encryption algorithm using a 256 bit key. Therefore the saved information can be considered as quite safe. KeePassX uses a database format that is compatible with KeePass Password Safe for MS Windows. /usr/bin/keepassx2 /usr/lib64/keepassx2/libkeepassx-autotype-x11.so /usr/share/applications/keepassx2.desktop /usr/share/doc/keepassx2-2.0.3 /usr/share/doc/keepassx2-2.0.3/CHANGELOG /usr/share/doc/keepassx2-2.0.3/README.md /usr/share/icons/hicolor/128x128 /usr/share/icons/hicolor/128x128/apps /usr/share/icons/hicolor/128x128/apps/keepassx.png /usr/share/icons/hicolor/128x128/mimetypes /usr/share/icons/hicolor/128x128/mimetypes/application-x-keepassx.png /usr/share/icons/hicolor/16x16 Best Regards, Kaushal I prefer the community fork, KeePassXC, which is more actively maintained with new/updated features regularly added. There is no recent RPM package AFAIK but it's really easy to install the very latest Snap package from here and comes with all the latest encryption (AES 256bit) and key derivation functions (Argon2): https://keepassxc.org/download/ It's the first time I'd installed a snap and was pleasantly surprised how easy it was plus updates are automatic. For extra security I then don't use it to store the full password, but separately add a salt creating a double-blind password for more sensitive uses: https://www.youtube.com/watch?v=boj9q26gadE ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 05/01/2021 19:32, Jamie Burchell wrote: Hello I've recently discovered the announcement regarding the change in direction for the CentOS project and I imagine like many others, I'm confused and concerned about what this means moving forward. I work for a small web development agency and we offer hosting as part of our package to clients who need it. We have many CentOS 7 web servers (DigitalOcean droplets) (LAMP/LEMP) that I look after and today I'm thankful I have only migrated one of those to CentOS 8, given the recent announcement about its curtailed EOL. I literally just went to the Wiki today to confirm the EOL date for EL7 and boy am I glad I spotted it. Given we are not developing drivers or applications (other than websites and web applications), is the change a non-issue for my use-case? I've seen it written that CentOS Stream is the "development version" of RHEL but also that we shouldn't have considered RHEL to be the beta for CentOS. Others have said to think of CentOS more like RHEL RC-1. I just don't know how the stability will compare and we have historically always chosen CentOS for its stability (and of course price). Sure, I could migrate to Ubuntu (I use this locally in WSL), but I've become somewhat "comfy slippers" with CentOS and have built our setup around it (including custom ansible scripts etc) and don't want to change everything unncessarily. Of course, a lot of this is somewhat dependent on what DigitalOcean will decide to provide image wise moving forward. I'm sorry if this has already been answered, I spent a good few hours reading through the respective threads in the devel list and ended up more confused than I started. Cheers, Jamie Hi Jamie, Unfortunately no one can advise you as to what may be a suitable operating system for your business needs. One thing is clear, the operating system you are currently running (CentOS Linux) is being brought to end of life, version 7 in 2024 and version 8 in 2021. That gives you at least a year (for 8) if not longer to consider and evaluate alternatives. As your current OS will no longer exist, I would start with a blank sheet, look at the OSes that do exist and evaluate each based on it's merits and suitability for your business needs and requirements. Cheers, Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS Stream suitability as a production webserver
On 07/01/2021 09:47, Jamie Burchell wrote: Didn't the CentOS Vault repo ensure that every package ever published was still available? Yes, it did, but that is not the intention for CentOS Stream moving forward. Only packages in CentOS Linux are moved to the vault at point release time. CentOS Stream only ever has the LATEST package version and nothing else. There is a bug filed for this issue here: https://bugzilla.redhat.com/show_bug.cgi?id=1908047 If it is likely to be an issue for you, please make that known. The more people this affects, the more likely it may be addressed. On 7 Jan 2021, at 07:03, Gordon Messmer wrote: On 1/6/21 8:01 PM, Strahil Nikolov via CentOS wrote: - No chance to "yum history undo last" as there are no older packages I've seen that mentioned as a change pretty frequently, but I don't think it is in any meaningful sense. In CentOS Stream, package versions may be rebased periodically, and the public repos will no longer have older packages to install when using "undo" or "rollback". In CentOS, package versions may be rebased at minor releases, and the public repos will no longer have older packages to install when using "undo" or "rollback". It's true that you might be able to roll back a simple patch in CentOS in between minor releases, but those are the updates that everyone seems to regard as being the safest, and least likely to cause problems, and therefore the least likely to need undo/rollback. The only rational conclusion I can come to is that it doesn't matter if you're talking about CentOS today or Stream in the future: If you want to be able to roll back, you need a private mirror that keeps the package versions that you use. If you don't want a mirror, then you need to build, test, and deploy complete images rather than making incremental changes to mutable systems. None of this is new, it's always been this way and people have just accepted it. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL changes
On 21/01/2021 22:40, John R. Dennison wrote: On Thu, Jan 21, 2021 at 11:36:44PM +0100, Ljubomir Ljubojevic wrote: On 1/21/21 8:53 PM, Alfredo Perez wrote: Is this good news for the "Centos" family? There is no CentOS "family". CentOS clone is dead and will be now Odd that you say it's dead when 7 doesn't sunset until June 30th, 2024. Surely anyone requiring less than 16 licences will now ditch CentOS 7 in favour of RHEL7? The rest may stay on CentOS 7 for a year or so until there is a clearer picture around viable alternatives. This may as well become the RHEL users list and CentOS-Devel effectively becomes the CentOS-Stream mailing list? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL changes
On 22/01/2021 21:08, Frank Cox wrote: On Fri, 22 Jan 2021 20:51:09 + Jamie Burchell wrote: So RH could make it difficult for downstream projects such a Rocky Linux. I don't imagine Redhat will go out of their way to make it easy for Rocky Linux. But there's a point beyond which they can't go without contravening the GPL (and other licenses) so they couldn't do that legally, and there's also a point beyond which they'll alienate more of their customers. At the moment, Red Hat currently make the source code of RHEL 8 available as push commits to a git repo (git.centos.org) that CentOS pull and rebuild. Once CentOS Linux 8 is gone, this git repository will presumably be gone too (or replaced by Stream), so one wonders were the public RHEL sources for other projects to rebuild will be :-/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL changes
On 25/01/2021 20:05, Marc Balmer via CentOS wrote: Am 25.01.2021 um 17:04 schrieb Johnny Hughes : I mean, I get it, some people are very upset with the new way CentOS is being done. And obviously people get to think what they think. But when this was announced, it was also announced that RHEL was going to be opened up early in Q1 of 2021 (which has happened and is still happening). So where is the option to install a RHEL system at a customer site, like I was able with CentOS? Unless I'm misunderstanding Red Hat's offer of 16 free licenses, I'm assuming you can install free RHEL for the customer, and that will form one of their (your customer's) 16 free entitlements. Unless your customer needs more than 16 free entitlements? I'm assuming your customer has the relationship with Red Hat and entitlement to 16 free copies, and you are their sub-contracted IT professional responsible for installation and maintaining / supporting that installation. Obviously if your customer requires in excess of 16 copies, this offer from Red Hat is not going to work for them, or you. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] RHEL changes
On 25/01/2021 20:47, Frank Cox wrote: On Mon, 25 Jan 2021 20:17:17 + Phil Perry wrote: I'm assuming your customer has the relationship with Red Hat and entitlement to 16 free copies, and you are their sub-contracted IT professional responsible for installation and maintaining / supporting that installation. That's a big assumption to make. I set up systems for businesses who want "a computer that does job x". They don't know, care, or want to know what it runs on as long as the thing logs the production or makes the press crank on cue. "Here's your appliance", and they throw it in a corner and maybe someone blows the dust off of it every couple of years when they're going by with a vacuum. They don't want a relationship with Red Hat", and probably wouldn't even know what that is if I told them about it. "Hey Frank, this thing just quit. Make it work again." That's all the involvement they want in the IT end of things. Let me rephrase then. If you were installing Windows on that machine for your customer, who would 'own' the licence - you or your customer? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Dual WAN on EL8 desktop.
On 15/02/2021 11:30, Thomas Stephen Lee wrote: Hi, I have two internet connections from two ISPs. I also have a desktop with two Ethernet ports. My question: What is the best way to get the maximum out of two internet connections in EL 8 for my desktop? Thanks Define maximum. Are you looking for redundancy / fail-over in the event one connection fails or are you looking to combine throughput for maximum bandwidth? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kernel-devel package newer than installed kernel
On 08/03/2021 04:11, Mauricio Tavares wrote: Running CentOS Linux release 8.3.2011 According to uname my kernel is 4.18.0-240.10.1.el8_3.x86_64, but when I check which version of kernel-devel is available, yum info kernel-devel I get that Source : kernel-4.18.0-240.15.1.el8_3.src.rpm Why is the version of kernel-devel available for my kernel based on a newer kernel? uname prints the running kernel - maybe you need to reboot to the latest kernel. Try 'rpm -qa kernel' to see which kernels are actually installed. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] video driver for NVIDIA Quadro
On 09/04/2021 16:40, R C wrote: On 4/9/21 9:24 AM, Johnny Hughes wrote: On 4/7/21 6:44 PM, R C wrote: Hello, I am running Centos/RHEL 8 on a Dell precision M6800/6700 with a: NVIDIA Corporation GK104GLM [Quadro K3100M] Is there a driver for that one? or am I stuck with nouveaux ? The kernel included in CentOS-8 (the last time I tested it), did not properly build and run the proprietary NVIDIA drivers .. neither did the same kernel in RHEL. I found out, trying to install the driver, the NVIDIA installer was complaining. (I was pointed to where the latest driver for it was, by Nvidia (which surprised me a bit that they were still maintaining it actually, at least it's the impression I have) The GK104GLM [Quadro K3100M] _should_ be supported by the latest NVIDIA driver (currently v460.67) on el8. I say _should_ as I'm not 100% sure. I'm assuming your device is as below (check the device IDs with 'pci -nn'): [10de:11b6] NVIDIA Corporation GK104GLM [Quadro K3100M] That device was previously listed as supported: https://download.nvidia.com/XFree86/Linux-x86_64/410.66/README/supportedchips.html but I can't find it listed on the currently supported chipset's page, hence my doubt: https://download.nvidia.com/XFree86/Linux-x86_64/460.67/README/supportedchips.html I'd be interested to know which driver version NVIDIA pointed you towards? What I did was shift my workstation install to the elrepo kernel-ml kernels (you might want kernel-lt .. it is latest long term kernel). I can then build the latest NVIDIA drivers for my graphics card and use them. http://elrepo.org/tiki/kernel-ml http://elrepo.org/tiki/kernel-lt I have no issues using the elrepo kernels .. those guys and gals are outstanding. All the stuff they do is great. My card is a 1080ti .. so I have not tried building for Quadro 3100M .. but if NVIDIA has a linux driver for that, then it should build using the elrepo kernels. Phil Perry can tell us if the NVIDIA drivers they carry actually now work for EL8 .. i stopped trying it after I switched kernels as they don't carry drivers on elrepo for the kernel-ml or kernel-lt and I just rebuild the official NVIDIA drivers manually after every kernel update. That was sort of my plan, to see and wait if things would work with later kernels. Fr now my desktop seems to be working ok-ish. When my desktop is up for over 10-12 hrs, there seem to be some flickering, windows that 'switch' focus etc, and at times the gnome desktop flat out crashes (the machine keeps running, but no gnome. Assuming it is supported by the latest v460.67 driver, and the above omission is a mistake, ELRepo have a driver (kmod-nvidia) which should work with the el8 distro kernel. As Johnny says above, if you use a different kernel, such as those from elrepo, you will need to install the driver directly from NVIDIA. Regards, Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos versions in the future?
On 28/04/2021 23:28, Jonathan Billings wrote: On Apr 27, 2021, at 11:32, Johnny Hughes wrote: You would be hard pressed to find many FUNCTIONAL differences between Stream and CentOS Linux // just as you would be hard pressed to find many differences between RHEL 8.2 and RHEL 8.3, for example. Are there some differences? Sure. If people don't want stream, then by all means , use something else. This is true within the narrow scope of just CentOS/RHEL, but if, for example, you rely on ELrepo for kmods for hardware that Red Hat dropped support for, you’ll be sadly unable to use those kmods on Stream (elrepo isn’t supporting Stream[1]). There will also be inconsistencies with other third party repos and commercial software that focus exclusively on RHEL when Stream gets major version bumps ahead of RHEL. Certainly it will be an opportunity for those vendors to get their product working on Stream, so they’ll be prepared for the next RHEL release. But this is why people are calling it a beta test for RHEL. Yes, Steam running with only their core repos and software from within CentOS is tested and QA’d. But if you want to use Stream in a larger software context, be prepared for missing support and unexpected breakages. The only use I will consider Stream for will be as a test for upcoming RHEL releases, not as something I will ever want actual users to touch. (And maybe that’s ok) 1. http://elrepoproject.blogspot.com/2021/01/elrepo-and-centos-stream.html?m=1 The other concern for me is security. I've not had time to track CVE's in detail, but even a cursory look shows there are CVE's which have been fixed in RHEL8.3 kernel releases which are still not fixed in the latest Stream release [1] (which if truly upstream of RHEL should presumably get the fixes first before they are backported to the RHEL point releases), and others where the fixes eventually appeared weeks or months later [2]. I know CentOS makes no claims as to security fixes etc, but at least with RHEL->CentOS Linux rebuild, one could reasonably expect that when a security issue was fixed in RHEL, CentOS would have the same release and fix out the door within 24-48h. With Stream we are seeing delays of months for security fixes in the kernel that have been released in RHEL. The only time the Stream kernel is comparable to the RHEL kernel from a security fix viewpoint is once every six months on the day the next point release fork occurs. This all indicates Stream is not of production quality and hence why people associate / use the term beta software. [1] CVE-2020-25705 [2] CVE-2020-29661 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 7 on a new Dell Precision
On 15/05/2021 16:14, Tony Schreiner wrote: On Tue, May 4, 2021 at 3:21 PM Tony Schreiner wrote: I am trying to install CentOS 7 on a Dell Precision 3640 and am having some driver problems. I had to use kmod-e1000e from ElReo enable networking on the: 00:1f.6 Ethernet controller [0200]: Intel Corporation Ethernet Connection (11) I219-LM [8086:0d4c] I still don't have graphics. When starting Gnome, it shows the graphic screen briefly but reverts to the text login. It has two graphics cards: 00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:9bc5] (rev 05) 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Lexa XT [Radeon PRO WX 3200] [1002:6981] (rev 10) lsmod shows i915 and amdgpu modules loaded but Xorg.0.log says the modules amdgpu cannot be found. Is it a version issue? Dell has a Radeon driver for RHEL 8, but not for 7. ... Follow up. It was suggested to me off-list to try the elrepo -lt kernel. I have and it gives me network and graphics. Fantastic - glad we could help :-) ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kmod removal
On 29/05/2021 15:52, Emmett Culley via CentOS wrote: Sometime ago I thought I needed kmod-wl to support a new wireless card. Turns out I didn't need to do that. Now I'd like to remove kmod entirely. But when I try I get this: [root@ws1 etc]# dnf remove kmod Error: Problem: The operation would result in removing the following protected packages: systemd-udev (try to add '--skip-broken' to skip uninstallable packages) I am sure I don't want to remove systemd-udev, so I am a loss. I did disable akmods: systemctl disable akmods But I still see that kmod-wl is built each time the kernal is updated. Any suggestions where I can find out how to remove kmod. Note that searching the internet only brings me info on removing kmod-nvidia, and mostly on ubuntu, and they are no help because mostly what they discuss is how get back to neuveau. Even docs I've found that discuss how to install kmod on CentOS say nothing about removal. Emmett Try: dnf remove kmod-wl which should do it for you. the 'kmod' package is the package that provides the underlying kmod architecture. The kmod package providing the individual driver is (probably) called kmod-wl. Hope that helps. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Microsoft Teams on CentOS 7. Does the latest version work?
On 13/07/2021 13:02, Toralf Lund wrote: Does anyone else run Microsoft Teams on CentOS 7? I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything. Has anyone else seen this? Is there anything I can do to make the GUI appear? This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system. The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556. - Toralf My wife has been using it on el7, but for the last month or two yum has been complaining about broken dependencies when trying to update it, so I'd disabled the Teams repo from yum updating. I can check what version I'm running later for you, if that would be helpful. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [External] Re: Microsoft Teams on CentOS 7. Does the latest version work?
On 14/07/2021 07:28, Toralf Lund wrote: On 13/07/2021 14:23, Phil Perry wrote: On 13/07/2021 13:02, Toralf Lund wrote: Does anyone else run Microsoft Teams on CentOS 7? I've used it for a while now, and it's generally worked reasonably well. However, after upgrading to the latest version from the Microsoft repos, it doesn't start up properly. Processes start and remain active until I give up and kill them, but I can't see a window or a tray icon or anything. Has anyone else seen this? Is there anything I can do to make the GUI appear? This is not a big deal as everything just works fine if I revert to the previous release, but it would be interesting to know if this is a general problem with the software, or I have some weird issue with my system. The release that doesn't work is 1.4.00.13653. The one that does is 1.4.00.7556. - Toralf My wife has been using it on el7, but for the last month or two yum has been complaining about broken dependencies when trying to update it, so I'd disabled the Teams repo from yum updating. OK. Do you know what dependencies that might be? Just out of interest... I've never had any issues like that. Like I said, the latest (?) version installs just fine on my system, it's just that it doesn't do anything useful. I can check what version I'm running later for you, if that would be helpful. Well, it would be kind of interesting... - T My currently installed/working version is: # rpm -qa | grep teams teams-1.4.00.7556-1.x86_64 and when I attempt a yum update, I get: Resolving Dependencies --> Running transaction check ---> Package teams.x86_64 0:1.4.00.7556-1 will be updated ---> Package teams.x86_64 0:1.4.00.13653-1 will be an update --> Processing Dependency: libstdc++.so.6(CXXABI_1.3.8)(64bit) for package: teams-1.4.00.13653-1.x86_64 --> Processing Dependency: libstdc++.so.6(CXXABI_1.3.9)(64bit) for package: teams-1.4.00.13653-1.x86_64 --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) for package: teams-1.4.00.13653-1.x86_64 --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) for package: teams-1.4.00.13653-1.x86_64 --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4.22)(64bit) for package: teams-1.4.00.13653-1.x86_64 --> Finished Dependency Resolution Error: Package: teams-1.4.00.13653-1.x86_64 (teams) Requires: libstdc++.so.6(GLIBCXX_3.4.20)(64bit) Error: Package: teams-1.4.00.13653-1.x86_64 (teams) Requires: libstdc++.so.6(CXXABI_1.3.9)(64bit) Error: Package: teams-1.4.00.13653-1.x86_64 (teams) Requires: libstdc++.so.6(GLIBCXX_3.4.21)(64bit) Error: Package: teams-1.4.00.13653-1.x86_64 (teams) Requires: libstdc++.so.6(CXXABI_1.3.8)(64bit) Error: Package: teams-1.4.00.13653-1.x86_64 (teams) Requires: libstdc++.so.6(GLIBCXX_3.4.22)(64bit) So Teams now needs a newer version of libstdc++ than that in RHEL7. As others have mentioned, Microsoft clearly do not understand how to package software using RPM and you are probably better off with a snap/flatpak solution. --Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] A Blast from the past
On 17/08/2021 16:34, Simon Matter wrote: Hello, Can you please help with an interesting problem. I have an Intel Haswell based processor with CentOS 7.0 with an early kernel booting and running perfectly. I changed the processor to an Ice Lake and I get the problem below when I boot the working Haswell disk. The boot process hangs almost immediately and when I remove the 'quiet' boot parameter I see that it hangs randomly, usually with a high CPU number, when SMPBOOT is starting up the cores. The only solution I have found is to boot with the 'nr_cpus=8 (could be any low number), update to the latest kernel then reboot with the 'nr_cpus=8' parameter removed. On examination there are no problems with CentOS 7.4 and above but there are with CentOS 7.3 and below. I think the issue is quite clear here: the newer CPU is not handled correctly by the old kernel - maybe it even doesn't know this CPU type and doesn't know how to detect the number of cores it has. I don't think there is a better solution than what you already did. Regards, Simon Exactly what I was thinking. CentOS 7.0 released in 2014, Intel Ice Lake released at least 5 years later so there will be no support for Ice Lake in the CentOS 7.0 kernel. I'm surprised there is any support in 7.4. Why are you not using the latest release? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/dnf time constraints
On 14/11/2021 13:08, Leon Fauster via CentOS wrote: Hey, i wonder if its possible to use dnf and dictate it to not install packages that are younger then $((today - 7 )) for example. If not directly possible, any other ways to accomplishing it? Sure, building repos with snapshots would work here but I am looking for additional ways ... -- Thanks, Leon A couple ideas: 1. You could run weekly from a scrpt: yum --assumeno update which will create the transaction (but not install it) and save it to /tmp/ and then rerun that transaction week later: yum --assumeyes load-transaction /tmp/yum_save_tx.2021-11-14.13-54.FhQii3.yumtx 2. Write a yum plugin to mask packages from the transaction sack that are less than 7 days old. How are your python skills? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] yum/dnf time constraints
On 15/11/2021 11:49, Leon Fauster via CentOS wrote: Am 14.11.21 um 14:59 schrieb Phil Perry: On 14/11/2021 13:08, Leon Fauster via CentOS wrote: Hey, i wonder if its possible to use dnf and dictate it to not install packages that are younger then $((today - 7 )) for example. If not directly possible, any other ways to accomplishing it? Sure, building repos with snapshots would work here but I am looking for additional ways ... A couple ideas: 1. You could run weekly from a scrpt: yum --assumeno update which will create the transaction (but not install it) and save it to /tmp/ and then rerun that transaction week later: yum --assumeyes load-transaction /tmp/yum_save_tx.2021-11-14.13-54.FhQii3.yumtx That's an interesting approach. Not sure if this is still valid for EL8? Some tests doesn't show any transaction artifact. Maybe I need to dive deeper ... Yes, you are correct, 'yum load-transaction' is not available in dnf on RHEL8 https://access.redhat.com/solutions/5576651 I'm still mostly using el7 so never noticed :-) 2. Write a yum plugin to mask packages from the transaction sack that are less than 7 days old. How are your python skills? That seems to be the cleanest solution. Lets see if I find time for that. A quick look into repodata xml files shows that the build time is also there exposed ... Thanks, Leon ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mate desktop crashes at startup after update to Centos 8.5.2111
On 18/11/2021 17:10, Frank Cox wrote: I updated my main computer to Centos 8.5.2111 late last night and now Mate (my usual choice of desktop) will no longer start. From the GDM login screen I enter my password and select Mate. The screen goes blank and appears to be loading the Mate desktop as usual, but just at the point where the desktop should appear it returns to the GDM login menu. I use Mate from the stenstorp/MATE repo and it's been working fine until last night's update. Have you reported the issue to the stenstorp/MATE repo, and if so, what did they say? I suspect there may be something that needs rebuilding for el8.5. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Is shellcheck safe?
On 17/01/2022 05:30, Thomas Stephen Lee wrote: Hi, I downloaded, extracted, and ran 0.8.0 https://github.com/koalaman/shellcheck/releases After running, I submitted the file to virustotal with the below result. https://www.virustotal.com/gui/file/f4bce23c11c3919c1b20bcb0f206f6b44c44e26f2bc95f8aa708716095fa0651 Should I be concerned that I ran the program once? Thanks ShellCheck is available in EPEL (v0.3.8), at least for rhel7, if that is any indication of it's trustworthiness. The (older) EPEL version scans clean on VirusTotal. You could look at the source code changes between the two releases and make a judgement if you feel there is any reason to be concerned. Alternatively I would suggest submitting a copy to the AV vendor who flagged it for further investigation as a potential false positive. Phil ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] stream 8 or stream 9 for new server
On 13/02/2022 07:06, Jon LaBadie wrote: I'm replacing my ancient desktop home server (CentOS 7, email, dns, backup) with a new mini-server. I've been running stream 9 on the new toy for a couple of weeks and I find there are still a lot of incomplete or missing things. Enough to delay full implementation. Unless I do some workarounds or compile from source. On the other hand I've read there will be no migration path from stream 8 to stream 9. It will require a complete reinstall. Any guesses as to when the stream 9 repos (including epel) will be fairly complete? Just trying to decide whether to wait a bit or go with stream 8. Jon I wouldn't choose either - IMHO Stream is not suitable for production usage due to there being no guarantee regarding security updates (see recent polkit CVE for an example of why this is so). Why would you not use genuine RHEL? You can sign up for 16 free licences with Red Hat and use one of those, for either RHEL8 or RHEL9 once it is released. Alternatively, Rocky or Alma Linux may be a suitable drop in replacement for CentOS Linux for real world usage. Stream is great for getting an early look at what's going to be in the next release of RHEL, and for developing software for the next release of RHEL, or if you are a software developer and wish to contribute to the next release of RHEL, but IMHO it's not a suitable alternative to RHEL (or a clone) for production usage and their are better alternatives available. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] kernel e1000e 0000:00:1f.6 eno1 Reset adapter unexpectedly
On 13/02/2022 12:16, Hooton, Gerard wrote: The Ethernet interface stops working intermittently, once a day. I get the following message in /var/log/messages Feb 13 04:19:47 pc001 kernel: e1000e :00:1f.6 eno1: Reset adapter unexpectedly I ran the following command : ethtool -i eno1 driver: e1000e version: 4.18.0-365.el8.x86_64 firmware-version: 0.4-4 expansion-rom-version: bus-info: :00:1f.6 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: yes === lspci : 00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (11) I219-LM I have CentOS 8 Stream. I would first try to determine if it's a hardware or software issue. Are you able to try replacing the device? Or are you able to try reverting to an earlier kernel to see if you can determine when the issue started to manifest, if it is a software issue. I'm using the e1000e driver on some of my RHEL7 systems and have no issues with the hardware/driver combo under quite heavy usage. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] stream 8 or stream 9 for new server
On 13/02/2022 18:44, Gordon Messmer wrote: On 2/13/22 10:36, Joshua Kramer wrote: I wouldn't go with CentOS for something like that- all of my stuff is on Rocky 8. Using Rocky or Alma isn't going to result in a broader set of packages available on EPEL. Can I politely suggest that such suggestions don't actually address the question that was asked, and aren't helpful? Agreed, but the question that was asked is misplaced so re-framing the question is perhaps helpful to the OP. Also note Stream 8 now has little over 2 years of lifespan remaining (until May 2024), giving Stream 8 a *shorter* lifespan that the CentOS 7 it will be replacing (June 30, 2024) - another reason why it may not be the best choice for a new server right now. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel rebuild failling on Centos 7: missing libbpf-devel and dwarves rpm too old
On 19/04/2022 15:56, Passerini Marco wrote: Hi, I'm trying to rebuild the kernel specifically on Centos7 from src.rpm but some packages are missing or too old. I managed to get them and compile on Centos8 though. Any advice? # yumdownloader --source kernel.src # rpm -ivh ./kernel-4.18.0-348.20.1.el7.src.rpm # rpmbuild -bb --target=`uname -m` ~/rpmbuild/SPECS/kernel.spec Building target platforms: x86_64 Building for target x86_64 error: Failed build dependencies: libbpf-devel is needed by kernel-4.18.0-348.20.1.el7.x86_64 rpm < 4.13.0.1-19 conflicts with kernel-4.18.0-348.20.1.el7.x86_64 dwarves < 1.13 conflicts with kernel-4.18.0-348.20.1.el7.x86_64 You seem to be trying to build an el8 kernel source on el7? # rpm -q dwarves dwarves-1.10-1.el7.x86_64 # rpm -q rpm rpm-4.11.3-48.el7_9.x86_64 # yum search libbpf-devel Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: de.mirrors.clouvider.net * centos-sclo-rh: ftp.tu-chemnitz.de * centos-sclo-sclo: centos.mirrors.psw.services * epel: ftp.uni-kl.de * extras: mirror.imt-systems.com * updates: centos.mirror.iphh.net Warning: No matches found for: libbpf-devel No matches found # yum info rpm Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: de.mirrors.clouvider.net * centos-sclo-rh: ftp.tu-chemnitz.de * centos-sclo-sclo: mirror.softaculous.com * epel: mirror.nextlayer.at * extras: mirror.imt-systems.com * updates: centos.mirror.iphh.net Installed Packages Name: rpm Arch: x86_64 Version : 4.11.3 Release : 48.el7_9 Size: 2.5 M Repo: installed From repo : updates Summary : The RPM package management system URL : http://www.rpm.org/ License : GPLv2+ Description : The RPM Package Manager (RPM) is a powerful command line driven : package management system capable of installing, uninstalling, : verifying, querying, and updating software packages. Each software : package consists of an archive of files along with information about : the package like its version, a description, etc. # yum info dwarves Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: de.mirrors.clouvider.net * centos-sclo-rh: ftp.tu-chemnitz.de * centos-sclo-sclo: ftp.antilo.de * epel: mirror.de.leaseweb.net * extras: mirror.imt-systems.com * updates: centos.mirror.iphh.net Installed Packages Name: dwarves Arch: x86_64 Version : 1.10 Release : 1.el7 Size: 199 k Repo: installed From repo : epel Summary : Debugging Information Manipulation Tools URL : http://oops.ghostprotocols.net:81/blog License : GPLv2 Description : dwarves is a set of tools that use the debugging information inserted in : ELF binaries by compilers such as GCC, used by well known debuggers such as : GDB, and more recent ones such as systemtap. : : Utilities in the dwarves suite include pahole, that can be used to find : alignment holes in structs and classes in languages such as C, C++, but not : limited to these. : : It also extracts other information such as CPU cacheline alignment, helping : pack those structures to achieve more cache hits. : : A diff like tool, codiff can be used to compare the effects changes in source : code generate on the resulting binaries. : : Another tool is pfunct, that can be used to find all sorts of information about : functions, inlines, decisions made by the compiler about inlining, etc. Regards, Marco Passerini ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel rebuild failling on Centos 7: missing libbpf-devel and dwarves rpm too old
You could do a lot worse than following this documentation: https://wiki.centos.org/HowTos/Custom_Kernel On 20/04/2022 14:28, Passerini Marco wrote: Hi, I think you're right, I got it after I enabled: # cat /etc/yum.repos.d/CentOS-Sources.repo [...] [base-source] name=CentOS-$releasever - Base Sources baseurl=http://vault.centos.org/centos/$releasever/os/Source/ gpgcheck=1 enabled=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 [...] Then I ran: # yumdownloader --source kernel.src Loaded plugins: fastestmirror Enabling centos-sclo-rh-source repository Enabling epel-source repository Enabling updates-source repository Enabling centos-sclo-sclo-source repository Enabling extras-source repository Loading mirror speeds from cached hostfile epel/x86_64/metalink | 31 kB 00:00:00 epel-source/x86_64/metalink | 29 kB 00:00:00 * base: mirror.imt-systems.com * centos-sclo-rh: ftp.agdsn.de * centos-sclo-sclo: de.mirrors.clouvider.net * epel: fedora.tu-chemnitz.de * epel-source: fedora.tu-chemnitz.de * extras: mirror.imt-systems.com * updates: mirror.scaleuptech.com base | 3.6 kB 00:00:00 base-source | 2.9 kB 00:00:00 centos-sclo-rh | 3.0 kB 00:00:00 centos-sclo-rh-source | 3.0 kB 00:00:00 centos-sclo-sclo | 3.0 kB 00:00:00 centos-sclo-sclo-source | 3.0 kB 00:00:00 extras | 2.9 kB 00:00:00 extras-source | 2.9 kB 00:00:00 updates | 2.9 kB 00:00:00 updates-source | 2.9 kB 00:00:00 Delta RPMs disabled because /usr/bin/applydeltarpm not installed. kernel-4.18.0-348.20.1.el7.src.rpm | 121 MB 00:00:01 This version is too recent I think. I'm not sure why it's there? I then manually downloaded this version, it looks like it's working better: wget https://vault.centos.org/7.9.2009/os/Source/SPackages/kernel-3.10.0-1160.el7.src.rpm Regards, Marco Passerini From: CentOS on behalf of Phil Perry Sent: Tuesday, April 19, 2022 5:46:15 PM To: centos@centos.org Subject: Re: [CentOS] Kernel rebuild failling on Centos 7: missing libbpf-devel and dwarves rpm too old On 19/04/2022 15:56, Passerini Marco wrote: Hi, I'm trying to rebuild the kernel specifically on Centos7 from src.rpm but some packages are missing or too old. I managed to get them and compile on Centos8 though. Any advice? # yumdownloader --source kernel.src # rpm -ivh ./kernel-4.18.0-348.20.1.el7.src.rpm # rpmbuild -bb --target=`uname -m` ~/rpmbuild/SPECS/kernel.spec Building target platforms: x86_64 Building for target x86_64 error: Failed build dependencies: libbpf-devel is needed by kernel-4.18.0-348.20.1.el7.x86_64 rpm < 4.13.0.1-19 conflicts with kernel-4.18.0-348.20.1.el7.x86_64 dwarves < 1.13 conflicts with kernel-4.18.0-348.20.1.el7.x86_64 You seem to be trying to build an el8 kernel source on el7? # rpm -q dwarves d
Re: [CentOS] BIND server getting DDOS
On 03/08/2022 19:08, Mark Milhollan wrote: On Tue, 2 Aug 2022, Robert Moskowitz wrote: I just, maybe, figured out why I have been having problems with my CentOS DNS server with BIND 9.11.4. Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80 114.29.194.4#11205 (.): view external: query (cache) './A/IN' denied Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80 114.29.216.196#64956 (.): view external: query (cache) './A/IN' denied Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80 64.68.114.141#39466 (.): view external: query (cache) './A/IN' denied Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80 209.197.198.45#13280 (.): view external: query (cache) './A/IN' denied Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80 114.29.202.117#41955 (.): view external: query (cache) './A/IN' denied Aug 2 15:47:19 onlo named[6155]: client @0xaa3cad80 62.109.204.22#4406 (.): view external: query (cache) './A/IN' denied Aug 2 15:47:49 onlo named[6155]: client @0xa9420720 64.68.104.9#38518 (.): view external: query (cache) './A/IN' denied Aug 2 15:47:50 onlo named[6155]: client @0xaa882dc8 114.29.202.117#9584 (.): view external: query (cache) './A/IN' denied Usually that's someone hoping to use you in a reflection attack, which is successful since UDP can be forged but it hasn't got the volume it might if you answered differently (with a referral). Sometimes it is a policy denial attack, hoping you will block the apparent source thus denying it service. The only way to stop it is for all others to employ BCP 38 which will likely never happen, or for you to stop allowing outside use of your nameserver which means having someone else handle DNS for you (which just seems to stop it, from your perspective). It shouldn't cause problems unless your server is vastly underpowered. What problems are you experiencing? Enabling rate limiting in BIND can help. https://kb.isc.org/docs/aa-00994 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Current RHEL fragmentation landscape
I was trying to stay out of this thread, but the reply was complete and utter nonsense... On 25/07/2023 01:24, Gordon Messmer wrote: On 2023-07-24 13:47, frank saporito wrote: Let me know if you disagree with any of these statements: 1. Red Hat is no longer posting source code to git.centos.org. Correct. Red Hat used to publish a de-branded subset of RHEL source code there, and they've discontinued that process. The current code for RHEL is now published to the CentOS Stream repos. 2. Red Hat will release source code to partners and customers via the Red Hat Customer Portal. (ref: Red Hat announcement) Also correct. This is the only channel through which Red Hat ever posted complete code for RHEL. It hasn't been changed. Nonsense. For years Red Hat freely published the complete RHEL SRPMs to their public ftp server. It *has* changed, a number of times over the years as Red Hat increasingly seek to make it harder for others to exercise their GPL rights. 3. Per Red Hat EULA, customers can not freely distribute the source code. (ref: Red Hat EULA) It's a little more complex than that, but probably close enough for now. It's not complex at all. The GPL absolutely allows recipients to freely redistribute the RHEL sources. Red Hat seek to prevent their customers from exercising their rights under the GPL by imposing agreements that allow them to terminate their contract and/or take legal action if their customers choose to exercise their GPL rights. Lets be very clear what Red Hat are doing (and to the best of my knowledge have always done). 4. Red Hat's policy decision has made it difficult (maybe impossible) for "clone" distributions to continue existing. (ref: Google "red hat source code") This is the point at which I think we start to wade out into the territory of myth. It has never been possible to create a clone of RHEL from the code that Red Hat published. Of course it has. CentOS did it for years, and so did Scientific Linux and others. The GPL *requires* Red Hat to publish the full sources including "the scripts used to control compilation and installation of the executable." If it is not possible to create a clone, then Red Hat are not in compliance with the GPL. First, because Red Hat doesn't publish the information that would be required to create reproducible builds. Yes they do - it's all in the SRPMs. I will concede that these need to be built in the correct order and thus within the correct buildroot (the skill that CentOS and others brought), but the information required "to control compilation and installation of the executable" is all there. But more importantly, because RHEL has one life cycle per minor release, and distributions built from the old git.centos.org repositories had *at best* one life cycle per major release. CentOS Stream also has one life cycle per major release, and conforms to the interface compatibility guide for the matching RHEL major release. Distributions derived from CentOS Stream can have either lifecycles per minor release *or* one lifecycle per major release. Unlike the old source publication process, they can have continuous or overlapping life cycles. Yes, this involves more steps than the old process. The next natural question is whether the additional work is justified by the improvement in the outcome. And from my point of view, that is a very easy "yes". I understand that it's confusing, but CentOS was never a substitute for RHEL, and never provided the benefits of RHEL's model. It is not the "free RHEL" that many users tend to think it was: https://fosstodon.org/@gordonmessmer/110648143030974242 https://www.youtube.com/watch?v=tf_EkU3x2G0 ... and conversely, CentOS Stream is a much better stable LTS for self-supported systems than you might believe: https://medium.com/@gordon.messmer/in-favor-of-centos-stream-e5a8a43bdcf8 5. Red Hat's policy change contradicts the GPL's spirit. As you acknowledge, that's a subjective question. I would say "no." Seriously? You are the only person here who thinks that. The GPL grants the rights to redistribute sources. It goes further, it specifically states: " To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it. For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights." Red Hat's terms specifically contradict that and specifically prohibit: "using Subscription Services in connection with any redistribution of Software" in section 1.2 (g) (d) of their terms (below), con
Re: [CentOS] getting rid of hp c3180
On 20/07/17 07:29, Michael Hennebry wrote: Does a Canon MF232W work with Centos? From https://www.usa.canon.com/internet/portal/us/home/support/details/printers/black-and-white-laser/imageclass-mf232w#fb5cab1c-c86d-4fda-864d-6023bbc5a3a6_tab I got the following message: There is no driver for the OS Version you selected. The driver may be included in your OS or you may not need a driver. It had autodetected linux 64-bit. To me, that suggests that I should be able to connect it and it should pretty much just work. Am I correct? My guess would be no. It appears to use a proprietary built in engine that will need a driver and Canon don't appear to provide drivers for Linux for that model. I'd be very surprised if it will work. I'd recommend you look for a model with good Linux support, preferably based upon a Postscript/PCL engine. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] How does yum decide when 2 packages meet a dependency?
Hi list, Say a package has a dependency for libfoo.so.1, and 2 (or more) packages provide libfoo.so.1, how does yum decide which package to install to meet the dependency? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How does yum decide when 2 packages meet a dependency?
On 21/07/17 17:10, Matthew Miller wrote: On Fri, Jul 21, 2017 at 05:00:35PM +0100, John Hodrien wrote: Say a package has a dependency for libfoo.so.1, and 2 (or more) packages provide libfoo.so.1, how does yum decide which package to install to meet the dependency? It has a series of heuristics: http://yum.baseurl.org/wiki/CompareProviders Many thanks Matthew, that's a great overview. That's fabulous. You mean Phil could have fixed my issue by renaming the package priimus so that the name was longer than mesa-libGL ;) Tragically possible. :) In this case, working through the logic, it would appear that primus probably won the battle on the basis of pulling in fewer deps than mesa-libGL, but what else is already installed on the system would clearly have an effect here. Still, nice to know the logic involved. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Fedora bugs and EOL [was Re: CentOS users: please try and provide feedback on Fedora] Boltron
On 28/07/17 18:56, hw wrote: Matthew Miller wrote: On Fri, Jul 28, 2017 at 06:13:42PM +0200, hw wrote: What?s the point of doing this with Fedora? It?s not like bugs were fixed before Fedora is EOL and all reports are forgotten. Many bugs are fixed in Fedora. Many more bugs are fixed in the upstreams. Please remember that Fedora is primarily an *integration* project, and the best way to get bugs fixed is for the developers of the code in question to be involved. Many Fedora maintainers help facilitate this for users, which is awesome, but the sheer number of bugs exceeds what even our large contributor community can address. Contributions are usually not wanted, despite what all projects tell you. I have given up trying to make any and keep things to myself instead. The issue I have here is even if I did file a bug, and the issue were fixed, no sooner than it's fixed fedora updates to the next version and introduces a whole bunch of new bugs, and so the cycle continues. I played that game for a while with fedora core when Red Hat Linux died before settling on Enterprise Linux and have never looked back. I have just recently upgraded my main system from el5 to el7. I originally built and installed that el5 system back in 2007. It ran for 10 years without a hitch. I can count the number of bugs I had to file in 10 years on one hand. Once they were fixed the system just worked for 10 years. If RH continued to support it, I'd still be using it now, and probably for a lot longer, because it still worked as well for me now as it did in 2007. I've updated to el7 not because I wanted to or needed to, but because I was forced to, and given the pain I want another 10 years of payback to make it worth the effort. I know it sucks when an issue that affects you doesn't get fixed in a timely manner, but we really do appreciate reports and it's helpful if you can retest and reopen EOL bugs if they do indeed still happen in the newer version. It is discouraging to see bugs closed all the time not because the bugs are fixed but because Fedora has gone EOL again. When the policy is to have bugs fixed upstream, it might be a good idea to have them reported upstream and to restrict Fedoras bugzilla to bugs actually introduced by Fedora. In any case, I have given up reporting bugs a long time ago, especially with Fedora. However, I´m seeing the same bugs from years ago still unfixed in Centos. That refers to libreoffice being unusably slow. This still doesn´t seem to be fixed for Fedora, either, because it went EOL --- but I don´t know. Agree on that. My previous 10 year old el5 install ran OpenOffice perfectly on 10 year old hardware. My new el7 install on brand new hardware which is vastly superior in terms of processing power, GPU power, disk IO, can't even scroll a simple 3 column spreadsheet on the screen. How is that improvement or advancement? But if the issue does ever get fixed, you can bet your life I'll be sticking with that fixed product for the next 10 years, not upgrading to some other broken version in 6 or 12 months time. What is the fix for Centos? There used to be a package you could install which made libreoffice work at normal speed, and that package seems to have disappeared. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Problems switching from RHEL 6 to Centos 6
On 30/07/17 14:04, Alois Treindl wrote: Thank you. I could resolve the issues, by editing stuff in /etc/yum/pluginconf.d There, I created a file rhnplugin.conf with the content [rhel-6-server-extras-rpms] enabled=0 [rhel-6-server-optional-rpms] enabled=0 and I edited the file search-disabled-repos.conf and inserted into the line ignored-repos= ... the pattern rhel* I do not know whether this second step was necessary, I happened to do both at once. After that, yum upgrade no longer demanded rhel repositories. I would use yum to uninstall the packages that provide /etc/yum.repos.d/redhat.repo and /etc/yum/pluginconf.d/rhnplugin.conf On rhel7, these are yum-rhn-plugin and subscription-manager, use rpm to check which packages provide them on el6. On 30.07.17 14:37, Johnny Hughes wrote: On 07/30/2017 07:32 AM, Alois Treindl wrote: I am trying to migratean existing RHEL 6 machine to Centos 6. I followed the instructions in https://wiki.centos.org/HowTos/MigrationGuide I run into problems: when I run yum upgrade then yum tries to access a repository rhel-6-server-extras-rpms and then fails. What can I do that yum no longer tries to access this repository? Normally, .repo files are in /etc/yum.repos.d/ . You should be able to edit files in that directory and find a section for any repos that you wish to disable. Setting enable=0 in the applicable section will turn off that specific repo. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Problems switching from RHEL 6 to Centos 6
On 30/07/17 15:00, Alois Treindl wrote: On 07/30/2017 03:23 PM, Phil Perry wrote: I would use yum to uninstall the packages that provide /etc/yum.repos.d/redhat.repo and /etc/yum/pluginconf.d/rhnplugin.conf On rhel7, these are yum-rhn-plugin and subscription-manager, use rpm to check which packages provide them on el6. which rpm command does this exactly? rpm -q --whatprovides /etc/yum.repos.d/redhat.repo ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] What RH-like on a Dell XPS 15 (9590)?
On 02/08/17 16:18, Johnny Hughes wrote: On 08/02/2017 09:55 AM, Lamar Owen wrote: On 07/27/2017 04:16 PM, wwp wrote: ... It is as simple as unknown hardware at boot up, it's a well known issue w/ *Lake hardware (modern hardware) that kernel 3.x cannot handle. CentOS7 has a kernel which is simply not modern, unable to handle lots of computers sold currently. That said, there might be a way to boot, but nothing trivial and nothing at all I could find on the Internet, everytime it's kernel 4.3/4.10 minimum required. ... While I know that Johnny has provided the experimental kernel (thanks, Johnny) I would like to just briefly address this idea that the C7 kernel is 'obviously' not going to work because 'is 3.x and must have 4.x.' In EL-land, kernel versions are effectively meaningless, since features, hardware support, bugfixes, security fixes, etc are back-ported into the 'old and not modern' 3.10 kernel (for EL7) by competent developers at Red Hat. An EL 3.10 kernel, such as the current 3.10.0-514.26.2.el7.x86_64 one, may have hardware support back-ported from a 4.x kernel that doesn't exist in the vanilla kernel.org kernel (I'm almost certain it does, but I'm not going to take the time to get details). It might work in the RHEL 7.4 kernel .. I'll get that onto buildlogs for testing while I am working on the CentOS Linux 7 upgrade builds. And yes, people do need to understand that Red Hat backports newer firmware and drivers to the older kernels. There are plenty of 4.x kernel things backported. So, as you correctly pointed out, you can't treat the Red Hat 3.10.x kernels like kernel.org 3.10.x kernels. Indeed, Lamar and Johnny are correct. For example, the wireless driver stack from kernel-4.11 has just showed up in the RHEL-7.4 kernel released yesterday. Further, I would encourage anyone to file RFEs upstream with Red Hat for support to be added for any currently unsupported hardware. If Red Hat don't know you want support for it, it won't get added. If you don't ask, you won't get. Whilst you are waiting on Red Hat to backport support into the distro kernel, don't forget elrepo.org also specialise in backporting individual device drivers which can provide an invaluable stopgap allowing the distro kernel to continue to be used until such time as the hardware is natively supported. For example, I recently built an updated i2c-i801 el7 driver adding backported support from kernel-4.4 for Braswell and Wildcat Point ICH's following an RFE from a user. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] centos7: looking for libwebpdemux
On 06/08/17 08:04, wwp wrote: Hello there, I'm looking for libwebpdemux.so, possibly 0.4.x. I had it installed on my CentOS6, from EPEL, but now on CentOS7, EPEL doesn't provide it at all. Anybody knows about it? Maybe a rpm rebuild would do it? Regards, Packages don't just appear in EPEL for el7 because they are there for el6, someone has to request them. I would suggest you make a request for libwebpdemux for el7 and see if the el6 maintainer is willing to maintain this for el7 also. See: https://fedoraproject.org/wiki/EPEL/FAQ#Why_isn.27t_a_package_in_EPEL-7_when_it_is_in_EPEL-6.3F ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Centos 7 specific cure for Spamassassin DNS lookup problem
On 10/08/17 15:37, Paul Heinlein wrote: On Thu, 10 Aug 2017, Gary Stainburn wrote: I have the following error message in my /var/log/spamd spf: lookup failed: available_nameservers: No DNS servers available! Having Googled the error message I've found a number of responses which involve patching Perl or Spamassassin or other cures. Before I start changing things I was wondering if there was a Centos 7 specific resolution. Where possible, on production machines I prefer to stay with RPM's rather than amending software directly. I run SpamAssassin on CentOS 7; the SPF plugin is loaded via /etc/mail/spamassassin/init.pre. I have no trouble with spf at all. Is it possible the problem is with local DNS resolution? Same here, no issues with spamassassin and SPF. In addition to Paul's question which seems like the most obvious initial avenue of investigation, I assume you have perl-Mail-SPF and perl-Net-DNS installed? They should be as both are deps for the spamassassin package. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Kernel 4.12 and nVidia Driver
On 05/09/17 14:11, Alexander Dalloz wrote: Am 05.09.2017 um 06:16 schrieb Eugene Poole: I tried to move to the latest stable kernel (4.12) so I could take "latest stable kernel (4.12) - that's not a CentOS project kernel. Can we guess that you are using the ELrepo kernel-ml? advantage of my newest custom system (Intel Core I7 6-core; 64 GB RAM; MSI nVidia graphics card; 2 - 120 GB SSD; 2 - 4TB WD Black) on a UEFI Asrock mother board. I've had the machine for 3-months but I couldn't get it to work until I found out that the Nouveau driver was causing me all the 'hardware' issues. I moved to the nVidia driver along with DKMS and all of my issues went away until I attempted to upgrade kernel 4.12 ... It seems that DKMS doesn't automatically upgrade when the kernel is upgraded. Will this issue go away if I change my graphics card to a AMD? A bit dated, but it holds basic info about DKMS https://wiki.centos.org/HowTos/BuildingKernelModules#head-d313bd351f90d4f25a2143b7bbcff73f927731f0 Instead of using DKMS, the kmod-nvidia driver from ELrepo does not fit for your graphics card? Or any of the other kmod-nvidia* kernel module packages from there? https://elrepo.org/tiki/kmod-nvidia The elrepo kmod-nvidia drivers (or any kmods for that point) will only work with the distro kernel as they depend on the stable kernel ABI that Red Hat maintains in their kernel releases. They will not work with non-distro kernels. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Flush memory on a server?
On 09/09/17 12:43, Nicolas Kovacs wrote: Hi, A few days ago I checked the health of my main public server running CentOS 7, a quad-core machine with 16 GB RAM. It had been running non-stop for 65 days, hosting only a handful of services (BIND, NTP, Apache, Postfix, Dovecot) for two domains. I was surprised to see that RAM consumption was relatively high, and apparently, the machine even had to swap at some time. Why were you surprised? Linux systems use the available RAM, surely you understand that? Of course there is the possibility that you have discovered a bug and there is a memory leak on your system, building up over time. I suggest you show the list full memory usage details if you feel this is the case. I read up a bit on RAM consumption, and now I wonder if flushing the memory cache regularly is a good idea. https://tecadmin.net/flush-memory-cache-on-linux-server/ Any suggestions? Did you read the kernel documentation on the subject linked in comments section of that article? Niki ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] KeePassX replacement
On 16/09/17 11:55, Tom Longfield wrote: I have been using KeePassXC (though mostly on Debian) for quite a while now and am happy to report it works well. Nothing springs to mind that annoys me and it's a decent drop in replacement. My setup sounds pretty similar to your own (also use keepass2android, though not KeePass on Windows). I would be inclined to compile from source yourself rather than use an unofficial repo you have no reason to trust for such a sensitive application. I'm not trying to besmirch the good name of copr.fedorainfracloud.org/bugzy but I've never heard of them and if you hadn't either that would give me pause for thought before I let their binaries at my passwords. I'm in a similar position presently, evaluating at password manager apps and had also come across that KeePassXC build. I briefly installed the above package to evaluate and also intend to rebuild it for my own use. Another concern for me was the use of the 'centos' dist tag when the package clearly isn't a 'centos' package. I've got as far as confirming the validity of the source tarball in the SRPM and checking the SPEC file. Everything looks fine, but as previously mentioned I would still rebuild such a sensitive package for my own use. The only other potential issue I see is that the latest KeePassXC requires a newer version of libgcrypt, which the repo above packages as libgcrypt16 (libgcrypt version 1.6.6) on el7. The release of 1.6 broke ABI compatibility with version 1.5 in el7. I have not tried building KeePassXC against libgcrypt-1.5 in el7 to know if that is viable. On Fri 15 Sep 2017 @ 21:43, H wrote: I have been using the KeePassX password manager on CentOS 6 and 7 for some time and it works pretty well. On my Windows machine I use KeePass which offers a number of features missing from KeePassX, I also sync the database between several machines, including Android units where I use keepass2android. Database compatibility is thus required. KeePassX, however, does not seem to be maintained any more, the last update was just a bit less than a year ago. It also has some annoying bugs, including where switching keyboards on the computer corrupts the username and the password if they include any character outside the ASCII range. There seems to be a community fork called KeePassXC and I would like to ask if anyone is using this password manager? It is not in EPEL, nor in any other standard repository, only through an unofficial repository at https://copr.fedorainfracloud.org/coprs/bugzy/keepassxc/, ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] KeePassX replacement
On 16/09/17 16:05, Phil Perry wrote: The only other potential issue I see is that the latest KeePassXC requires a newer version of libgcrypt, which the repo above packages as libgcrypt16 (libgcrypt version 1.6.6) on el7. The release of 1.6 broke ABI compatibility with version 1.5 in el7. I have not tried building KeePassXC against libgcrypt-1.5 in el7 to know if that is viable. I've just looked at the ABI changes, and can confirm that the latest version of KeePassXC uses the GCRY_CIPHER_SALSA20 cipher function added in libgcrypt-1.6, so users will also need to install a newer version of libgcrypt alongside version 1.5 in el7. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
On 26/09/17 18:40, m.r...@5-cent.us wrote: This is really frustrating. I've got a server with two K20c Tesla cards. I need to use the proprietary drivers to use the CUDA toolkit. Btw, I had no trouble at all with building for CentOS 7.3 I have what NVidia claims is the correct driver package, a 340 series. It appears to build, but then fails to load. The only error I see is "no such device", which makes no sense to me, esp. since it says nothing whatever else. I've gone through the install log, and there are a bunch of Note:, and warnings, but the later I think are all about comparing signed and unsigned integers. And lsmod shows no nvidia drivers registered, but the logs claims that Error: Driver 'nvidia' is already registered, aborting... Anyone got any ideas? mark You don't say which version of the 340 series driver you have tried. There was a bug with recent legacy releases that affected el7.4 kernels. We (elrepo) patched the driver to fix that on rhel7.4 releases. I'm not sure but it _may_ have been fixed in the 340.104 driver released last week - I've not bothered building it as the changelog only mentions "Improved compatibility with recent Linux kernels" which we patched/fixed in our the previous release and other issues which don't affect kmods on RHEL. So it sounds like a known issue which has already been fixed. If you don't want to use our packages, maybe take a look at the patch and try applying it to your build. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] MP4/H.264 codec for Firefox?
On 26/09/17 20:26, Roman Kennke wrote: Hello, I am trying to get MP4/H.264 playback in Firefox to work on my CentOS laptop (for vimeo). I installed the gstreamer plugins as described here: https://wiki.centos.org/TipsAndTricks/MultimediaOnCentOS7 (No, I did not install Flash, VLC and all the other stuff. I only want HTML5 MP4 playback..) I enabled the nux repos. I did install all available gstreamer plugins, i.e. -good -bad -ugly -ffmpeg etc. No success. Has anybody got mp4 playback working? Here's a test page: https://www.quirksmode.org/html5/tests/video.html Help would be appreciated! Best regards, Roman Yes, it's working here, but I can't remember for sure exactly what I needed to install to get it working. Here's my installed gstreamer packages: rpm -qa | grep gstreamer | sort gstreamer-0.10.36-7.el7.x86_64 gstreamer1-1.10.4-2.el7.x86_64 gstreamer1-libav-1.0.6-1.el7.nux.x86_64 gstreamer1-plugins-bad-free-1.10.4-2.el7.x86_64 gstreamer1-plugins-bad-freeworld-1.0.6-1.el7.nux.x86_64 gstreamer1-plugins-base-1.10.4-1.el7.x86_64 gstreamer1-plugins-good-1.10.4-2.el7.x86_64 gstreamer1-plugins-ugly-1.0.6-2.el7.nux.x86_64 gstreamer-plugins-bad-free-0.10.23-23.el7.x86_64 gstreamer-plugins-base-0.10.36-10.el7.x86_64 gstreamer-plugins-good-0.10.31-13.el7.x86_64 gstreamer-plugins-ugly-0.10.19-17.el7.nux.x86_64 gstreamer-tools-0.10.36-7.el7.x86_64 PackageKit-gstreamer-plugin-1.1.5-1.el7.x86_64 phonon-backend-gstreamer-4.6.3-3.el7.x86_64 and here's everything from the nux repo on this box: rpm -qa | grep 'el7\.nux' | sort faac-1.28-6.0.el7.nux.x86_64 faad2-libs-2.7-5.el7.nux.x86_64 ffmpeg-2.6.8-3.el7.nux.x86_64 ffmpeg-libs-2.6.8-3.el7.nux.x86_64 gstreamer1-libav-1.0.6-1.el7.nux.x86_64 gstreamer1-plugins-bad-freeworld-1.0.6-1.el7.nux.x86_64 gstreamer1-plugins-ugly-1.0.6-2.el7.nux.x86_64 gstreamer-plugins-ugly-0.10.19-17.el7.nux.x86_64 libavdevice-2.6.8-3.el7.nux.x86_64 libcddb-1.3.2-12.el7.nux.x86_64 libdca-0.0.5-7.el7.nux.x86_64 libdvdcss-1.2.13-1.el7.nux.x86_64 libmimic-1.0.4-7.el7.nux.x86_64 libmms-0.6.4-1.el7.nux.x86_64 libmpeg2-0.5.1-10.el7.nux.x86_64 libquicktime-1.2.4-19.el7.nux.x86_64 librtmp-2.4-2.20131205.gitdc76f0a.el7.nux.x86_64 libsidplay-1.36.60-2.el7.nux.x86_64 live555-2013.11.26-1.el7.nux.x86_64 mjpegtools-libs-2.1.0-5.el7.nux.x86_64 nux-dextop-release-0-5.el7.nux.noarch opencore-amr-0.1.3-3.el7.nux.x86_64 twolame-libs-0.3.13-3.el7.nux.x86_64 vlc-2.2.5.1-2.el7.nux.x86_64 vlc-core-2.2.5.1-2.el7.nux.x86_64 vo-amrwbenc-0.1.2-1.el7.nux.x86_64 x264-libs-0.142-11.20141221git6a301b6.el7.nux.x86_64 x265-libs-1.9-1.el7.nux.x86_64 xvidcore-1.3.2-5.el7.nux.x86_64 Let me know if you need info on other installed packages. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
On 27/09/17 07:56, Sorin Srbu wrote: -Original Message- From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of Phil Perry Sent: den 26 september 2017 21:46 To: centos@centos.org Subject: Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4 On 26/09/17 18:40, m.r...@5-cent.us wrote: This is really frustrating. I've got a server with two K20c Tesla cards. I need to use the proprietary drivers to use the CUDA toolkit. Btw, I had no trouble at all with building for CentOS 7.3 I have what NVidia claims is the correct driver package, a 340 series. It appears to build, but then fails to load. The only error I see is "no such device", which makes no sense to me, esp. since it says nothing whatever else. I've gone through the install log, and there are a bunch of Note:, and warnings, but the later I think are all about comparing signed and unsigned integers. And lsmod shows no nvidia drivers registered, but the logs claims that Error: Driver 'nvidia' is already registered, aborting... Anyone got any ideas? mark You don't say which version of the 340 series driver you have tried. There was a bug with recent legacy releases that affected el7.4 kernels. We (elrepo) patched the driver to fix that on rhel7.4 releases. I'm not sure but it _may_ have been fixed in the 340.104 driver released last week - I've not bothered building it as the changelog only mentions "Improved compatibility with recent Linux kernels" which we patched/fixed in our the previous release and other issues which don't affect kmods on RHEL. So it sounds like a known issue which has already been fixed. If you don't want to use our packages, maybe take a look at the patch and try applying it to your build. Tested 340.76, 340.102, 340.104 (elrepo and proprietary). No luck over here with a GTX260 and the 64b-drivers. Will test some more, if still no luck, I'll just reinstall from scratch. The kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64.rpm driver should work for your card on el7.4. All previous releases in elrepo were for el7.3 (and earlier) and are not compatible with the el7.4 series kernel. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
On 27/09/17 16:49, m.r...@5-cent.us wrote: Hi, folks, Well, still more fun (for values of fun approaching zero): 1. Went to install CUDA 9.0... well, gee, there is *no* CUDA 9.0. Even though I installed the 9 repo, all that I get is 8. I've used their webform, and an waiting on a reply. 2. I remove all nvidia packages. 3. It appears that the kmod-nvidia is what I need; that's what nvidia-detect says. So I try to install... bzzt, thank you for playing. a: uname -a: 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux b: Installing : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Broadcast message from systemd-journ...@lyon.cit.nih.gov (Wed 2017-09-27 11:43:12 EDT): dracut[32409]: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut:/lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Working. This may take some time ... /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? /sbin/weak-modules: line 116: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 132: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 137: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory Unable to decompress /boot/initramfs-3.10.0-693.el7.x86_64.tmp: Unknown format /sbin/weak-modules: line 175: /tmp/weak-modules.oC1A7x/new_initramfs.img: No such file or directory rm: cannot remove '/tmp/weak-modules.oC1A7x/new_initramfs.img': No such file or directory mv: cannot stat '/boot/initramfs-3.10.0-693.el7.x86_64.tmp': No such file or directory Done. Installing : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 etckeeper: post transaction commit Verifying : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Verifying : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 Installed: kmod-nvidia.x86_64 0:384.90-1.el7_4.elrepo Dependency Installed: nvidia-x11-drv.x86_64 0:384.90-1.el7.elrepo Complete! Well, no it's not complete, and it's trying to install in the *previous* kernel, not the running one. mark kmod packages are a special class of package on RHEL that take advantage of the stable kernel ABI in Red Hat Enterprise Linux. When a kmod package is compiled against a kernel, the kernel module will be installed for that kernel and the weak-modules script will then weak link the module against all other kABI-compatible kernels installed on the system. This means that you do not need to rebuild the kernel module for each and every kernel update (or worse, delay updating your kernel whilst you wait for me to rebuild the module for you). So yes, the module will likely be installed against a previous kernel, and maybe one that isn't even installed on your system. But it will weak link against your current kernel(s) providing none of the kernel symbols used by the module have changed between the kernel the module was built against and the current kernel in question. If you don't understand, just think of it as magic and be grateful you are running an Enterprise Linux kernel and not a fedora kernel. As to the earlier error messages, have you been playing with depmod? Where is your modules.dep for your installed kernels? Anyway, the magic described above has likely not worked correctly due to missing modules.dep, so I would uninstall the nvidia packages, sort out your kernel(s) / depmod information and try again once you have a sane system. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Semi-OT: hardware: NVidia proprietary driver, C7.4
On 27/09/17 20:24, m.r...@5-cent.us wrote: Phil Perry wrote: On 27/09/17 16:49, m.r...@5-cent.us wrote: Hi, folks, Well, still more fun (for values of fun approaching zero): 1. Went to install CUDA 9.0... well, gee, there is *no* CUDA 9.0. Even though I installed the 9 repo, all that I get is 8. I've used their webform, and an waiting on a reply. 2. I remove all nvidia packages. 3. It appears that the kmod-nvidia is what I need; that's what nvidia-detect says. So I try to install... bzzt, thank you for playing. a: uname -a: 3.10.0-693.2.2.el7.x86_64 #1 SMP Tue Sep 12 22:26:13 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux b: Installing : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Broadcast message from systemd-journ...@lyon.cit.nih.gov (Wed 2017-09-27 11:43:12 EDT): dracut[32409]: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut:/lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Message from syslogd@lyon at Sep 27 11:43:12 ... dracut: /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? Working. This may take some time ... /lib/modules/3.10.0-693.el7.x86_64//modules.dep is missing. Did you run depmod? /sbin/weak-modules: line 116: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 132: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory /sbin/weak-modules: line 137: /boot/initramfs-3.10.0-693.el7.x86_64.tmp: No such file or directory Unable to decompress /boot/initramfs-3.10.0-693.el7.x86_64.tmp: Unknown format /sbin/weak-modules: line 175: /tmp/weak-modules.oC1A7x/new_initramfs.img: No such file or directory rm: cannot remove '/tmp/weak-modules.oC1A7x/new_initramfs.img': No such file or directory mv: cannot stat '/boot/initramfs-3.10.0-693.el7.x86_64.tmp': No such file or directory Done. Installing : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 etckeeper: post transaction commit Verifying : kmod-nvidia-384.90-1.el7_4.elrepo.x86_64 1/2 Verifying : nvidia-x11-drv-384.90-1.el7.elrepo.x86_64 2/2 Installed: kmod-nvidia.x86_64 0:384.90-1.el7_4.elrepo Dependency Installed: nvidia-x11-drv.x86_64 0:384.90-1.el7.elrepo Complete! Well, no it's not complete, and it's trying to install in the *previous* kernel, not the running one. kmod packages are a special class of package on RHEL that take advantage of the stable kernel ABI in Red Hat Enterprise Linux. When a kmod package is compiled against a kernel, the kernel module will be installed for that kernel and the weak-modules script will then weak link the module against all other kABI-compatible kernels installed on the system. This means that you do not need to rebuild the kernel module for each and every kernel update (or worse, delay updating your kernel whilst you wait for me to rebuild the module for you). Ok. I had thought it did. So yes, the module will likely be installed against a previous kernel, and maybe one that isn't even installed on your system. But it will weak link against your current kernel(s) providing none of the kernel symbols used by the module have changed between the kernel the module was built against and the current kernel in question. If you don't understand, just think of it as magic and be grateful you are running an Enterprise Linux kernel and not a fedora kernel. As to the earlier error messages, have you been playing with depmod? Where is your modules.dep for your installed kernels? Anyway, the magic described above has likely not worked correctly due to missing modules.dep, so I would uninstall the nvidia packages, sort out your kernel(s) / depmod information and try again once you have a sane system. Odd. The original kernel is installed, so I don't know why modules.dep wasn't there. I haven't had to run depmod before. Btw, about your previous email: nvidia-detect tells me to use kmod-nvidia for the K20c. When I go to the elrepo page about it, and follow the link, for the 340, I don't see it supporting them, but the non-legacy does. mark I would trust what nvidia-detect tells you. It is based on the definitive information provided by NVIDIA in their docs: http://us.download.nvidia.com/XFree86/Linux-x86_64/384.90/README/supportedchips.html ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Thunderbird in CentOS 7.4
On 28/09/17 04:19, Alice Wonder wrote: With the current Thunderbird I can not connect to one of my IMAP servers that uses a self-signed cert. Virtually identical IMAP servers that use CA signed certs work I was a bit out of date when I updated to 7.4 and was running Thunderbird 45.6.x and it worked. When I connected from evolution (which I do not like) it worked. When I connected with my laptop still running 45.6.x it works. so - I rebuilt thunderbird 45.8.0 from 7.3 updates (newest that isn't 5x.x.x series) and did an --oldpackage update with RPM and it works again. When rebuilding the old thunderbird in mock I had to add the following: BuildRequires: dbus-glib-devel Either the build system used by CentOS automatically includes that, or a build dependency use to pull that it but no longer does. Anyway if anyone is having a similar problem, that's a solution. -=- This is what I see in the mail server log when current CentOS thunderbird tries to connect: Sep 25 20:17:49 librelamp dovecot: imap-login: Disconnected (no auth attempts in 1 secs): user=<>, rip=2600:1010:b064:f260:e83e:562d:2316:18df, lip=2600:3c01::f03c:91ff:fee4:310c, TLS handshaking: SSL_accept() failed: error:14094418:SSL routines:SSL3_READ_BYTES:tlsv1 alert unknown ca: SSL alert number 48, session= --- Since it works with current evolution and with older thunderbird, I assume it is a bug in current thunderbird when the server is using a self-signed cert. Don't know if same thing happens on pop. I use IMAP on 143 using starttls I have no problem using a self-signed cert on my own private mail server, although admittedly I'm using POP, not IMAP. Have you imported your certificate(s) in thunderbird? Preferences > Advanced > Certificates ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] systemd-networkd issue
On 04/10/17 03:46, Phil Manuel wrote: Hi, If I disable ipv6 via the kernel command line, ipv6.disable=1, then systemd-networkd fails to bring up any interfaces. Removing the option and networking works as expected. Phil. How are you controlling your network interfaces? I am using NM. Whilst not answering your question directly, I disable ipv6 in /etc/sysctl.conf. cat /etc/sysctl.conf # sysctl settings are defined through files in # /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/. # # Vendors settings live in /usr/lib/sysctl.d/. # To override a whole file, create a new file with the same in # /etc/sysctl.d/ and put new settings there. To override # only specific settings, add a file with a lexically later # name in /etc/sysctl.d/ and put new settings there. # # For more information, see sysctl.conf(5) and sysctl.d(5). net.ipv4.ip_forward = 1 net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 After updating, run 'sysctl -p' and 'dracut -f' Works for me. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Missing file in current kernel-devel package
On 05/10/17 18:24, m.r...@5-cent.us wrote: m.r...@5-cent.us wrote: Johnny Hughes wrote: On 10/05/2017 10:17 AM, m.r...@5-cent.us wrote: Albert McCann wrote: From: CentOS [mailto:centos-boun...@centos.org] On Behalf Of m.r...@5-cent.us Sent: Thursday, October 05, 2017 10:58 AM To: CentOS mailing list Subject: Re: [CentOS] Missing file in current kernel-devel package I've identified what my problem is, trying to install the NVidia proprietary drivers: in kernel-devel-3.10.0-514.26.2.el7.x86_64, there is a file /usr/src/kernels/3.10.0-514.26.2.el7.x86_64/include/linux/fence.h It does not exist in the kernel-devel-3.10.0-693.2.2.el7.x86_64 package. Is this something that got missed, or did HR drop it, or? Sorry, but I really don't believe it is good, much less best practice to do something like removing a kernel include file within one release. If they'd made it go a away for 7.0, I would deal, but to suddenly drop it, bad. Tell it to Linus, not us: https://lwn.net/Articles/685049/ Well, I d/l the latest from NVidia, and that one built. Of course, now I'm going to really worry about several of my users, who have old - as in 5-10 year old, NVidia cards, who need legacy drivers, like the 304. mark This issue is fixed in recent releases, including the latest 304.137 legacy release. Nvidia are still actively supporting that driver, even if the hardware is "5-10 years old". ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /boot partition too small
On 10/10/17 15:27, John Hodrien wrote: On Tue, 10 Oct 2017, Pete Biggs wrote: No, you can't do that. /boot is special and needs to be a separate partition. Needs is a bit strong, as grub2 does support LVM. It's not a supported configuration for Redhat. I'm not a sure there's a lot to it beyond having the lvm module loaded in grub, but I've honestly not tried. Indeed, /boot does not need to be a separate partition. I have /boot within the root filesystem on my test boxes where I know I will need to install many / all kernels for testing / development purposes for the specific reason that I do not need to set a size for /boot and it can just consume whatever it needs from the rest of the filesystem. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [CentOS-announce] CESA-2017:2907 Important CentOS 7 wpa_supplicant Security Update
On 18/10/17 17:24, Yves Bellefeuille wrote: Johnny Hughes wrote: CentOS Errata and Security Advisory 2017:2907 Important Upstream details at : https://access.redhat.com/errata/RHSA-2017:2907 Will there also be an update for CentOS 6? Or does the problem not exist with CentOS 6? Yes, there is an update for RHEL6 so I'm sure CentOS will get it out shortly: https://access.redhat.com/errata/RHSA-2017:2911 ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] NBD does not compile for 3.10.0-514.26.2.el7.x86_64
On 30/10/17 14:19, Thanos Makatos wrote: Compiling NBD kernel module for kernel 3.10.0-514.26.2.el7.x86_64 fails as follows: # make -C ../../ M=`pwd` nbd.o make: Entering directory `/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64' CC /root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.o /root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c: In function ‘__nbd_ioctl’: /root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c:619:19: error: ‘REQ_TYPE_SPECIAL’ undeclared (first use in this function) sreq.cmd_type = REQ_TYPE_SPECIAL; ^ /root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.c:619:19: note: each undeclared identifier is reported only once for each function it appears in make[1]: *** [/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64/drivers/block/nbd.o] Error 1 make: *** [nbd.o] Error 2 make: Leaving directory `/root/rpmbuild/BUILD/kernel-3.10.0-514.26.2.el7/linux-3.10.0-514.26.2.el7.x86_64' Was support for NBD dropped or was this just a human error? Because Red Hat do not configure and build this module, they do not maintain the code for it in their kernel. REQ_TYPE_SPECIAL was renamed to REQ_TYPE_DRV_PRIV some time back, so try patching for that in nbd.c and rebuilding. Be aware that by building the unmaintained module you will be missing all relevant security patches for this module since RHEL7 was first released some 3.5 years ago. A better solution would be to backport the module from the latest upstream kernel and maintain it out of tree. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia error
On 06/11/17 18:19, Jerry Geis wrote: yes the error is still the .90 I looked back, everything was working Friday... I did a yum update on Friday but did not reboot. I rebooted this morning and I have the issue. The kernel package before was NOT the 693.5.2 it was 692.2.2 Does that help at all ? my kernel is not yet supported or something ? Jerry Hi Jerry, Yes, it is supported and it should work, so I'm not sure what has gone wrong for you (other than you failed to reboot after the update), but lets see if we can fix it. Please start by uninstalling and reinstalling the nvidia packages to see if that fixes the issue: yum erase kmod-nvidia nvidia-x11-drv yum install kmod-nvidia nvidia-x11-drv and reboot the system. If it's still not working after a reboot, please could you post any error messages (again) together with the output (as root) from: lsinitrd -k $(uname -r) | grep nvidia.*ko and the output from: find /lib/modules/ -name nvidia*.ko ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Logitech Brio 4K Ultra HD Webcam - 960-001105
On 11/11/17 02:22, Gregory P. Ennis wrote: Everyone, I was hoping to be able to plug the Logitech Brio in and have it work, but it did not. I can have it connect to a Windows 10 laptop and have it function, so I know the camera works. The Centos 7.4 is recognizing it when I plug in the usb 3.0 cable. The results of dmesg demonstrated : [ 4519.922257] input: Logitech BRIO as /devices/pci:00/:00:04.0/:03:00.0/usb9/9-4/9- 4:1.4/input/input25 [ 4519.922402] hid-generic 0003:046D:085E.0009: input,hidraw0: USB HID v1.11 Device [Logitech BRIO] on usb-:03:00.0-4/input4 [ 4519.956452] usb 9-4: current rate 16000 is different from the runtime rate 48000 [ 4519.963948] usb 9-4: current rate 16000 is different from the runtime rate 48000 [ 4519.973798] usb 9-4: current rate 16000 is different from the runtime rate 48000 [ 4825.386775] usb 9-4: reset SuperSpeed USB device number 7 using xhci_hcd [ 5079.321074] usb 9-4: USB disconnect, device number 7 I am not seeing any new device driver in /dev/ Testing the programs 'cheese', 'vlc', and 'ucview' did not identify the camera. I have used Logitech C922 webcams with Centos 7.4 which work just by plugging them in. Does anyone have any ideas as to how to make this 4K camera work on 7.4? Thanks for your help!!! Greg Ennis You will need the appropriate device driver for it, and that driver will need to support the device. Probably the easiest way to see if the device is supported on Linux yet is to boot the very latest kernel, which conveniently for you is packaged in RPM format in the elrepo-kernel repository. Head over to elrepo and set up the repository on your system: http://elrepo.org/ then install the latest mainline kernel: yum --enablerepo=elrepo-kernel install kernel-ml Reboot to that new kernel (currently kernel-ml-4.13.12) and see again if the device is supported. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Logitech Brio 4K Ultra HD Webcam - 960-001105
On 12/11/17 22:15, Gregory P. Ennis wrote: On 11/11/17 02:22, Gregory P. Ennis wrote: Everyone, I was hoping to be able to plug the Logitech Brio in and have it work, but it did not. I can have it connect to a Windows 10 laptop and have it function, so I know the camera works. The Centos 7.4 is recognizing it when I plug in the usb 3.0 cable. The results of dmesg demonstrated : [ 4519.922257] input: Logitech BRIO as /devices/pci:00/:00:04.0/:03:00.0/usb9/9-4/9- 4:1.4/input/input25 [ 4519.922402] hid-generic 0003:046D:085E.0009: input,hidraw0: USB HID v1.11 Device [Logitech BRIO] on usb-:03:00.0-4/input4 [ 4519.956452] usb 9-4: current rate 16000 is different from the runtime rate 48000 [ 4519.963948] usb 9-4: current rate 16000 is different from the runtime rate 48000 [ 4519.973798] usb 9-4: current rate 16000 is different from the runtime rate 48000 [ 4825.386775] usb 9-4: reset SuperSpeed USB device number 7 using xhci_hcd [ 5079.321074] usb 9-4: USB disconnect, device number 7 I am not seeing any new device driver in /dev/ Testing the programs 'cheese', 'vlc', and 'ucview' did not identify the camera. I have used Logitech C922 webcams with Centos 7.4 which work just by plugging them in. Does anyone have any ideas as to how to make this 4K camera work on 7.4? Thanks for your help!!! Greg Ennis You will need the appropriate device driver for it, and that driver will need to support the device. Probably the easiest way to see if the device is supported on Linux yet is to boot the very latest kernel, which conveniently for you is packaged in RPM format in the elrepo-kernel repository. Head over to elrepo and set up the repository on your system: http://elrepo.org/ then install the latest mainline kernel: yum --enablerepo=elrepo-kernel install kernel-ml Reboot to that new kernel (currently kernel-ml-4.13.12) and see again if the device is supported. --- Phil, Thank you very much. After booting to the new kernel the camera worked very well with vlc and ucview, but did not work with cheese. I have never used a kernel from your website. After checking whether some of the things I use for production work with the new kernel, I did not identify any problems. Are there things I should consider, or is this kernel reasonable to use on a production basis. Thanks again Greg I would refer you to the release announcement: http://lists.elrepo.org/pipermail/elrepo/2017-November/003904.html Use at your own risk. But at least you now know the device is supported upstream, so you can head over to Red Hat and file an RFE to request support be backported from the upstream kernel. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] gnome boot problem
On 16/11/17 22:32, Pete Biggs wrote: On Thu, 2017-11-16 at 16:28 -0500, dominic adair-jones wrote: greetings all. running centos 7. i recently performed an upgrade and the server rebooted later in the night. now everytime i start my server its sits at the grey gnome background. i can hit ctl+atl+f2 to get to another console and the error message states "a start job is running for wait for plymouth boot screen to quit". i can ssh into the server but i dont see any obvious issues. this is the brain of my network and houses all my vms and documents. any help would be greatly appreciated. There's lots of reasons for this - try googling for that message. A common one is bad video drivers, especially nVidia - nVidia helpfully stop supporting certain older cards in the newer drivers, so if you have a card that drops support in the most recent driver, you have to specifically use an old driver version. ...and if you use the nvidia driver packages from elrepo, the yum-plugin-nvidia package prevents yum from updating nvidia drivers on older hardware where support for that hardware has been dropped. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Broadcom BCM4360
On 04/12/17 00:38, John R Pierce wrote: On 12/3/2017 4:22 PM, Gregory P. Ennis wrote: I have not been able to get it to work Centos 7.4 machine. Some of the centos user posts had indicated the nux repsitory had a Centos 7 kmod- wl, but it is not present when I tried to search or or install it at this time. this looks potentionally helpful http://elrepo.org/tiki/wl-kmod it appears those are closed source drivers with funky licenses, so they can't just be redistributed without assumption of liability. Correct, elrepo isn't able to freely redistribute the drivers due Broadcom's licensing, but does provide instructions and a SRPM (minus tarball) for you to build yourself. Alternatively, for $8 you can purchase an adaptor that is natively supported and will work out of the box: https://www.amazon.com/Edimax-EW-7811Un-150Mbps-Raspberry-Supports/dp/B003MTTJOY/ref=sr_1_1?ie=UTF8&qid=1512370979&sr=8-1&keywords=edimax+n150 https://www.newegg.com/Product/Product.aspx?Item=N82E16833315091&cm_re=edimax_n150-_-33-315-091-_-Product The above adaptor is based on the Realtek RTL8188CUS chipset and uses the rtl8192cu kernel driver. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Question on CentoS 7.4 on nvidia
On 15/12/17 00:21, Jerry Geis wrote: So I removed the nvidia items and reinstalled. In /var/log/messages I saw dracut commands for every kernel EXCEPT the 4.14.5 elrepo kernel. So I did it manually and I get an error. /usr/bin/dracut --add-drivers nvidia -f /boot/initramfs-4.14.5-1.el7.elrepo.x86_64.img 4.14.5-1.el7.elrepo.x86_64 Failed to install module nvidia No sure what to do. Jerry The elrepo kmod packages ONLY support the distro RHEL/CentOS kernels. They are NOT compatible with any other non-KABI compatible kernels, including the mainline and LTS kernel packages from elrepo. Hope that helps. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
On 03/01/18 15:45, Danny Smit wrote: Hi everyone, On CentOS 7 I'm running into an issue with the latest nvidia driver from elrepo: kmod-nvidia-384.98-1.el7_4.elrepo.x86_64 This driver version seem to introduce issue in detecting video modes when a monitor is connected using DVI. As soon as the machine attempts to start X, nothing happens and the monitor goes into sleep mode reporting that it has 'no signal'. It is interesting because it occurs with several monitors, but only when they are connected through DVI. When using VGA it works like a charm. Also it did work without problems with the previous driver version (kmod-nvidia-384.90-1.el7_4.elrepo.x86_64), with the exact same setup. In this case the issue occurs with an Nvidia NVS 315. I don't know if other nvidia cards are affected. The following information from Xorg.0.log seems of interest: [ 130.447] (--) NVIDIA(0): Valid display device(s) on GPU-0 at PCI:1:0:0 [ 130.447] (--) NVIDIA(0): CRT-0 [ 130.447] (--) NVIDIA(0): CRT-1 [ 130.447] (--) NVIDIA(0): DFP-0 (boot) [ 130.447] (--) NVIDIA(0): DFP-1 [ 130.447] (--) NVIDIA(0): DFP-2 [ 130.447] (--) NVIDIA(0): DFP-3 [ 130.448] (II) NVIDIA(0): NVIDIA GPU NVS 315 (GF119) at PCI:1:0:0 (GPU-0) [ 130.448] (--) NVIDIA(0): Memory: 1048576 kBytes [ 130.448] (--) NVIDIA(0): VideoBIOS: 75.19.88.00.0b [ 130.448] (II) NVIDIA(0): Detected PCI Express Link width: 16X [ 130.462] (--) NVIDIA(GPU-0): CRT-0: disconnected [ 130.462] (--) NVIDIA(GPU-0): CRT-0: 400.0 MHz maximum pixel clock [ 130.462] (--) NVIDIA(GPU-0): [ 130.467] (--) NVIDIA(GPU-0): CRT-1: disconnected [ 130.467] (--) NVIDIA(GPU-0): CRT-1: 400.0 MHz maximum pixel clock [ 130.467] (--) NVIDIA(GPU-0): [ 130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): connected [ 130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): Internal TMDS [ 130.488] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): 0.0 MHz maximum pixel clock [ 130.488] (--) NVIDIA(GPU-0): [ 130.493] (--) NVIDIA(GPU-0): DFP-1: disconnected [ 130.493] (--) NVIDIA(GPU-0): DFP-1: Internal TMDS [ 130.493] (--) NVIDIA(GPU-0): DFP-1: 0.0 MHz maximum pixel clock [ 130.493] (--) NVIDIA(GPU-0): [ 130.493] (--) NVIDIA(GPU-0): DFP-2: disconnected [ 130.493] (--) NVIDIA(GPU-0): DFP-2: Internal DisplayPort [ 130.493] (--) NVIDIA(GPU-0): DFP-2: 480.0 MHz maximum pixel clock [ 130.493] (--) NVIDIA(GPU-0): [ 130.493] (--) NVIDIA(GPU-0): DFP-3: disconnected [ 130.493] (--) NVIDIA(GPU-0): DFP-3: Internal DisplayPort [ 130.493] (--) NVIDIA(GPU-0): DFP-3: 480.0 MHz maximum pixel clock [ 130.493] (--) NVIDIA(GPU-0): [ 130.493] (EE) NVIDIA(GPU-0): Unable to add conservative default mode "nvidia-auto-select". [ 130.493] (EE) NVIDIA(GPU-0): Unable to add "nvidia-auto-select" mode to ModePool. [ 130.493] (==) NVIDIA(0): [ 130.493] (==) NVIDIA(0): No modes were requested; the default mode "nvidia-auto-select" [ 130.493] (==) NVIDIA(0): will be used as the requested mode. [ 130.493] (==) NVIDIA(0): [ 130.493] (WW) NVIDIA(0): No valid modes for "DFP-0:nvidia-auto-select"; removing. [ 130.493] (WW) NVIDIA(0): [ 130.493] (WW) NVIDIA(0): Unable to validate any modes; falling back to the default mode [ 130.493] (WW) NVIDIA(0): "nvidia-auto-select". [ 130.493] (WW) NVIDIA(0): [ 130.493] (WW) NVIDIA(0): No valid modes for "DFP-0:nvidia-auto-select"; removing. [ 130.493] (EE) NVIDIA(0): Unable to use default mode "nvidia-auto-select". [ 130.493] (EE) NVIDIA(0): Failing initialization of X screen 0 The log shows "0.0 MHz maximum pixel clock" for the DVI connections. When enabling ModeDebug in the xorg.conf it shows that all of the resolutions are rejected because of incorrect maximum pixel clock: [ 1354.589] (II) NVIDIA(GPU-0): [ 1354.589] (II) NVIDIA(GPU-0): --- Building ModePool for Philips 240S4 (DFP-0) --- [ 1354.589] (WW) NVIDIA(GPU-0): Validating Mode "1920x1200_60": [ 1354.589] (WW) NVIDIA(GPU-0): Mode Source: EDID [ 1354.589] (WW) NVIDIA(GPU-0): 1920 x 1200 @ 60 Hz [ 1354.589] (WW) NVIDIA(GPU-0): Pixel Clock : 154.00 MHz [ 1354.589] (WW) NVIDIA(GPU-0): HRes, HSyncStart : 1920, 1968 [ 1354.589] (WW) NVIDIA(GPU-0): HSyncEnd, HTotal : 2000, 2080 [ 1354.589] (WW) NVIDIA(GPU-0): VRes, VSyncStart : 1200, 1203 [ 1354.589] (WW) NVIDIA(GPU-0): VSyncEnd, VTotal : 1209, 1235 [ 1354.589] (WW) NVIDIA(GPU-0): Sync Polarity: +H -V [ 1354.589] (WW) NVIDIA(GPU-0): Mode is rejected: PixelClock (154.0 MHz) too high for [ 1354.589] (WW) NVIDIA(GPU-0): Display Device (Max: 0.0 MHz). [ 1354.589] (WW) NVIDIA(GPU-0): Mode "1920x1200_60" is inval
Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
On 03/01/18 20:14, Zube wrote: On Wed Jan 03 07:43:04 PM, Phil Perry wrote: On CentOS 7 I'm running into an issue with the latest nvidia driver from elrepo: kmod-nvidia-384.98-1.el7_4.elrepo.x86_64 This driver version seem to introduce issue in detecting video modes when a monitor is connected using DVI. As soon as the machine attempts to start X, nothing happens and the monitor goes into sleep mode reporting that it has 'no signal'. It is interesting because it occurs with several monitors, but only when they are connected through DVI. When using VGA it works like a charm. Also it did work without problems with the previous driver version (kmod-nvidia-384.90-1.el7_4.elrepo.x86_64), with the exact same setup. In this case the issue occurs with an Nvidia NVS 315. I don't know if other nvidia cards are affected. I can confirm that this happens with the driver downloaded from NVIDIA. I had to fall back to the .90 driver to get it to work for all my NVS 315s (with dual DVI) running on 7.4 / 6.9. Thank you for the confirmation. I found a similar report on debian also relating to NVS315 with the 384.98 driver so I'm guessing this is hardware specific: https://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg1570324.html I couldn't find any reports upstream at nvidia so am unsure if they are aware of the issue. For reference, my GK208 [GeForce GT 730] in my test system is unaffected by the issue and is working fine with the 384.98 driver over DVI. There is an updated version 387.34 short-lived branch driver available in the elrepo testing repository that you could test to see whether the issue has been fixed in this latest release (only available for el7 currently). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
On 04/01/18 09:12, Danny Smit wrote: On Thu, Jan 4, 2018 at 5:22 AM, Phil Perry wrote: On 03/01/18 20:14, Zube wrote: I can confirm that this happens with the driver downloaded from NVIDIA. I had to fall back to the .90 driver to get it to work for all my NVS 315s (with dual DVI) running on 7.4 / 6.9. Thanks. For reference, I did the same test. With the driver downloaded from NVIDIA the issues also occurs in my case. I couldn't find any reports upstream at nvidia so am unsure if they are aware of the issue. Where do you look for this at nvidia, in the community forums? Or is there another publicly available bug tracking system? (which I was unable to find) I would start by posting in the forums as you did (below). I'm not aware of an official bug tracker either. There is an updated version 387.34 short-lived branch driver available in the elrepo testing repository that you could test to see whether the issue has been fixed in this latest release (only available for el7 currently). Surprisingly, I couldn't reproduce the issue anymore. Therefore at first sight it seems to be fixed in the 387.34 driver. Excellent. Hopefully sounds like the issue may already have been fixed. I posted a question at nvidia anyway: https://devtalk.nvidia.com/default/topic/1028268/linux/nvidia-maximum-pixel-clock-issue-in-kmod-nvidia-384-98/ (although I'm not sure it is the right place, still having some issues finding my way at nvidia.com, other suggestions or directions are welcome of course) Yes, I would have posted to the same place. Will short-lived drivers ever make it into the official elrepo repository? Or will only the long-lived drivers be included in the official repository? Normally elrepo only releases the long term branch for Enterprise Linux, on the assumption EL users will welcome the implied stability over more frequent and potentially buggy releases. In this case I had built the current short lived release as a user requested it for compatibility with the latest CUDA. However, as it is a short term branch release, it will stay in the testing repository indefinitely and will not be promoted to the main repository. Once it's been superseded by a subsequent long term branch release I will likely just delete it from the testing repo. That said, it should be fine to use (at your own risk). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
On 06/01/18 12:00, Zube wrote: On Sat Jan 06 12:27:22 PM, Danny Smit wrote: I normally certainly prefer the stability of the long-lived releases. I noticed an update was just released of the long-lived release: 384.111. The notes for this release say: Fixed a regression that prevented displays connected via some types of passive adapters (e.g. DMS-59 to VGA or DVI) from working correctly. The regression was introduced with driver version 384.98. That sounds very much like my issue. I will verify next Monday if that solves it for me. Can I assume that new 384.111 release will make it into the main elrepo repository eventually? I can confirm the 384.111 version fixes the DVI problems with the NVS-315. Cheers, Zube I've just built and released 384.111 to the elrepo main repository, so it should show up on the mirrors shortly. Thanks for the confirmation it fixes the issue. I've just updated my local machine, which was unaffected by this issue, ran a few quick tests (glmark2) and can confirm 384.11 looks fine on my hardware. Just keep in mind, this will be a package 'downgrade' from version 387.34 in the elrepo testing repository due to the lower version number. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CVE-2017-5715, CVE-2017-5753 and CVE-2017-5754
On 07/01/18 16:11, Mike McCarthy, W1NR wrote: How about kernel-lt and kernel-ml? Mike Mike, If you are referring to kernel-lt and kernel-ml packages offered by elrepo, may I refer you to this post / thread: http://lists.elrepo.org/pipermail/elrepo/2018-January/004031.html Essentially, kernel-lt and kernel-ml contain all the latest fixes that are in the equivalent upstream kernel versions. Further, I'd highly recommend you read Greg Kroah-Hartman's blog posting (below) summarising the current state of play within the Linux kernel for Meltdown and Spectre issues: http://www.kroah.com/log/blog/2018/01/06/meltdown-status/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
On 08/01/18 10:22, Danny Smit wrote: On Sat, Jan 6, 2018 at 2:27 PM, Phil Perry wrote: I've just built and released 384.111 to the elrepo main repository, so it should show up on the mirrors shortly. As expected, the 384.111 also solves the problem in my case. Thanks for the support everyone. Thanks for the feedback Danny - glad we got it resolved. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6
On 17/01/18 21:24, Valeri Galtsev wrote: Dear All, An update just brought on my CenOS 6 boxes updated microcode.dat files: /lib/firmware/microcode.dat Does anybody know off hand what (how critical) is that, as, if it is related to most famous these days trouble with CPU hardware, I will need to reboot relevant boxes to have new microcode loaded. But if it is not that critical, it can wait till next reboot. Thanks a lot and apologies for laziness (not looking into details of this particular update myself). See: https://access.redhat.com/errata/RHSA-2018:0093 Red Hat have rolled back the recent microcode updates for Spectre as they were causing instabilities in some systems. Updated microcode was only made available for a relatively small number of CPUs so it might be the case that the your microcode was never actually updated, hence there is nothing to roll back in the latest release, so no need to panic about rebooting. Checking /var/log/messages should give you more clues when your microcode was actually last updated and allow you to determine if it was before or after the recent Spectre fiasco. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] /lib/firmware/microcode.dat update on CentOS 6
On 18/01/18 18:55, Matthew Miller wrote: On Thu, Jan 18, 2018 at 11:45:42AM -0500, Pete Geenhuizen wrote: Do we update the microcode now or do we wait until the latest microcode_ctl rpm is available and then tackle this issue? Check with your hardware vendor for BIOS/EFI firmware updates. Apply those. Thanks for the reply, but you missed what I was asking. I've already downloaded the appropriate files from the links that Johnny provided in a previous posting. My question is, do we wait until the latest microcode_ctl rpm is installed or do it now? My concern is that if I do it now the new rpm might undo what I've done. It does not matter. The microcode_ctl package contains CPU firmware that is loaded at by the kernel early in the boot process if it's newer than the one provided by the system firmware/BIOS. It is never permanently stored in NVRAM or anything — it's loaded at each boot. Hence, by my understanding, there should not be any permanent damage should you get a 'bad' microcode update, either from Intel or Red Hat, that prevents the system from booting. Presumably one should still always be able to boot the machine from a rescue disk, mount the fs and either delete the offending microcode or uninstall the microcode_ctl package to allow the system to boot again. This should not result in a 'bricked' permanently unrecoverable system. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Error installing Nvidia driver on a 7.5 beta kernel
On 02/02/18 15:30, James Pearson wrote: OK, I know CentOS has nothing to do with RHEL beta releases, but I wanted to test if el7.5 has added support for a particular peripheral (Wacom Pro 2 tablet) ... but was unable to install the propriety Nvidia display driver (v390.25) on a test workstation - and was wondering if anyone could explain on what is going on. All I've done is upgrade an existing CentOS 7.4 install with the RHEL 7.5 beta kernel RPMS However, when installing the Nvidia driver, it fails with: FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__cachemode2pte_tbl' A bit of Googling seems to suggest that this issue has been 'fixed' in later upstream kernels by changing the export of this symbol from 'EXPORT_SYMBOL_GPL' to 'EXPORT_SYMBOL' However, 7.4 and earlier el7 kernels also export this symbol as EXPORT_SYMBOL_GPL - but the Nvidia driver builds/installs fine on 7.4 kernels ... So, I'm not really sure what the issue is - i.e. is it an Nvidia or Redhat issue ? It looks like a regression. This was originally fixed upstream (kernel.org) 3 years ago, so if the RHEL7.5 beta kernel has reverted to 'EXPORT_SYMBOL_GPL' then it is a regression that will break building any out-of-tree non-gpl modules which need to set caching mode in pte's You should file a bug report with Red Hat. For now, I've managed to hack around this by patching the stub Nvidia driver src to change MODULE_LICENSE from "NVIDIA" to "GPL" - and the Nvidia driver now installs and loads OK The correct fix in the kernel is in arch/x86/mm/init.c -EXPORT_SYMBOL_GPL(__cachemode2pte_tbl); +EXPORT_SYMBOL(__cachemode2pte_tbl); If anyone knows any more about this, then please let me know Thanks James Pearson ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
