Re: numfmt issue on SL 7.9; possible bug?
A question: Are there applications that use the affected glibc version and were used for mission-critical (or possibly life endangering) calculations? If so, all of the results of such calculations (including any done at Fermilab, CERN, or HEP for data analysis, detector calibration and modeling, etc.) are suspect. Are these users even deeply aware of the issue and the need to redo work? On 2/11/21 6:34 AM, ~Stack~ wrote: On 2/11/21 2:25 AM, Akemi Yagi wrote: On Wed, Feb 10, 2021 at 11:59 PM Dietrich, Stefan wrote: Hi, you might be running into this issue: bugzilla.redhat.com/show_bug.cgi?id=1925204 This has been introduced with glibc-2.17-322.el7_9 and has been fixed in glibc-2.17-323.el7_9. CentOS 7 already ships the updated version, on SL7 the version seems to be not yet available. Regards, Stefan Looks like the glibc-2.17-323.el7_9 update (RHBA-2021:0439) is not a security fix. SL usually publishes non-security updates on Tuesdays. Unless the devs decide to make it an exception, the update will be out on next Tue, Feb 16. Akemi Awesome! Thank you both. I think you are absolutely onto something. This also may explain why I can't get it to work reliably on my upstream vendor OS. Even though they are all the same coreutils version, I've got different versions of glibc running on them (we have a rolling update cycle for certain environments to help catch upgrade errors). Some are older and some are newer. The one having the problem is the same version. I didn't even think to check glibc. I will wait till next Tuesday. Thank you!
Re: numfmt issue on SL 7.9; possible bug?
On 2/11/21 2:25 AM, Akemi Yagi wrote: On Wed, Feb 10, 2021 at 11:59 PM Dietrich, Stefan wrote: Hi, you might be running into this issue: bugzilla.redhat.com/show_bug.cgi?id=1925204 This has been introduced with glibc-2.17-322.el7_9 and has been fixed in glibc-2.17-323.el7_9. CentOS 7 already ships the updated version, on SL7 the version seems to be not yet available. Regards, Stefan Looks like the glibc-2.17-323.el7_9 update (RHBA-2021:0439) is not a security fix. SL usually publishes non-security updates on Tuesdays. Unless the devs decide to make it an exception, the update will be out on next Tue, Feb 16. Akemi Awesome! Thank you both. I think you are absolutely onto something. This also may explain why I can't get it to work reliably on my upstream vendor OS. Even though they are all the same coreutils version, I've got different versions of glibc running on them (we have a rolling update cycle for certain environments to help catch upgrade errors). Some are older and some are newer. The one having the problem is the same version. I didn't even think to check glibc. I will wait till next Tuesday. Thank you!
Re: numfmt issue on SL 7.9; possible bug?
Can you supply the command you are typing to use the numfmt? Steve From: owner-scientific-linux-us...@listserv.fnal.gov on behalf of Ching Him Leung Sent: Wednesday, February 10, 2021 11:10 PM To: scientific-linux-users Subject: Re: numfmt issue on SL 7.9; possible bug? I get "nan" on one SL7.9 computer but a "0" on another. Not sure what causes the difference.
Re: numfmt issue on SL 7.9; possible bug?
On Wed, Feb 10, 2021 at 11:59 PM Dietrich, Stefan wrote: > > Hi, > > you might be running into this issue: > bugzilla.redhat.com/show_bug.cgi?id=1925204 > > This has been introduced with glibc-2.17-322.el7_9 and has been fixed in > glibc-2.17-323.el7_9. > CentOS 7 already ships the updated version, on SL7 the version seems to be > not yet available. > > Regards, > Stefan Looks like the glibc-2.17-323.el7_9 update (RHBA-2021:0439) is not a security fix. SL usually publishes non-security updates on Tuesdays. Unless the devs decide to make it an exception, the update will be out on next Tue, Feb 16. Akemi
Re: numfmt issue on SL 7.9; possible bug?
Hi, you might be running into this issue: https://urldefense.proofpoint.com/v2/url?u=https-3A__bugzilla.redhat.com_show-5Fbug.cgi-3Fid-3D1925204=DwICaQ=gRgGjJ3BkIsb5y6s49QqsA=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A=ts7ZLN5_srcF3E4faT54Sy7e6mS9J6_NLmE5JzpQZNY=QJunYmR2QqlKhqaFW90rNCvLZU3fnyDph0Dr_ISa-H0= This has been introduced with glibc-2.17-322.el7_9 and has been fixed in glibc-2.17-323.el7_9. CentOS 7 already ships the updated version, on SL7 the version seems to be not yet available. Regards, Stefan - Original Message - > From: "~Stack~" > To: scientific-linux-us...@listserv.fnal.gov > Sent: Thursday, February 11, 2021 1:17:26 AM > Subject: numfmt issue on SL 7.9; possible bug? > Greetings, > > Curious if anyone else can replicate this. I initially saw this in a > certain upstream vendor 7.9, but I'm having issues replicating it and > it's only in a certain environment (virtual and I've done strange and > awful things to that as I've been trying to understand an unrelated > project). However, I was trying to figure out if it was other places as > well. Sure enough, I can replicate it on every single one of my SL 7.9 > instances that I've tested. > > The short, numfmt should not return 'nan' when passed a zero. > > $ echo 0 | numfmt > nan > $ rpm -q coreutils > coreutils-8.22-24.el7_9.2.x86_64 > > If I try on any other distro (Ubuntu/Debian/CentOS 8), it returns 0 as > it should. > > $ echo 0 | numfmt > 0 > $ rpm -q coreutils > coreutils-8.30-8.el8.x86_64 > > I may not be able to replicate it as reliably as I would prefer on > upstream vendor, but every single SL 7.9 system I've tried has had > coreutils-8.22-24.el7_9.2.x86_64 and incorrectly returns 'nan'. > > I'm hoping the devs can confirm and/or offer suggestions. > > Thanks! > ~Stack~
Re: numfmt issue on SL 7.9; possible bug?
I get "nan" on one SL7.9 computer but a "0" on another. Not sure what causes the difference.
Re: numfmt issue on SL 7.9; possible bug?
I get the same 'nan' on three SL 7.9 computers, but it works ok on a CentOS 7.9 machine. Here is an excerpt from 'rpm -qi coreutils' on CentOS 7.9: Source RPM : coreutils-8.22-24.el7_9.2.src.rpm Build Date : Mon 16 Nov 2020 02:24:59 PM PST Build Host : x86-01.bsys.centos.org and here is the same from SL 7.9: Source RPM : coreutils-8.22-24.el7_9.2.src.rpm Build Date : Tue 10 Nov 2020 09:07:17 AM PST Build Host : sl7.fnal.gov Steven Yellin On Wed, 10 Feb 2021, ~Stack~ wrote: Greetings, Curious if anyone else can replicate this. I initially saw this in a certain upstream vendor 7.9, but I'm having issues replicating it and it's only in a certain environment (virtual and I've done strange and awful things to that as I've been trying to understand an unrelated project). However, I was trying to figure out if it was other places as well. Sure enough, I can replicate it on every single one of my SL 7.9 instances that I've tested. The short, numfmt should not return 'nan' when passed a zero. $ echo 0 | numfmt nan $ rpm -q coreutils coreutils-8.22-24.el7_9.2.x86_64 If I try on any other distro (Ubuntu/Debian/CentOS 8), it returns 0 as it should. $ echo 0 | numfmt 0 $ rpm -q coreutils coreutils-8.30-8.el8.x86_64 I may not be able to replicate it as reliably as I would prefer on upstream vendor, but every single SL 7.9 system I've tried has had coreutils-8.22-24.el7_9.2.x86_64 and incorrectly returns 'nan'. I'm hoping the devs can confirm and/or offer suggestions. Thanks! ~Stack~
Re: numfmt issue on SL 7.9; possible bug?
Greetings, Thanks for checking. That seems to fit that every other distro is fine. But I've now check a dozen different systems on SL 7.9 and all show it. Thanks! ~Stack~ On 2/10/21 7:37 PM, Konstantin Olchanski wrote: here goes, all on physical machines. sl6, macos: no numfmt, sorry ubuntu lts 20.04, centos-7, rhel-8 (ahem!): $ echo 0 | numfmt 0 perhaps your 80387 chip is faulty. (happened to us once on an R3000/R3010 SGI workstation) K.O. On Wed, Feb 10, 2021 at 06:17:26PM -0600, ~Stack~ wrote: Greetings, Curious if anyone else can replicate this. I initially saw this in a certain upstream vendor 7.9, but I'm having issues replicating it and it's only in a certain environment (virtual and I've done strange and awful things to that as I've been trying to understand an unrelated project). However, I was trying to figure out if it was other places as well. Sure enough, I can replicate it on every single one of my SL 7.9 instances that I've tested. The short, numfmt should not return 'nan' when passed a zero. $ echo 0 | numfmt nan $ rpm -q coreutils coreutils-8.22-24.el7_9.2.x86_64 If I try on any other distro (Ubuntu/Debian/CentOS 8), it returns 0 as it should. $ echo 0 | numfmt 0 $ rpm -q coreutils coreutils-8.30-8.el8.x86_64 I may not be able to replicate it as reliably as I would prefer on upstream vendor, but every single SL 7.9 system I've tried has had coreutils-8.22-24.el7_9.2.x86_64 and incorrectly returns 'nan'. I'm hoping the devs can confirm and/or offer suggestions. Thanks! ~Stack~
Re: numfmt issue on SL 7.9; possible bug?
here goes, all on physical machines. sl6, macos: no numfmt, sorry ubuntu lts 20.04, centos-7, rhel-8 (ahem!): $ echo 0 | numfmt 0 perhaps your 80387 chip is faulty. (happened to us once on an R3000/R3010 SGI workstation) K.O. On Wed, Feb 10, 2021 at 06:17:26PM -0600, ~Stack~ wrote: > Greetings, > > Curious if anyone else can replicate this. I initially saw this in a > certain upstream vendor 7.9, but I'm having issues replicating it > and it's only in a certain environment (virtual and I've done > strange and awful things to that as I've been trying to understand > an unrelated project). However, I was trying to figure out if it was > other places as well. Sure enough, I can replicate it on every > single one of my SL 7.9 instances that I've tested. > > The short, numfmt should not return 'nan' when passed a zero. > > $ echo 0 | numfmt > nan > $ rpm -q coreutils > coreutils-8.22-24.el7_9.2.x86_64 > > If I try on any other distro (Ubuntu/Debian/CentOS 8), it returns 0 > as it should. > > $ echo 0 | numfmt > 0 > $ rpm -q coreutils > coreutils-8.30-8.el8.x86_64 > > I may not be able to replicate it as reliably as I would prefer on > upstream vendor, but every single SL 7.9 system I've tried has had > coreutils-8.22-24.el7_9.2.x86_64 and incorrectly returns 'nan'. > > I'm hoping the devs can confirm and/or offer suggestions. > > Thanks! > ~Stack~ -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
