Re: [CentOS] Lenovo M900 with CentOS 7 strangeness
Dear Walter, thanks for your answer. I did not touch any settings between installation and the final system. That what confused me. There was no change at all between working and non working USB state just a simple reboot. To make things more complex. First time, when failed, I installed from external USB single sided DVD media. I have another M900 machine. Now I made a USB pendrive installer from double sided DVD media (called everything). And now it is working. The two machines is exactly the same based on the serial numbers, checked on Lenovo site, but I have seen some difference between BIOS settings. No idea why. Now I try to investigate what is "problem" with the first machine. And why there is such BIOS differences. BR, Zsolt On Thu, Mar 2, 2017 at 11:21 PM, Walter Dnes wrote: > On Wed, Mar 01, 2017 at 05:55:21PM +0100, SZ, Zsolt wrote > > Hello, > > > > I would like to install CentOS 7.3 on my new Lenovo M900 machine. I am > > using the official 1 DVD installer. The installation process was fine > > without any error but after reboot the USB keyboard and the USB mouse did > > not work. Therefore I was not able to type anything or pass the first > boot > > screen. Only the power button is working. > > > > Any idea why? I believe the installation media is using the same kernel > > components as the installed machine. So why the installer is working and > > the installed system is not? > > Did you disable UHCI (low speed) USB support during the install? USB > keyboards and mice use that protocol on Intel and Via USB chipsets. > There's also an OHCI (low speed) USB driver for non-x86 chipsets. > > -- > Walter Dnes > ___ > 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] MRTG and eth0
Matt writes: > Is there an easy way to graph ethernet eth0 on Centos 7 with MRTG > without using SNMP? I thought I found a way to do this in past by > using a shell script to poll the interface but cannot find it back. Yes, this is very easy and the required script is very simple. See http://oss.oetiker.ch/mrtg/doc/mrtg-reference.en.html, "External Monitoring Scripts". You can write a small script around ifconfig or ip, as you wish. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Laptop turns off after lid closed Centos6
On 03/02/2017 09:08 AM, david wrote: > Folks > > I have a laptop which i am using temporarily as a test server. > It is permanently plugged in. It is running Centos 6, command > line only. In the past, I could close the lid, thereby turning > off the display, but not turning off the machine. It remained > running indefinitely. a laptop makes a nice 24/7/365 server. using 'extend battery pack' or 'oem' pack? > A recent update (this past week) changed that behavior. Now, > when I close the lid, the laptop turns itself off within an hour. you need a battery manager/monitor program to set up lid switch. or use a 'script' to switch. any settings in bios config? > A google search talks about tools like "upower" and apcitool, > but a "yum search" does not locate them. yum knows where to 'look for what' in directory /etc/yum.repos.d have a look at: http://yum.baseurl.org/wiki/ then read: http://yum.baseurl.org/wiki/Faq > Is there a way to revert back to the previous behavior? get a battery manager, do not 'roll back'. questions:: make/model? oem manual? -- The important thing is not to stop questioning. - Albert Einstein CentOS GNU/Linux 6.8 -- KDE 4.3.4 Firefox 45.7.0 -- Thunderbird 45.6.0 GNUCash 2.4.15 -- zoneminder 1.30.0 peace out. tc,hago. g . =+= Tired of having your microsoft os hacked? Change to Linux os, used by microsoft hackers. =+= in a world with out fences, who needs gates. =+= ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-5 End of Life
In article , James Hogarth wrote: > > This is especially important if you use anything from EPEL as EPEL5 will be > removed when RHEL goes EOL. You mean just thrown away, or archived somewhere? Just thrown away would seem rather irresponsible... Cheers Tony -- Tony Mountifield Work: t...@softins.co.uk - http://www.softins.co.uk Play: t...@mountifield.org - http://tony.mountifield.org ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-5 End of Life
On Fri, 3 Mar 2017, Tony Mountifield wrote: You mean just thrown away, or archived somewhere? Just thrown away would seem rather irresponsible... Mirroring EPEL makes sense well before this point, as they don't keep old versions of packages online either AFAIK. jh ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-5 End of Life
On 3 March 2017 at 11:34, John Hodrien wrote: > On Fri, 3 Mar 2017, Tony Mountifield wrote: > >> You mean just thrown away, or archived somewhere? Just thrown away would >> seem rather irresponsible... > > > Mirroring EPEL makes sense well before this point, as they don't keep old > versions of packages online either AFAIK. > > jh > > Indeed they aren't kept ... and since there hasn't been an EOL of EPEL before I honestly have no idea ... I've asked on the epel-devel mailing list as to whether it'll move to archive like old fedora releases do. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-5 End of Life
On 3 March 2017 at 11:47, James Hogarth wrote: > On 3 March 2017 at 11:34, John Hodrien wrote: >> On Fri, 3 Mar 2017, Tony Mountifield wrote: >> >>> You mean just thrown away, or archived somewhere? Just thrown away would >>> seem rather irresponsible... >> >> >> Mirroring EPEL makes sense well before this point, as they don't keep old >> versions of packages online either AFAIK. >> >> jh >> >> > > Indeed they aren't kept ... and since there hasn't been an EOL of EPEL > before I honestly have no idea ... I've asked on the epel-devel > mailing list as to whether it'll move to archive like old fedora > releases do. My mistake - I forgot there was an EPEL4 in the mists of time .. so the last version of the repo is likely to end up here: http://archive.fedoraproject.org/pub/epel/ ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] imaging a drive with dd
On Thu, Mar 02, 2017 at 10:57:51PM -0500, Robert Moskowitz wrote: > > > On 03/02/2017 10:02 PM, Fred Smith wrote: > >On Thu, Mar 02, 2017 at 09:06:52PM -0500, fred roller wrote: > >>On Thu, Mar 2, 2017 at 8:36 PM, Robert Moskowitz > >>wrote: > >> > >>>dd if=/dev/sdb of=os.img bs=1M count=3210 > >>> > >>I would recommend bs=512 to keep the block sizes the same though not a huge > >>diff just seems to be happier for some reason and add status=progress if > >>you would like to monitor how it is doing. Seems the command you have > >>should work otherwise. > >The dd blocksize has nothing to do with the disk sector size. > > > >the disk sector size is the number of bytes in a minimal read/write > >operation (because the physical drive can't manipulate anything smaller). > > > >the dd blocksize is merely the number of bytes read/written in a > >single read/write operation. (or not bytes, but K, or Kb, or other > >depending on the options you use.) > > > >It makes sense for the bs option in dd to be a multiple of the actual > >disk block/sector size, but isn't even required. if you did dd with a > >block size of, e.g., 27, it would still work, it'd just be stupidly slow. > > Kind of wondered about that. > > So the blocks reported by fdisk is what I should use as the count, > as that matches the drive's real block size? > > thanks if you're copying the entire device, you do not need to tell it how many blocks. just use a large-ish blocksize and let 'er rip. for a single partition, you could use the blocksize and block number you get from fdisk. you would then need to say /dev/sda4, e.g., instead of /dev/sda. when copying an entire drive I tend to use 10M as the blocksize. using a large blocksize just reduces the number of read operations that are needed. that's why a very small blocksize could slow down the copy, as it would require a whole lot more read operations. -- Fred Smith -- fre...@fcshome.stoneham.ma.us - "Not everyone who says to me, 'Lord, Lord,' will enter the kingdom of heaven, but only he who does the will of my Father who is in heaven." -- Matthew 7:21 (niv) - ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS-5 End of Life
In article , James Hogarth wrote: > On 3 March 2017 at 11:47, James Hogarth wrote: > > On 3 March 2017 at 11:34, John Hodrien wrote: > >> On Fri, 3 Mar 2017, Tony Mountifield wrote: > >> > >>> You mean just thrown away, or archived somewhere? Just thrown away would > >>> seem rather irresponsible... > >> > >> Mirroring EPEL makes sense well before this point, as they don't keep old > >> versions of packages online either AFAIK. > >> > >> jh > > > > Indeed they aren't kept ... and since there hasn't been an EOL of EPEL > > before I honestly have no idea ... I've asked on the epel-devel > > mailing list as to whether it'll move to archive like old fedora > > releases do. > > My mistake - I forgot there was an EPEL4 in the mists of time .. so > the last version of the repo is likely to end up here: > > http://archive.fedoraproject.org/pub/epel/ Cool, thanks! Tony -- Tony Mountifield Work: t...@softins.co.uk - http://www.softins.co.uk Play: t...@mountifield.org - http://tony.mountifield.org ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] imaging a drive with dd
On 03/03/2017 07:50 AM, Fred Smith wrote: On Thu, Mar 02, 2017 at 10:57:51PM -0500, Robert Moskowitz wrote: On 03/02/2017 10:02 PM, Fred Smith wrote: On Thu, Mar 02, 2017 at 09:06:52PM -0500, fred roller wrote: On Thu, Mar 2, 2017 at 8:36 PM, Robert Moskowitz wrote: dd if=/dev/sdb of=os.img bs=1M count=3210 I would recommend bs=512 to keep the block sizes the same though not a huge diff just seems to be happier for some reason and add status=progress if you would like to monitor how it is doing. Seems the command you have should work otherwise. The dd blocksize has nothing to do with the disk sector size. the disk sector size is the number of bytes in a minimal read/write operation (because the physical drive can't manipulate anything smaller). the dd blocksize is merely the number of bytes read/written in a single read/write operation. (or not bytes, but K, or Kb, or other depending on the options you use.) It makes sense for the bs option in dd to be a multiple of the actual disk block/sector size, but isn't even required. if you did dd with a block size of, e.g., 27, it would still work, it'd just be stupidly slow. Kind of wondered about that. So the blocks reported by fdisk is what I should use as the count, as that matches the drive's real block size? thanks if you're copying the entire device, you do not need to tell it how many blocks. just use a large-ish blocksize and let 'er rip. for a single partition, you could use the blocksize and block number you get from fdisk. you would then need to say /dev/sda4, e.g., instead of /dev/sda. when copying an entire drive I tend to use 10M as the blocksize. using a large blocksize just reduces the number of read operations that are needed. that's why a very small blocksize could slow down the copy, as it would require a whole lot more read operations. Well, I only wanted to copy the used part of the drive which I try to keep small so I can still copy the image to an mSD card if I wish. So I have to supply the amount of the drive to copy. The bs=512 went fast enough, but then I was only copying 3.2GB. thanks for the help. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] what's the max thread number per process in centos
On Mar 2, 2017 3:54 PM, "Kenneth Porter" wrote: On 3/2/2017 2:05 AM, qw wrote: > what's the max thread number per process in centos? > http://stackoverflow.com/questions/344203/maximum-number-of- threads-per-process-in-linux http://unix.stackexchange.com/questions/47595/linux-max-threads-count L Thanks for posting this. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus ___ 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] CentOS-5 End of Life
On 2017-03-03 14:14, Tony Mountifield wrote: > In article > , > James Hogarth wrote: >> On 3 March 2017 at 11:47, James Hogarth wrote: >>> On 3 March 2017 at 11:34, John Hodrien wrote: On Fri, 3 Mar 2017, Tony Mountifield wrote: > You mean just thrown away, or archived somewhere? Just thrown away would > seem rather irresponsible... Mirroring EPEL makes sense well before this point, as they don't keep old versions of packages online either AFAIK. jh >>> Indeed they aren't kept ... and since there hasn't been an EOL of EPEL >>> before I honestly have no idea ... I've asked on the epel-devel >>> mailing list as to whether it'll move to archive like old fedora >>> releases do. >> My mistake - I forgot there was an EPEL4 in the mists of time .. so >> the last version of the repo is likely to end up here: >> >> http://archive.fedoraproject.org/pub/epel/ > Cool, thanks! > > Tony I am mirroring the EPEL from official mirrors and the EPEL4 content is stills there: 1.9Gpub/mirrors/epel/4 7.3Gpub/mirrors/epel/5 15G pub/mirrors/epel/6 16G pub/mirrors/epel/7 //Zdenek ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C 7.3 sshd will not reload
On Thu, Mar 02, 2017 at 11:29:24AM -0500, m...@tdiehl.org wrote: > Hi, > > Since upgrading to 7.3 I am having a problem getting sshd to reload after > configuration changes. When I issue the command "systemctl reload > sshd.service" > > I get the following error: "Unit sshd.service cannot be reloaded because it > is inactive." upstream see https://bugzilla.redhat.com/show_bug.cgi?id=1381997 openssh-7.4p1-1.el7 should fix it. Cheers Tru -- Tru Huynh http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xBEFA581B pgpEi1lwDewbx.pgp Description: PGP signature ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] New C7 kernel ABI and kmods
All, This is just a heads-up that the new C7 update kernel breaks ABI compatibility, at least as far as using the ELrepo nVidia drivers is concerned. I have posted more details to the ELrepo list; but since many folks use the Elrepo kmods I thought a heads-up would be appropriate. If you use the ELrepo nvidia kmod you will either need to hold off on the kernel update or uninstall the nvidia kmod. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] imaging a drive with dd
On 3/3/2017 5:34 AM, Robert Moskowitz wrote: Well, I only wanted to copy the used part of the drive which I try to keep small so I can still copy the image to an mSD card if I wish. So I have to supply the amount of the drive to copy. The bs=512 went fast enough, but then I was only copying 3.2GB. thanks for the help. personally, I would use 'dump' for ext? file systems, and xfsdump for XFS. this *just* backs up the inodes and directories, not raw blocks -- john r pierce, recycling bits in santa cruz ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] imaging a drive with dd
On 3/3/2017 5:34 AM, Robert Moskowitz wrote: > Well, I only wanted to copy the used part of the drive which I try to > keep small so I can still copy the image to an mSD card if I wish. So > I have to supply the amount of the drive to copy. The bs=512 went > fast enough, but then I was only copying 3.2GB. > > thanks for the help. Have you considered looking at Clonezilla? It does a nice job of imaging a disk and only saves the used part. It creates an image which can be restored and is bootable. ___ 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] Solved Re: imaging a drive with dd
On 03/02/2017 11:57 PM, Robert Moskowitz wrote: The following worked: # dd if=/dev/sdb of=cubietruck.img bs=512 count=6268927 6268927+0 records in 6268927+0 records out 3209690624 bytes (3.2 GB, 3.0 GiB) copied, 114.435 s, 28.0 MB/s So bs= IS the drive blocksize. This is the result of trying a number of different values for bs and count. You can set bs to a multiple of 512 and it will go a lot faster. If I have to use raw dd for cloning, I will factor the count all the way down to primes, and multiply the blocksize by all of the factors up to the largest prime factor. This is trivially easy on a CentOS system (factor is part of coreutils): [lowen@FREE-IP-92 ~]$ factor 6268927 6268927: 7 43 59 353 So you could use 512 times any of these factors, or several of these factors. I would probably use the line: dd if=/dev/sdb of=cubietruck.img bs=9092608 count=353 Note that while dd can use the abbreviation 'k' you would not want to use that here since 2 is not one of the factors of your count. A roughly 9MB blocksize is going to be loads faster than 512, but still manageable. Or you could make it easy on yourself and use either dd_rescue or ddrescue. When I was working on the ODROID C2 stuff last year I built ddrescue from source RPM early on, before it got built as part of the EPEL aarch64 stuff. Either of these two will figure out the optimum blocksize for you for best performance, and you get progress indications without having to have another terminal open to issue the fun 'kill -USR1 $pid-of-dd' command to get that out of dd. The ddrescue utility for one includes a '--size=' parameter so that you can clone only the portion you want. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] imaging a drive with dd
On 03/03/2017 12:23 PM, John R Pierce wrote: On 3/3/2017 5:34 AM, Robert Moskowitz wrote: Well, I only wanted to copy the used part of the drive which I try to keep small so I can still copy the image to an mSD card if I wish. So I have to supply the amount of the drive to copy. The bs=512 went fast enough, but then I was only copying 3.2GB. thanks for the help. personally, I would use 'dump' for ext? file systems, and xfsdump for XFS. this *just* backs up the inodes and directories, not raw blocks But I have a single image that I can use to build a working drive. Even on another drive, as long as it is more that 3.2GB. Also the partition table and uboot (but on Cubie's uboot, you put the uboot as the ONLY thing on the mSD, and it switches over to the sata for all the partitions). ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] imaging a drive with dd
On 03/03/2017 12:31 PM, Styma, Robert (Nokia - US) wrote: On 3/3/2017 5:34 AM, Robert Moskowitz wrote: Well, I only wanted to copy the used part of the drive which I try to keep small so I can still copy the image to an mSD card if I wish. So I have to supply the amount of the drive to copy. The bs=512 went fast enough, but then I was only copying 3.2GB. thanks for the help. Have you considered looking at Clonezilla? It does a nice job of imaging a disk and only saves the used part. It creates an image which can be restored and is bootable. Yes, I looked at it a couple years ago, and I may well again as a disaster recovery tool. It takes more to set up than a dd of the drive (and xzcat compression for storage). I *DO* want a recovery strategy in place here. thanks ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] imaging a drive with dd
On 03/03/2017 12:31 PM, Styma, Robert (Nokia - US) wrote: On 3/3/2017 5:34 AM, Robert Moskowitz wrote: Well, I only wanted to copy the used part of the drive which I try to keep small so I can still copy the image to an mSD card if I wish. So I have to supply the amount of the drive to copy. The bs=512 went fast enough, but then I was only copying 3.2GB. thanks for the help. Have you considered looking at Clonezilla? It does a nice job of imaging a disk and only saves the used part. It creates an image which can be restored and is bootable. I have a Pogoplug (armv5) running Redsleeve 7 with a 2TB drive to back up to. AFTER I get my new mailserver working. Which probably won't be until either someone builds php-imap for armv7, or I figure out how to get build or mock installed (both of which had failed dependencies) and do it myself. BTW, here is my Cubieboard2 'rack'. I should also put up my CubieTruck... http://medon.htt-consult.com/~rgm/cubieboard/cubietower-3.JPG Medon is the top one in the stack. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] New C7 kernel ABI and kmods
On Fri, Mar 3, 2017 at 9:16 AM, Lamar Owen wrote: > All, > > This is just a heads-up that the new C7 update kernel breaks ABI > compatibility, at least as far as using the ELrepo nVidia drivers is > concerned. I have posted more details to the ELrepo list; but since many > folks use the Elrepo kmods I thought a heads-up would be appropriate. > > If you use the ELrepo nvidia kmod you will either need to hold off on the > kernel update or uninstall the nvidia kmod. This is being tracked here: https://elrepo.org/bugs/view.php?id=720 Akemi ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] A firefox/CentOS 7 oddity
I just switched to a new workstation, running C 7, the other day. I was looking at a blog, and in the thread of cmts, I wanted to play this one youtube video. I listened, then closed the tab. The video that had been *above* it in the thread started playing, and hasn't stopped. Every other time until now that I've done this, closing the tab shuts down the video mark ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] New C7 kernel ABI and kmods
On Fri, Mar 03, 2017 at 12:03:52PM -0800, Akemi Yagi wrote: > On Fri, Mar 3, 2017 at 9:16 AM, Lamar Owen wrote: > > All, > > > > This is just a heads-up that the new C7 update kernel breaks ABI > > compatibility, at least as far as using the ELrepo nVidia drivers is > > concerned. I have posted more details to the ELrepo list; but since many > > folks use the Elrepo kmods I thought a heads-up would be appropriate. > > > > If you use the ELrepo nvidia kmod you will either need to hold off on the > > kernel update or uninstall the nvidia kmod. > > This is being tracked here: > > https://elrepo.org/bugs/view.php?id=720 didn't we just go thru this a few months ago? they're breaking it again? -- Fred Smith -- fre...@fcshome.stoneham.ma.us - The eyes of the Lord are everywhere, keeping watch on the wicked and the good. - Proverbs 15:3 (niv) - ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] C 7.3 sshd will not reload
On Fri, 3 Mar 2017 08:53:43 Tru Huynh wrote: On Thu, Mar 02, 2017 at 11:29:24AM -0500, m...@tdiehl.org wrote: > Hi, > > Since upgrading to 7.3 I am having a problem getting sshd to reload after > configuration changes. When I issue the command "systemctl reload sshd.service" > > I get the following error: "Unit sshd.service cannot be reloaded because it is inactive." upstream see https://bugzilla.redhat.com/show_bug.cgi?id=1381997 openssh-7.4p1-1.el7 should fix it. Well at least I know I an not going crazy. I missed that in my Google search. Thanks Tru. Regards, -- Tom m...@tdiehl.org Spamtrap address me...@tdiehl.org ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Solved Re: imaging a drive with dd
On Mar 3, 2017, at 10:49 AM, Lamar Owen wrote: > > On 03/02/2017 11:57 PM, Robert Moskowitz wrote: >> The following worked: >> >> # dd if=/dev/sdb of=cubietruck.img bs=512 count=6268927 >> >> 6268927+0 records in >> 6268927+0 records out >> 3209690624 bytes (3.2 GB, 3.0 GiB) copied, 114.435 s, 28.0 MB/s >> >> So bs= IS the drive blocksize. >> >> This is the result of trying a number of different values for bs and count. > > You can set bs to a multiple of 512 and it will go a lot faster. Maybe, maybe not. OP said he’s on an embedded system, which often implies low-end eMMC or SD type storage, and 28 MB/sec is typical for such things. When mirroring HDDs and proper SSDs, yes, you want to use large block sizes. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] New C7 kernel ABI and kmods
On Fri, Mar 3, 2017 at 12:03 PM, Akemi Yagi wrote: > On Fri, Mar 3, 2017 at 9:16 AM, Lamar Owen wrote: >> All, >> >> This is just a heads-up that the new C7 update kernel breaks ABI >> compatibility, at least as far as using the ELrepo nVidia drivers is >> concerned. I have posted more details to the ELrepo list; but since many >> folks use the Elrepo kmods I thought a heads-up would be appropriate. >> >> If you use the ELrepo nvidia kmod you will either need to hold off on the >> kernel update or uninstall the nvidia kmod. > > This is being tracked here: > > https://elrepo.org/bugs/view.php?id=720 The kmod-nvidia packages (legacy packages too) against the latest EL7.3 kernel (3.10.0-514.10.2.el7) have been released to the main repository and are syncing to the mirrors. kmod-nvidia-304xx-304.135-2.el7.elrepo.x86_64.rpm kmod-nvidia-340xx-340.102-2.el7.elrepo.x86_64.rpm kmod-nvidia-375.39-2.el7.elrepo.x86_64.rpm These packages will not be compatible with earlier kernel releases. Akemi ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 7 iso file SHA-256 hashes
I downloaded CentOS-7-x86_64-Everything.iso (8,233,418,752 bytes) by clicking on the 'Everything' link in the 'Rolling' line on https://wiki.centos.org/Download (supposedly the 1611 build). But when I look in the sha256sum.txt file from https://buildlogs.centos.org/rolling/7/isos/x86_64/ (where Chrome says that iso came from), there is no SHA hash for a file of that name. The reason I wanted to check it is because it's a different size than another one I found on my hard drive while looking through the Downloads history in Chrome. The other file I found was CentOS-7-x86_64-Everything-1611.iso (8,280,604,672 bytes), which returns a hash of af4969ebbdc479d330de97c5bfbb37eedc64c369f009cb15a97f9553ba441c88 and that matches the value given in the sha256sum.txt file for the file of that name. So, my question is tri-fold. what's the SHA-256 hash supposed to be for the file given when clicking the 'Everything' link on centos.org. then, why is the 'official' download link sending a file that's not listed in the hash results. and finally, why is the file sent thusly, different from another 'everything' iso allegedly from the same build? Thanks. ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
