Also, make sure your BIOS is the latest version for your motherboard!
Jay
>
>>
>> [2.183682] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
>> [2.183825] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
>> [7.183893] ata3.00: qc timeout (cmd 0xec)
>> [7.183908]
On Mon, Jun 24, 2019 at 03:42:24PM +, Chris Olson via CentOS wrote:
> We have a very old Dell desk top machine that has been running
> CentOS 6 for the past five years. It received a new, 1 TB disk
> and additional memory before the OS installation. It has been
> the primary Linux machine in
On Sun, 2019-06-23 at 22:13 -0400, doug schmidt wrote:
> Hi,
> I'm having an issue with my Thinkpad P70 laptop/workstation. This system is
> a dual boot,
> windows 10 pro and centos 7. I have not needed to use the cdrom until now,
> however the system does not see it in /dev. I know the cdrom
On Mon, Jun 24, 2019 at 3:35 AM Pete Biggs wrote:
> On Sun, 2019-06-23 at 22:13 -0400, doug schmidt wrote:
> > Hi,
> > I'm having an issue with my Thinkpad P70 laptop/workstation. This system
> is
> > a dual boot,
> > windows 10 pro and centos 7. I have not needed to use the cdrom until
> now,
>
>
> [root@darkness ~]# ls -al /dev/sr*
> ls: cannot access /dev/sr*: No such file or directory
> [root@darkness ~]# ls /dev/s*
> /dev/sda /dev/sda3 /dev/sdb1 /dev/sg0 /dev/stderr
> /dev/sda1 /dev/sda4 /dev/sdb2 /dev/sg1 /dev/stdin
> /dev/sda2 /dev/sdb /dev/sdb3
On Mon, Jun 24, 2019 at 10:42 AM Chris Olson via CentOS
wrote:
> Advice regarding this issue and any possible diagnostic methods
> will be greatly appreciated.
>
Install smartmontools. You can use the smartctl tool to get all of the
S.M.A.R.T. data for the drive. You can also set up the config
Chris Olson wrote:
> One theory put forward is that some application is running that
> uses up CPU and disk bandwidth.
1. Check the cable. I'm getting convinced that half of all problems
are caused by cables.
2. Use iotop to see what's using the disk.
3. Check the disk using smartmontools
>
> >
> > [root@darkness ~]# ls -al /dev/sr*
> > ls: cannot access /dev/sr*: No such file or directory
> > [root@darkness ~]# ls /dev/s*
> > /dev/sda /dev/sda3 /dev/sdb1 /dev/sg0 /dev/stderr
> > /dev/sda1 /dev/sda4 /dev/sdb2 /dev/sg1 /dev/stdin
> > /dev/sda2 /dev/sdb
Chris Olson via CentOS wrote:
> We have a very old Dell desk top machine that has been running
> CentOS 6 for the past five years. It received a new, 1 TB disk
> and additional memory before the OS installation. It has been the primary
> Linux machine in our smallest and most remote field
>
Peda, Allan (NYC-GIS) wrote:
> I think the subject says it all. We don't run named. It seems there are
> chronic issues with bind. Can these packages be removed?
>
> We locally authenticate. I see this:
>
> Removing for dependencies:
> bind-utils ipa-client sssd sssd-ad sssd-ipa
>
> We
I think the subject says it all. We don't run named. It seems there are
chronic issues with bind. Can these packages be removed?
We locally authenticate. I see this:
Removing for dependencies:
bind-utils
ipa-client
sssd
sssd-ad
sssd-ipa
We shouldn't need any of that with local
All,
I have a user who has a Dell Precision 7520 laptop, and we're running CentOS 7,
latest kernel.
This morning he had two lockup incidents. Nothing in /var/log/messages stands
out so far,
but did get this information when running 'abrt-cli list --since 1560891312':
id
On Mon, Jun 24, 2019 at 9:07 AM Peda, Allan (NYC-GIS)
wrote:
>
> I think the subject says it all. We don't run named. It seems there are
> chronic issues with bind. Can these packages be removed?
>
> We locally authenticate. I see this:
>
> Removing for dependencies:
> bind-utils
>
Virgo, Paul E. \(GSFC-610.2\)\[ADNET SYSTEMS INC\] via CentOS wrote:
> All,
>
>
> I have a user who has a Dell Precision 7520 laptop, and we're running
> CentOS 7, latest kernel.
> This morning he had two lockup incidents. Nothing in /var/log/messages
> stands out so far, but did get this
Had a manager come by, to tell me one server seemed to be running slow,
but nothing much was on it.
Well, it turned out to be a user who was using Visual Studio on his Win10
laptop to edit files on the server. And VS used sftp to get to the files.
Yeah, about that: ssh in about 4 times a
We have a very old Dell desk top machine that has been running
CentOS 6 for the past five years. It received a new, 1 TB disk
and additional memory before the OS installation. It has been
the primary Linux machine in our smallest and most remote field
office. It has been updated at least once a
I just tried out removal of bind-utils on a soon to be retired machine. It
seems fine with the caveat that we lose /bin/host and /bin/dig
Perhaps a perl script might suffice to emulate 'host' on machines that might
need the occasional networking debug session. Just typed this up, so FWIW:
>
> [2.183682] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
> [2.183825] ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
> [7.183893] ata3.00: qc timeout (cmd 0xec)
> [7.183908] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> [7.183960] ata4.00: qc
CentOS Errata and Security Advisory 2019:1587 Important
Upstream details at : https://access.redhat.com/errata/RHSA-2019:1587
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
CentOS Errata and Enhancement Advisory 2019:1344
Upstream details at : https://access.redhat.com/errata/RHEA-2019:1344
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
CentOS Errata and Enhancement Advisory 2019:1342
Upstream details at : https://access.redhat.com/errata/RHEA-2019:1342
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
CentOS Errata and Enhancement Advisory 2019:1343
Upstream details at : https://access.redhat.com/errata/RHEA-2019:1343
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
CentOS Errata and Enhancement Advisory 2019:1341
Upstream details at : https://access.redhat.com/errata/RHEA-2019:1341
The following updated files have been uploaded and are currently
syncing to the mirrors: ( sha256sum Filename )
x86_64:
23 matches
Mail list logo
