> Q3) Does this indicate that only the latest CentOS (minor) release can
> be considered "secure" or "patched"?
Yes. Security errata for previous Enterprise Linux minor releases are
a Red Hat product called Extended Update Support (EUS) [0]. CentOS
doesn't build EUS updates. CentOS point
Am 05.08.20 um 17:55 schrieb Johnny Hughes:
On 8/5/20 10:45 AM, cen...@niob.at wrote:
On 05/08/2020 16:49, Johnny Hughes wrote:
On 8/5/20 1:05 AM, cen...@niob.at wrote:
On 04/08/2020 23:50, Jon Pruente wrote:
On Tue, Aug 4, 2020 at 11:34 AM wrote:
Q5) If the answer to the last question is
On 05/08/2020 17:55, Johnny Hughes wrote:
Having said all this: maybe there is some deeper problem here, because
of that pattern of missing announce e-mails that correspond with
packages that differ in the final version number with respect to the
upstream package. Or is this just a
On 8/5/20 10:45 AM, cen...@niob.at wrote:
> On 05/08/2020 16:49, Johnny Hughes wrote:
>> On 8/5/20 1:05 AM, cen...@niob.at wrote:
>>> On 04/08/2020 23:50, Jon Pruente wrote:
On Tue, Aug 4, 2020 at 11:34 AM wrote:
> Q5) If the answer to the last question is "no": shouldn't there be
On 05/08/2020 16:49, Johnny Hughes wrote:
On 8/5/20 1:05 AM, cen...@niob.at wrote:
On 04/08/2020 23:50, Jon Pruente wrote:
On Tue, Aug 4, 2020 at 11:34 AM wrote:
Q5) If the answer to the last question is "no": shouldn't there be such
a resource?
CentOS doesn't publish security errata. If
On 8/5/20 1:05 AM, cen...@niob.at wrote:
> On 04/08/2020 23:50, Jon Pruente wrote:
>> On Tue, Aug 4, 2020 at 11:34 AM wrote:
>>
>>> Q5) If the answer to the last question is "no": shouldn't there be such
>>> a resource?
>>>
>> CentOS doesn't publish security errata. If you need it then you should
On 8/4/20 10:45 AM, ja wrote:
> On Tue, 2020-08-04 at 10:36 -0500, Chris Adams wrote:
>> Once upon a time, Johnny Hughes said:
>>> The issues should now be resolved.
>>>
>>> If you just mount /mnt/sysimage, set an ip address and upgrade (to get
>>> th new shim) .. then:
>>>
>>> yum reinstall
>>
Am 05.08.20 um 13:44 schrieb Leon Fauster via CentOS:
> Take a look into "top",
> if something like gz or xz is in place occupying your CPU then the
> initrd gets build ... just wait :-)
'journalctl -f' shows the state of the build process.
___
CentOS
Am 05.08.20 um 02:13 schrieb david:
At 05:01 PM 8/4/2020, you wrote:
Am 05.08.20 um 01:27 schrieb david:
At 04:18 PM 8/4/2020, you wrote:
Am 05.08.20 um 01:09 schrieb david:
At 01:54 PM 8/4/2020, you wrote:
On Tue, 04 Aug 2020 13:44:05 -0700
david wrote:
> After all the updates, the system
Am 05.08.20 um 06:22 schrieb hexp...@hexpeek.com:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Announcing the version 1.0 hexpeek release!
I am pleased to announce the first stable release of hexpeek, which
seeks to be an efficient, powerful, and portable hex editor for files
of all kinds
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.
On 8/4/2020 11:20 AM, Jonathan Billings wrote:
Running transaction
Installing : kernel-3.10.0-1127.el7.x86_64 1/1
at which point the process appeared to hang. No further output happened for
five minutes. I opened a different terminal and entered "shutdown -r now".
The result is an
On 04/08/2020 23:50, Jon Pruente wrote:
On Tue, Aug 4, 2020 at 11:34 AM wrote:
Q5) If the answer to the last question is "no": shouldn't there be such
a resource?
CentOS doesn't publish security errata. If you need it then you should
either buy RHEL, or deal with putting together your own
13 matches
Mail list logo
