Thanks, Patrick. It's all good now!
Gilbert
On 2023-09-01 9:18 a.m., Patrick Riehecky wrote:
Sorry for the delay, In theory this was fixed up overnight.
Are you still seeing the issue?
On Thu, 2023-08-31 at 09:20 -0500, Gilbert E. Detillieux wrote:
When I try to run "yum update" now, I get
Sorry for the delay, In theory this was fixed up overnight.
Are you still seeing the issue?
On Thu, 2023-08-31 at 09:20 -0500, Gilbert E. Detillieux wrote:
> When I try to run "yum update" now, I get the following dependency
> errors (below). I suspect some packages unrelated to the kernel
>
When I try to run "yum update" now, I get the following dependency
errors (below). I suspect some packages unrelated to the kernel update
were released from "fastbugs" prematurely, without their dependencies
coming along for the ride...
Gilbert
Resolving Dependencies
-->
Scientific Linux users worldwide
on behalf of Patrick Riehecky
Sent: Wednesday, March 18, 2020 12:30 PM
To: scientific-linux-users
Subject: Re: [SCIENTIFIC-LINUX-USERS] EXT: Security ERRATA Important: kernel on
SL7.x x86_64
Interesting. I didn't see this in the internal repoclosures.
for Scientific Linux users worldwide
on behalf of Peed, Andrew (GE
Healthcare)
Sent: Wednesday, March 18, 2020 10:05 AM
To: scientific-linux-users
Subject: Re: [SCIENTIFIC-LINUX-USERS] EXT: Security ERRATA Important: kernel on
SL7.x x86_64
Hi,
When I update my repository with this kernel package
Message-
From: owner-scientific-linux-err...@listserv.fnal.gov
On Behalf Of Farhan Ahmed
Sent: Tuesday, March 17, 2020 4:43 PM
To: scientific-linux-err...@listserv.fnal.gov
Subject: EXT: Security ERRATA Important: kernel on SL7.x x86_64
Synopsis: Important: kernel security, bug fix
On 03/09/2018 03:00 PM, Stephan Wiesand wrote:
On 09.Mar 2018, at 21:51, Gilles Detillieux
wrote:
I wasn't sure if you could safely mix code compiled with and without the
retpoline extensions into the same kernel, which is why I thought the Makefile
threw an error.
> On 09.Mar 2018, at 21:51, Gilles Detillieux wrote:
>
> I wasn't sure if you could safely mix code compiled with and without the
> retpoline extensions into the same kernel, which is why I thought the
> Makefile threw an error.
Looks like upstream it's just a
I wasn't sure if you could safely mix code compiled with and without the
retpoline extensions into the same kernel, which is why I thought the
Makefile threw an error. But if it's safe to do, I may give this a shot
next week if the gcc update doesn't come as expected, or if for some
reason it
Meanwhile, this change should help:
---8<---
--- /usr/src/kernels/3.10.0-693.21.1.el7.x86_64/arch/x86/Makefile.orig
2018-03-09 10:49:58.902263193 +0100
+++ /usr/src/kernels/3.10.0-693.21.1.el7.x86_64/arch/x86/Makefile
2018-03-09 10:50:51.820305074 +0100
@@ -160,12 +160,12 @@
# Avoid
An updated gcc that supports this option is scheduled for publication on
Tuesday.
Pat
On 03/08/2018 11:46 AM, Gilles Detillieux wrote:
I realize this problem was likely introduced by upsteam updates, but I
thought I'd point it out here anyway so you're aware of it. An
unintended consequence
I realize this problem was likely introduced by upsteam updates, but I
thought I'd point it out here anyway so you're aware of it. An
unintended consequence of this latest kernel update is that it breaks
recompilation of third-party kernel modules. The new kernel was built
with
12 matches
Mail list logo