> Am 24.01.2018 um 22:22 schrieb Chris Adams :
>
> Once upon a time, Chris Murphy said:
>> "We recommend that OEMs, cloud service providers, system
>> manufacturers, software vendors and end users stop deployment of
>> current versions." Current versions of what? Microcode?
>
> Well, that's th
Why is the line "+auto.master" present in the /etc/auto.master file? Does this not create
a loop, and perhaps is the reason why, on every boot, I see the message, "automount[3260]:
problem reading master map, maximum wait exceeded"?
This is in an unmodified /etc/auto.master from autofs-5.0.5-13
Once upon a time, Chris Murphy said:
> "We recommend that OEMs, cloud service providers, system
> manufacturers, software vendors and end users stop deployment of
> current versions." Current versions of what? Microcode?
Well, that's the only thing Intel provides for CPUs, so that's all it
can b
Leroy Tennison wrote:
> What's amazing to me is, after "Intel Inside - don't divide" (their 486
> debacle), they didn't learn and have a better plan for addressing these
> kinds of things.
>
Or, as some of us back then referred to it, the RePentium chip (think
again...)
mark
> - Original M
> Am 24.01.2018 um 20:37 schrieb Leon Fauster :
>
>
>> Am 24.01.2018 um 19:17 schrieb hw :
>>
>> Hi,
>>
>> what´s the proposed way of handling mdadm in Centos 7? I did not get
>> any notification when a disk in a RAID1 failed, and now that the
>> configuration has changed after resolving the
> Am 24.01.2018 um 19:17 schrieb hw :
>
> Hi,
>
> what´s the proposed way of handling mdadm in Centos 7? I did not get
> any notification when a disk in a RAID1 failed, and now that the
> configuration has changed after resolving the problem, I might be
> supposed to somehow update /etc/mdadm.c
On Wed, January 24, 2018 12:38 pm, Leroy Tennison wrote:
> What's amazing to me is, after "Intel Inside - don't divide" (their 486
> debacle), they didn't learn and have a better plan for addressing these
> kinds of things.
It probably would be fair to conclude that they didn't plan to address
th
What's amazing to me is, after "Intel Inside - don't divide" (their 486
debacle), they didn't learn and have a better plan for addressing these kinds
of things.
- Original Message -
From: "Chris Murphy"
To: "centos"
Sent: Wednesday, January 24, 2018 12:06:01 PM
Subject: Re: [CentOS] /l
Hi,
what´s the proposed way of handling mdadm in Centos 7? I did not get
any notification when a disk in a RAID1 failed, and now that the
configuration has changed after resolving the problem, I might be
supposed to somehow update /etc/mdadm.conf.
Am I not supposed to be notified by default when
On Tue, Jan 23, 2018 at 4:26 AM, Johnny Hughes wrote:
>
> Here are a couple of posts for our reading pleasure:
>
> Intel recommends not installing the microcode now:
> http://intel.ly/2DsL9qz
Except this doesn't mention microcode at all. I can't even tell WTF
they're recommending not doing in th
On 01/23/2018 08:50 PM, Alexander Dalloz wrote:
> Am 23.01.2018 um 20:23 schrieb H:
>> I received a rar-archive, probably created on Win10, that I could not
>> extract with unrar on CentOS 6.
>
> CentOS does not provide unrar. You must have it from a third party repository
> and we don't know whi
Yes
--
Sent from the Delta quadrant using Borg technology!
Nux!
www.nux.ro
- Original Message -
> From: "Morgan Read"
> To: "CentOS mailing list"
> Sent: Tuesday, 23 January, 2018 23:30:57
> Subject: Re: [CentOS] best centos server setup for graphics intensive kvm
> vms?
> Hmm, S
12 matches
Mail list logo
