date:20171214

Re: [CentOS] Question on CentoS 7.4 on nvidia

2017-12-14 Thread Phil Perry


On 15/12/17 00:21, Jerry Geis wrote:

So I removed the nvidia items and reinstalled.

In /var/log/messages I saw dracut commands for every kernel EXCEPT the
4.14.5 elrepo kernel.
So I did it manually and I get an error.

/usr/bin/dracut --add-drivers nvidia -f
/boot/initramfs-4.14.5-1.el7.elrepo.x86_64.img 4.14.5-1.el7.elrepo.x86_64
Failed to install module nvidia

No sure what to do.

Jerry


The elrepo kmod packages ONLY support the distro RHEL/CentOS kernels. 
They are NOT compatible with any other non-KABI compatible kernels, 
including the mainline and LTS kernel packages from elrepo.


Hope that helps.

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accessing crashed disk

2017-12-14 Thread Marcin Trendota

W dniu 14.12.2017 o 23:06, Nizar Armansyah pisze:
> If the data is important to you, don't mess around and contact a
> reputable professional data recovery expert or company.

If the data is important to you, you will get it back from your backups,
won't you?

-- 
Over And Out
MoonWolf
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Traffic shaping on CentOS

2017-12-14 Thread Kenneth Porter

I came across this on the Fedora devel list. I added 
/etc/sysctl.d/51-bufferbloat.conf containing the suggested line and it 
installs the new codel qdisc as desired. There's probably more knobs that 
might be useful to tweak but this makes a good start. More reading on the 
bufferbloat site suggests that the later "cake" module will be even better, 
but it requires a newer kernel than CentOS currently ships with.




# 51-bufferbloat.conf
# Address bufferbloat
net.core.default_qdisc = fq_codel

___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

[CentOS] Traffic shaping on CentOS

2017-12-14 Thread Kenneth Porter

I'm deploying a CentOS 7 box as a gateway and I'm trying to figure out how 
to set up traffic shaping. Historically I've used the Wondershaper script 
but apparently it's not deprecated in favor of superior queue management. I 
haven't yet found a packaged solution and I'm wondering what others do to 
configure this kind of thing.


Apparently the new modules are available in many appliance router products 
(eg. OpenWrt and Streamboost). Perhaps someone here knows of an RPM that 
wraps this up for RH-based distros?




Here's an article arguing why Wondershaper was great in its day but is now 
bad for modern traffic flows.



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question on CentoS 7.4 on nvidia

2017-12-14 Thread Jerry Geis

It seems as though 4.14.5 elrepo kernel does not generate any initramfs. It
seems nvidia needs to be apart of that.
Is that correct ?
If so how do I tell it to actually generate the initramfs

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question on CentoS 7.4 on nvidia

2017-12-14 Thread Jerry Geis

So I removed the nvidia items and reinstalled.

In /var/log/messages I saw dracut commands for every kernel EXCEPT the
4.14.5 elrepo kernel.
So I did it manually and I get an error.

/usr/bin/dracut --add-drivers nvidia -f
/boot/initramfs-4.14.5-1.el7.elrepo.x86_64.img 4.14.5-1.el7.elrepo.x86_64
Failed to install module nvidia

No sure what to do.

Jerry
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set triggers domU kernel WARNING, then domU becomes unresponsive

2017-12-14 Thread Adi Pircalabu


On 15-12-2017 9:01, Adi Pircalabu wrote:

On 15-12-2017 4:10, Akemi Yagi wrote:

On Mon, Dec 11, 2017 at 4:52 PM, Adi Pircalabu 
wrote:


Has anyone seen this recently? I couldn't replicate it on:
- CentOS 6 running kernel-2.6.32-696.16.1.el6.x86_64,
kernel-lt-4.4.105-1.el6.elrepo.x86_64
- CentOS 7 running 4.9.67-1.el7.centos.x86_64

But I can replicate it consistently running "xl -v vcpu-set 
" on:
- CentOS 6 running 4.14.5-1.el6.elrepo.x86_64
- CentOS 7 running 4.14.5-1.el7.elrepo.x86_64

dom0 versions tested with similar results in the domU:
- 4.6.6-6.el7 on kernel 4.9.63-29.el7.x86_64
- 4.6.3-15.el6 on kernel 4.9.37-29.el6.x86_64

Noticed behaviour:
- These commands stall:
top
ls -l /var/tmp
ls -l /tmp
- Stuck in D state on the CentOS 7 domU:
root 5  0.0  0.0  0 0 ?D11:20   0:00
[kworker/u8:0]
root   316  0.0  0.0  0 0 ?D11:20   0:00
[jbd2/xvda1-8]
root  1145  0.0  0.2 116636  4776 ?Ds   11:20   0:00
-bash
root  1289  0.0  0.1  25852  2420 ?Ds   11:35   0:00
/usr/bin/systemd-tmpfiles --clean
root  1290  0.0  0.1 125248  2696 pts/1D+   11:44   0:00 ls
--color=auto -l /tmp/
root  1293  0.0  0.1 125248  2568 pts/2D+   11:44   0:00 ls
--color=auto -l /var/tmp
root  1296  0.0  0.2 116636  4908 pts/3Ds+  11:44   0:00
-bash
root  1358  0.0  0.1 125248  2612 pts/4D+   11:47   0:00 ls
--color=auto -l /var/tmp

At a first glance it appears the issue is in 4.14.5 kernel. Stack
traces follow:

Adi Pircalabu


Can you test-install 4.15-rcX
 to see if the problem persists in the latest kernel?:

http://elrepo.org/people/ajb/devel/kernel-ml/el7/x86_64/RPMS/ [1]

Akemi


Thanks for that, tested it on both CentOS 6 and 7 PV domU and I get
similar panics:

-CentOS 6-
[...]
dracut: Switching root
Welcome to CentOS
Starting udev: udev: starting version 147
input: PC Speaker as /devices/platform/pcspkr/input/input0
xen_netfront: Initialising Xen virtual ethernet driver
BUG: unable to handle kernel NULL pointer dereference at 
0010

IP: coretemp_cpu_online+0x116/0x190 [coretemp]
PGD 7b5c7067 P4D 7b5c7067 PUD 7b5cd067 PMD 0
Oops: 0002 [#1] SMP
Modules linked in: coretemp(+) hwmon xen_netfront pcspkr ext4 jbd2
mbcache xen_blkfront dm_mirror dm_region_hash dm_log dm_mod dax
CPU: 0 PID: 12 Comm: cpuhp/0 Not tainted 4.15.0-0.rc1.el6.elrepo.x86_64 
#1

task: 88007c8f43c0 task.stack: c9004039
RIP: e030:coretemp_cpu_online+0x116/0x190 [coretemp]
RSP: e02b:c90040393cd8 EFLAGS: 00010246
RAX: 0010 RBX:  RCX: 88007c87c248
RDX:  RSI: 880077720c28 RDI: 8800069ea020
RBP: c90040393d18 R08:  R09: c90040393a08
R10:  R11: 005f R12: 
R13: 8800069ea000 R14: 88007f60a040 R15: 
FS:  7f685ca0a700() GS:88007f60() 
knlGS:

CS:  e033 DS:  ES:  CR0: 80050033
CR2: 0010 CR3: 0683a000 CR4: 00042660
Call Trace:
 ? coretemp_add_core+0x50/0x50 [coretemp]
 cpuhp_invoke_callback+0xe9/0x700
 ? put_prev_task_fair+0x26/0x40
 ? __schedule+0x2d0/0x6e0
 ? __wake_up_common+0x84/0x130
 ? __wake_up_common+0x84/0x130
 cpuhp_thread_fun+0xee/0x170
 smpboot_thread_fn+0x10c/0x160
 ? smpboot_create_threads+0x80/0x80
 kthread+0x10a/0x140
 ? kthread_probe_data+0x40/0x40
 ret_from_fork+0x1f/0x30
Code: 11 15 41 e1 49 89 c5 b8 f4 ff ff ff 4d 85 ed 0f 84 66 ff ff ff
4c 89 ef e8 88 11 41 e1 85 c0 75 6e 48 8b 05 75 17 00 00 4d 63 ff <4e>
89 2c f8 49 81 fd 00 f0 ff ff 44 89 e8 0f 87 3c ff ff ff 49
RIP: coretemp_cpu_online+0x116/0x190 [coretemp] RSP: c90040393cd8
CR2: 0010
---[ end trace 8253bafacf228cf2 ]---
-CentOS 6-
-CentOS 7-
[...]
[  OK  ] Found device /dev/xvda2.
 Activating swap /dev/xvda2...
[4.998940] alg: No test for pcbc(aes) (pcbc-aes-aesni)
[5.001054] Adding 1048572k swap on /dev/xvda2.  Priority:-2
extents:1 across:1048572k SSFS
[  OK  ] Activated swap /dev/xvda2.
[  OK  ] Reached target Swap.
[5.020760] BUG: unable to handle kernel NULL pointer dereference
at 0010
[5.020767] IP: coretemp_cpu_online+0xf8/0x1f7 [coretemp]
[5.020769] PGD 0 P4D 0
[5.020771] Oops: 0002 [#1] SMP
[5.020773] Modules linked in: coretemp(+) crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd
glue_helper cryptd pcspkr intel_rapl_perf nfsd auth_rpcgss nfs_acl
lockd grace sunrpc ip_tables ext4 mbcache jbd2 xen_netfront
xen_blkfront crc32c_intel
[5.020786] CPU: 0 PID: 12 Comm: cpuhp/0 Not tainted
4.15.0-0.rc3.el7.elrepo.x86_64 #1
[5.020789] RIP: e030:coretemp_cpu_online+0xf8/0x1f7 [coretemp]
[5.020790] RSP: e02b:c90040387e10 EFLAGS: 00010246
[5.020793] RAX: 0010 RBX: 8800040d8800 RCX: 

[5.020794] RDX: 880079761e70 RSI:

Re: [CentOS] Accessing crashed disk

2017-12-14 Thread Nizar Armansyah

If the data is important to you, don't mess around and contact a
reputable professional data recovery expert or company.

If losing your data is a viable option, try to do it yourself.
Otherwise seek professional help, with the data recovery effort of
course.

On Fri, Dec 15, 2017 at 4:31 AM, J Martin Rushton
 wrote:
> On 14/12/17 18:57, Warren Young wrote:
>> On Dec 13, 2017, at 5:15 PM, J Martin Rushton 
>>  wrote:
>>>
>>> # dd if=/dev/sdc of=/home/dd-copy-of-sdc
>>
>> Better, use ddrescue:
>>
>>https://www.gnu.org/software/ddrescue/
>>
>> dd will do unfortunate things like quit early on I/O errors, even if later 
>> blocks would read just fine.  ddrescue assumes the input file is dodgy and 
>> tries to cope.
>>
> Looks interesting.  I've only used dd in anger, and then only maybe 3 or
> 4 times over the last 20 years.  It's worth pointing out that ddrescue
> is not in the main distro, you'll need to get it from EPEL.
>
> Whatever method you use though: "Be diligent because every time a
> physically damaged drive powers up and is able to output some data, it
> may be the very last time that it ever will." (ddrescue manual section 9)
>
>
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
>
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question on CentoS 7.4 on nvidia

2017-12-14 Thread Alice Wonder


That's what I get too -

01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 
405] (rev a2)


It works fine for me with mate with this:

kernel-3.10.0-693.5.2.el7.x86_64
kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64

I've had problems with gnome 3 and nvidia before, but haven't tested in 
a very long time, been running mate for years.


On 12/14/2017 01:51 PM, Jerry Geis wrote:

I installed the elrepo kmod-nvidia and also the nvidia-detect and modules
(see below).

I had X working with the 3.10 from Centos  - but video was freezing. SO I
thought I would try the elrepo kernel. I installed that and X does not come
up?

How do I re-make the nvidia module for 4.14.5 kernel? I want to make sure
the kmod kernel did it.   I 'm thinking it did not.

lspci | grep VGA says GT218

Or  what do I look at now to see why X is not coming up?

Thanks,

Jerry

uname -r
4.14.5-1.el7.elrepo.x86_64


grep EE /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   136.998] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module.
Please see the
[   136.998] (EE) NVIDIA: system's kernel log for additional error
messages and
[   136.998] (EE) NVIDIA: consult the NVIDIA README for details.
[   136.998] (EE) No devices detected.
[   136.998] (EE)
[   136.998] (EE) no screens found(EE)
[   136.998] (EE)
[   136.998] (EE) Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[   136.998] (EE)
[   137.004] (EE) Server terminated with error (1). Closing log file.

uname -a

rpm -qa | grep kernel
kernel-3.10.0-693.el7.x86_64
kernel-tools-3.10.0-693.5.2.el7.x86_64
abrt-addon-kerneloops-2.1.11-48.el7.centos.x86_64
kernel-headers-3.10.0-693.5.2.el7.x86_64
kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
kernel-devel-3.10.0-693.el7.x86_64
kernel-3.10.0-693.5.2.el7.x86_64
kernel-ml-4.14.5-1.el7.elrepo.x86_64
kernel-tools-libs-3.10.0-693.5.2.el7.x86_64
kernel-devel-3.10.0-693.5.2.el7.x86_64
[root@mediaport14 ~]# rpm -qa | grep kernel-ml
kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
kernel-ml-4.14.5-1.el7.elrepo.x86_64


# rpm -qa | grep nvidia
kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64
nvidia-detect-384.90-1.el7.elrepo.x86_64
yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch
nvidia-x11-drv-340xx-340.102-1.el7.elrepo.x86_64
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos



___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question on CentoS 7.4 on nvidia

2017-12-14 Thread Christian, Mark

Find the akmod-nvidia package.  Last I bothered with this some years ago, the
akmod package was required to ensure the nvidia module would be rebuilt every
time a new kernel was booted into.

Mark
On Thu, 2017-12-14 at 16:51 -0500, Jerry Geis wrote:
> I installed the elrepo kmod-nvidia and also the nvidia-detect and modules
> (see below).
> 
> I had X working with the 3.10 from Centos  - but video was freezing. SO I
> thought I would try the elrepo kernel. I installed that and X does not come
> up?
> 
> How do I re-make the nvidia module for 4.14.5 kernel? I want to make sure
> the kmod kernel did it.   I 'm thinking it did not.
> 
> lspci | grep VGA says GT218
> 
> Or  what do I look at now to see why X is not coming up?
> 
> Thanks,
> 
> Jerry
> 
> uname -r
> 4.14.5-1.el7.elrepo.x86_64
> 
> 
> grep EE /var/log/Xorg.0.log
> (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
> [   136.998] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module.
> Please see the
> [   136.998] (EE) NVIDIA: system's kernel log for additional error
> messages and
> [   136.998] (EE) NVIDIA: consult the NVIDIA README for details.
> [   136.998] (EE) No devices detected.
> [   136.998] (EE)
> [   136.998] (EE) no screens found(EE)
> [   136.998] (EE)
> [   136.998] (EE) Please also check the log file at "/var/log/Xorg.0.log"
> for additional information.
> [   136.998] (EE)
> [   137.004] (EE) Server terminated with error (1). Closing log file.
> 
> uname -a
> 
> rpm -qa | grep kernel
> kernel-3.10.0-693.el7.x86_64
> kernel-tools-3.10.0-693.5.2.el7.x86_64
> abrt-addon-kerneloops-2.1.11-48.el7.centos.x86_64
> kernel-headers-3.10.0-693.5.2.el7.x86_64
> kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
> kernel-devel-3.10.0-693.el7.x86_64
> kernel-3.10.0-693.5.2.el7.x86_64
> kernel-ml-4.14.5-1.el7.elrepo.x86_64
> kernel-tools-libs-3.10.0-693.5.2.el7.x86_64
> kernel-devel-3.10.0-693.5.2.el7.x86_64
> [root@mediaport14 ~]# rpm -qa | grep kernel-ml
> kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
> kernel-ml-4.14.5-1.el7.elrepo.x86_64
> 
> 
> # rpm -qa | grep nvidia
> kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64
> nvidia-detect-384.90-1.el7.elrepo.x86_64
> yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch
> nvidia-x11-drv-340xx-340.102-1.el7.elrepo.x86_64
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set triggers domU kernel WARNING, then domU becomes unresponsive

2017-12-14 Thread Adi Pircalabu


On 15-12-2017 4:10, Akemi Yagi wrote:

On Mon, Dec 11, 2017 at 4:52 PM, Adi Pircalabu 
wrote:


Has anyone seen this recently? I couldn't replicate it on:
- CentOS 6 running kernel-2.6.32-696.16.1.el6.x86_64,
kernel-lt-4.4.105-1.el6.elrepo.x86_64
- CentOS 7 running 4.9.67-1.el7.centos.x86_64

But I can replicate it consistently running "xl -v vcpu-set 
" on:
- CentOS 6 running 4.14.5-1.el6.elrepo.x86_64
- CentOS 7 running 4.14.5-1.el7.elrepo.x86_64

dom0 versions tested with similar results in the domU:
- 4.6.6-6.el7 on kernel 4.9.63-29.el7.x86_64
- 4.6.3-15.el6 on kernel 4.9.37-29.el6.x86_64

Noticed behaviour:
- These commands stall:
top
ls -l /var/tmp
ls -l /tmp
- Stuck in D state on the CentOS 7 domU:
root 5  0.0  0.0  0 0 ?D11:20   0:00
[kworker/u8:0]
root   316  0.0  0.0  0 0 ?D11:20   0:00
[jbd2/xvda1-8]
root  1145  0.0  0.2 116636  4776 ?Ds   11:20   0:00
-bash
root  1289  0.0  0.1  25852  2420 ?Ds   11:35   0:00
/usr/bin/systemd-tmpfiles --clean
root  1290  0.0  0.1 125248  2696 pts/1D+   11:44   0:00 ls
--color=auto -l /tmp/
root  1293  0.0  0.1 125248  2568 pts/2D+   11:44   0:00 ls
--color=auto -l /var/tmp
root  1296  0.0  0.2 116636  4908 pts/3Ds+  11:44   0:00
-bash
root  1358  0.0  0.1 125248  2612 pts/4D+   11:47   0:00 ls
--color=auto -l /var/tmp

At a first glance it appears the issue is in 4.14.5 kernel. Stack
traces follow:

Adi Pircalabu


Can you test-install 4.15-rcX
 to see if the problem persists in the latest kernel?:

http://elrepo.org/people/ajb/devel/kernel-ml/el7/x86_64/RPMS/ [1]

Akemi


Thanks for that, tested it on both CentOS 6 and 7 PV domU and I get 
similar panics:


-CentOS 6-
[...]
dracut: Switching root
Welcome to CentOS
Starting udev: udev: starting version 147
input: PC Speaker as /devices/platform/pcspkr/input/input0
xen_netfront: Initialising Xen virtual ethernet driver
BUG: unable to handle kernel NULL pointer dereference at 
0010

IP: coretemp_cpu_online+0x116/0x190 [coretemp]
PGD 7b5c7067 P4D 7b5c7067 PUD 7b5cd067 PMD 0
Oops: 0002 [#1] SMP
Modules linked in: coretemp(+) hwmon xen_netfront pcspkr ext4 jbd2 
mbcache xen_blkfront dm_mirror dm_region_hash dm_log dm_mod dax
CPU: 0 PID: 12 Comm: cpuhp/0 Not tainted 4.15.0-0.rc1.el6.elrepo.x86_64 
#1

task: 88007c8f43c0 task.stack: c9004039
RIP: e030:coretemp_cpu_online+0x116/0x190 [coretemp]
RSP: e02b:c90040393cd8 EFLAGS: 00010246
RAX: 0010 RBX:  RCX: 88007c87c248
RDX:  RSI: 880077720c28 RDI: 8800069ea020
RBP: c90040393d18 R08:  R09: c90040393a08
R10:  R11: 005f R12: 
R13: 8800069ea000 R14: 88007f60a040 R15: 
FS:  7f685ca0a700() GS:88007f60() 
knlGS:

CS:  e033 DS:  ES:  CR0: 80050033
CR2: 0010 CR3: 0683a000 CR4: 00042660
Call Trace:
 ? coretemp_add_core+0x50/0x50 [coretemp]
 cpuhp_invoke_callback+0xe9/0x700
 ? put_prev_task_fair+0x26/0x40
 ? __schedule+0x2d0/0x6e0
 ? __wake_up_common+0x84/0x130
 ? __wake_up_common+0x84/0x130
 cpuhp_thread_fun+0xee/0x170
 smpboot_thread_fn+0x10c/0x160
 ? smpboot_create_threads+0x80/0x80
 kthread+0x10a/0x140
 ? kthread_probe_data+0x40/0x40
 ret_from_fork+0x1f/0x30
Code: 11 15 41 e1 49 89 c5 b8 f4 ff ff ff 4d 85 ed 0f 84 66 ff ff ff 4c 
89 ef e8 88 11 41 e1 85 c0 75 6e 48 8b 05 75 17 00 00 4d 63 ff <4e> 89 
2c f8 49 81 fd 00 f0 ff ff 44 89 e8 0f 87 3c ff ff ff 49

RIP: coretemp_cpu_online+0x116/0x190 [coretemp] RSP: c90040393cd8
CR2: 0010
---[ end trace 8253bafacf228cf2 ]---
-CentOS 6-
-CentOS 7-
[...]
[  OK  ] Found device /dev/xvda2.
 Activating swap /dev/xvda2...
[4.998940] alg: No test for pcbc(aes) (pcbc-aes-aesni)
[5.001054] Adding 1048572k swap on /dev/xvda2.  Priority:-2 
extents:1 across:1048572k SSFS

[  OK  ] Activated swap /dev/xvda2.
[  OK  ] Reached target Swap.
[5.020760] BUG: unable to handle kernel NULL pointer dereference at 
0010

[5.020767] IP: coretemp_cpu_online+0xf8/0x1f7 [coretemp]
[5.020769] PGD 0 P4D 0
[5.020771] Oops: 0002 [#1] SMP
[5.020773] Modules linked in: coretemp(+) crct10dif_pclmul 
crc32_pclmul ghash_clmulni_intel pcbc aesni_intel crypto_simd 
glue_helper cryptd pcspkr intel_rapl_perf nfsd auth_rpcgss nfs_acl lockd 
grace sunrpc ip_tables ext4 mbcache jbd2 xen_netfront xen_blkfront 
crc32c_intel
[5.020786] CPU: 0 PID: 12 Comm: cpuhp/0 Not tainted 
4.15.0-0.rc3.el7.elrepo.x86_64 #1

[5.020789] RIP: e030:coretemp_cpu_online+0xf8/0x1f7 [coretemp]
[5.020790] RSP: e02b:c90040387e10 EFLAGS: 00010246
[5.020793] RAX: 0010 RBX: 8800040d8800 RCX: 

[5.020794] RDX: 880079761e70 RSI: 88007c438cc8 RDI:

[CentOS] Question on CentoS 7.4 on nvidia

2017-12-14 Thread Jerry Geis

I installed the elrepo kmod-nvidia and also the nvidia-detect and modules
(see below).

I had X working with the 3.10 from Centos  - but video was freezing. SO I
thought I would try the elrepo kernel. I installed that and X does not come
up?

How do I re-make the nvidia module for 4.14.5 kernel? I want to make sure
the kmod kernel did it.   I 'm thinking it did not.

lspci | grep VGA says GT218

Or  what do I look at now to see why X is not coming up?

Thanks,

Jerry

uname -r
4.14.5-1.el7.elrepo.x86_64


grep EE /var/log/Xorg.0.log
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   136.998] (EE) NVIDIA: Failed to initialize the NVIDIA kernel module.
Please see the
[   136.998] (EE) NVIDIA: system's kernel log for additional error
messages and
[   136.998] (EE) NVIDIA: consult the NVIDIA README for details.
[   136.998] (EE) No devices detected.
[   136.998] (EE)
[   136.998] (EE) no screens found(EE)
[   136.998] (EE)
[   136.998] (EE) Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[   136.998] (EE)
[   137.004] (EE) Server terminated with error (1). Closing log file.

uname -a

rpm -qa | grep kernel
kernel-3.10.0-693.el7.x86_64
kernel-tools-3.10.0-693.5.2.el7.x86_64
abrt-addon-kerneloops-2.1.11-48.el7.centos.x86_64
kernel-headers-3.10.0-693.5.2.el7.x86_64
kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
kernel-devel-3.10.0-693.el7.x86_64
kernel-3.10.0-693.5.2.el7.x86_64
kernel-ml-4.14.5-1.el7.elrepo.x86_64
kernel-tools-libs-3.10.0-693.5.2.el7.x86_64
kernel-devel-3.10.0-693.5.2.el7.x86_64
[root@mediaport14 ~]# rpm -qa | grep kernel-ml
kernel-ml-devel-4.14.5-1.el7.elrepo.x86_64
kernel-ml-4.14.5-1.el7.elrepo.x86_64


# rpm -qa | grep nvidia
kmod-nvidia-340xx-340.102-4.el7_4.elrepo.x86_64
nvidia-detect-384.90-1.el7.elrepo.x86_64
yum-plugin-nvidia-1.0.2-1.el7.elrepo.noarch
nvidia-x11-drv-340xx-340.102-1.el7.elrepo.x86_64
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accessing crashed disk

2017-12-14 Thread J Martin Rushton

On 14/12/17 18:57, Warren Young wrote:
> On Dec 13, 2017, at 5:15 PM, J Martin Rushton 
>  wrote:
>>
>> # dd if=/dev/sdc of=/home/dd-copy-of-sdc
> 
> Better, use ddrescue:
> 
>https://www.gnu.org/software/ddrescue/
> 
> dd will do unfortunate things like quit early on I/O errors, even if later 
> blocks would read just fine.  ddrescue assumes the input file is dodgy and 
> tries to cope.
>
Looks interesting.  I've only used dd in anger, and then only maybe 3 or
4 times over the last 20 years.  It's worth pointing out that ddrescue
is not in the main distro, you'll need to get it from EPEL.

Whatever method you use though: "Be diligent because every time a
physically damaged drive powers up and is able to output some data, it
may be the very last time that it ever will." (ddrescue manual section 9)



signature.asc
Description: OpenPGP digital signature
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Accessing crashed disk

2017-12-14 Thread Warren Young

On Dec 13, 2017, at 5:15 PM, J Martin Rushton  
wrote:
> 
> # dd if=/dev/sdc of=/home/dd-copy-of-sdc

Better, use ddrescue:

   https://www.gnu.org/software/ddrescue/

dd will do unfortunate things like quit early on I/O errors, even if later 
blocks would read just fine.  ddrescue assumes the input file is dodgy and 
tries to cope.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Problems with dnscrypt's package from EPEL

2017-12-14 Thread Stephen John Smoogen

Can you give more information on the unbound setup? We use unbound in
Fedora Infrastructure on RHEL-7 servers. I know there is an selinux
dance we have to do to start it properly without a special policy...
but I don't know exactly the details on why.

On 11 December 2017 at 03:56, C. L. Martinez  wrote:
> Sorry Stephen. I have enabled another dnscrypt process in port 6355 to
> test ... But no luck.
>
> On the other side, I am not sure if dnscrypt the problem. I have
> replaced unbound by dnsmasq and voila! ... All it is working very fast
> (and dnsmasq only spends 75 MiB of RAM, when unbound spends 400 MiB).
> And no more SERVFAIL errors ... But I don't understand where is the
> problem with unbound.conf's file then. Using same config for dnscrypt
> and unbound in a FreeBSD vm, all works ok.
>
> On Sun, Dec 10, 2017 at 8:10 PM, Stephen John Smoogen  
> wrote:
>> Not sure if this is a factor yet, but your forwardzone is looking for
>> 3 ports but only 2 ports are configured in the systemd startup.. so
>> are 1/3 of all lookups going to fail? Or is the 6355 a 'given' (aka it
>> will be set up whether 6353 and 6354 are setup?)
>>
>> On 9 December 2017 at 16:45, C. L. Martinez  wrote:
>>> On Sat, Dec 09, 2017 at 10:25:41PM +0100, C. L. Martinez wrote:
 On Sat, Dec 09, 2017 at 03:03:52PM -0500, Stephen John Smoogen wrote:
 > On 9 December 2017 at 14:04, C. L. Martinez  wrote:
 > > Hi all,
 > >
 > >  I have installed dnscrypt's rpm package from EPEL repo under a CentOS 
 > > 7.4 and using unbound as a resolver. But, I see constant timeouts and 
 > > responses are very slow ... Using same config in a Debian 9 virtual 
 > > machine, all works ok.
 > >
 > >  I think the problem is with dnscrypt's rpm package provided by EPEL. 
 > > Anyone have seen similar problems?
 > >
 >
 > Can you give some more information on what you are seeing and how you
 > have it set up? I can try to duplicate it in EPEL and/or put in bugs
 > on the package.
 >
 >

 Of course and thanks in advance Stephen. My dnscrypt startup scripts use 
 the following options:

 [Service]
 Type=forking
 PIDFile=/var/run/dnscrypt-cs.pid
 ExecStart=/usr/sbin/dnscrypt-proxy \
   --daemonize \
   --user=nobody \
   --pidfile=/var/run/dnscrypt-cs.pid \
   --ephemeral-keys \
   --resolver-name=cs-fi \
   --logfile=/tmp/cs.log \
   --local-address=127.0.0.1:6354
 Restart=on-abort

 [Service]
 Type=forking
 PIDFile=/var/run/dnscrypt-ipredator.pid
 ExecStart=/usr/sbin/dnscrypt-proxy \
   --daemonize \
   --user=nobody \
   --pidfile=/var/run/dnscrypt-ipredator.pid \
   --ephemeral-keys \
   --resolver-name=ipredator \
   --logfile=/tmp/ipredator.log \
   --local-address=127.0.0.1:6353
 Restart=on-abort

 And unbound.conf is:

 server:
   interface: 127.0.0.1
   interface: 172.22.54.4
   interface: ::1
   port: 53
   do-ip6: no
   do-udp: yes
   do-tcp: yes
   num-threads: 1

   access-control: 0.0.0.0/0 refuse
   access-control: 127.0.0.0/8 allow
   access-control: ::0/0 refuse
   access-control: ::1 allow
   access-control: 172.22.54.0/29 allow
   access-control: 172.22.55.1 allow

   hide-identity: yes
   hide-version: yes

   do-not-query-localhost: no
   val-permissive-mode: yes
   val-clean-additional: yes
   module-config: "validator iterator"
>>>
>>> Oops .. sorry. There are more options in unbound.conf's file:
>>>
>>> remote-control:
>>> control-enable: yes
>>> control-use-cert: yes
>>> control-interface: 127.0.0.1
>>>
>>> forward-zone:
>>> name: "."
>>> forward-addr: 127.0.0.1@6353
>>> forward-addr: 127.0.0.1@6354
>>> forward-addr: 127.0.0.1@6355
>>>
>>> Sorry.
>>>
>>> --
>>> Greetings,
>>> C. L. Martinez
>>> ___
>>> CentOS mailing list
>>> CentOS@centos.org
>>> https://lists.centos.org/mailman/listinfo/centos
>>
>>
>>
>> --
>> Stephen J Smoogen.
>> ___
>> CentOS mailing list
>> CentOS@centos.org
>> https://lists.centos.org/mailman/listinfo/centos
> ___
> CentOS mailing list
> CentOS@centos.org
> https://lists.centos.org/mailman/listinfo/centos



-- 
Stephen J Smoogen.
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Spamassassin vs. SELinux trouble

2017-12-14 Thread Nicolas Kovacs

Le 12/12/2017 à 21:25, Gordon Messmer a écrit :
> You may have had a custom context set on /var/log/spamassassin or a
> sub-path in the past, overwritten by a recent update.  That's a normal
> occurrence if you set context using chcon rather than "semanage
> fcontext".  The latter is persistent; the former is not.
> 
> Spamassassin can write to /var/lib/spamassassin, which makes that a more
> suitable location for bayes_toks than /var/log.  However, if you'd
> prefer to keep your bayes_toks file where it is, use:
> 
>   semanage fcontext -a -t spamd_var_lib_t
> /var/log/spamassassin/.spamassassin
>   restorecon -Rv /var/log/spamassassin/.spamassassin

Thanks very much. That got me on the right track, though I solved the
problem a bit differently.

# semanage fcontext -a -t spamd_var_lib_t '/var/log/spamassassin(/.*)?'
# restorecon -Rv /var/log/spamassassin/

That did the trick.

Cheers,

Niki

-- 
Microlinux - Solutions informatiques durables
7, place de l'église - 30730 Montpezat
Site : https://www.microlinux.fr
Blog : https://blog.microlinux.fr
Mail : i...@microlinux.fr
Tél. : 04 66 63 10 32
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Broadcom BCM4352 on Centos 7

2017-12-14 Thread Akemi Yagi

On Thu, Dec 14, 2017 at 6:59 AM, Akemi Yagi  wrote:

>
> Just wanted to add a note that you can use ELRepo's drivers with
> SecureBoot enabled if you so wish. 
> Here's how:
> 
> http://elrepo.org/tiki/SecureBootKey
>

Yet another comment. Sorry, the above note is a general one. The
self-built kmod-wl package does not have the SB key signed by ELRepo. This
note has been added to our wiki page.

Akemi
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS-virt] Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set triggers domU kernel WARNING, then domU becomes unresponsive

2017-12-14 Thread Akemi Yagi

On Mon, Dec 11, 2017 at 4:52 PM, Adi Pircalabu  wrote:

> Has anyone seen this recently? I couldn't replicate it on:
> - CentOS 6 running kernel-2.6.32-696.16.1.el6.x86_64,
> kernel-lt-4.4.105-1.el6.elrepo.x86_64
> - CentOS 7 running 4.9.67-1.el7.centos.x86_64
>
> But I can replicate it consistently running "xl -v vcpu-set  "
> on:
> - CentOS 6 running 4.14.5-1.el6.elrepo.x86_64
> - CentOS 7 running 4.14.5-1.el7.elrepo.x86_64
>
> dom0 versions tested with similar results in the domU:
> - 4.6.6-6.el7 on kernel 4.9.63-29.el7.x86_64
> - 4.6.3-15.el6 on kernel 4.9.37-29.el6.x86_64
>
> Noticed behaviour:
> - These commands stall:
> top
> ls -l /var/tmp
> ls -l /tmp
> - Stuck in D state on the CentOS 7 domU:
> root 5  0.0  0.0  0 0 ?D11:20   0:00
> [kworker/u8:0]
> root   316  0.0  0.0  0 0 ?D11:20   0:00
> [jbd2/xvda1-8]
> root  1145  0.0  0.2 116636  4776 ?Ds   11:20   0:00 -bash
> root  1289  0.0  0.1  25852  2420 ?Ds   11:35   0:00
> /usr/bin/systemd-tmpfiles --clean
> root  1290  0.0  0.1 125248  2696 pts/1D+   11:44   0:00 ls
> --color=auto -l /tmp/
> root  1293  0.0  0.1 125248  2568 pts/2D+   11:44   0:00 ls
> --color=auto -l /var/tmp
> root  1296  0.0  0.2 116636  4908 pts/3Ds+  11:44   0:00 -bash
> root  1358  0.0  0.1 125248  2612 pts/4D+   11:47   0:00 ls
> --color=auto -l /var/tmp
>
> At a first glance it appears the issue is in 4.14.5 kernel. Stack traces
> follow:
>
> Adi Pircalabu


Can you test-install 4.15-rcX

 to see if the problem persists in the latest kernel?:

http://elrepo.org/people/ajb/devel/kernel-ml/el7/x86_64/RPMS/

Akemi
___
CentOS-virt mailing list
CentOS-virt@centos.org
https://lists.centos.org/mailman/listinfo/centos-virt

Re: [CentOS] Broadcom BCM4352 on Centos 7

2017-12-14 Thread Akemi Yagi

On Thu, Dec 14, 2017 at 6:59 AM, Akemi Yagi  wrote:

> On Thu, Dec 14, 2017 at 5:39 AM, Gary Stainburn 
> wrote:
>
>> After getting nowhere with the mokutil command I decided to use the other
>> option and turn off secure boot in the BIOS settings.
>>
>> I had been loathed to do this because every time I do anything in the
>> BIOS it
>> stuffs the boot order and reverts to booting straight into Win8.  Guess
>> what,
>> as soon as I turned off secure boot it did exactly that. Turnng secure
>> boot
>> back on made no difference.
>>
>> Thankfully, the mailing list archives for this list still contain the
>> instructions on how to fix it.
>>
>> For those interested, it involved pressing F9 at boot time to select the
>> boot
>> menu and selecting the Centos option. This then went through GRUB as
>> normal
>> and booted.  I then used 'eftbootmgr -o' to define the correct boot
>> sequence.
>>
>> The upshot is that I now have a laptop that boots correctly, and that
>> successfully uses the built in Broadcom WiFi adaptor.
>>
>> Thanks everyone for your help
>>
>
> Glad to hear things are now working for you.
>
> Just wanted to add a note that you can use ELRepo's drivers with
> SecureBoot enabled if you so wish. 
> Here's how:
>
> 
> http://elrepo.org/tiki/SecureBootKey
>
> Akemi
>
> Another [important] note if you are running CentOS 7.4. There is an issue
with the current version of shim in CentOS 7.4. The details can be found
here:

https://bugs.centos.org/view.php?id=14050

Follow the workaround in that bug report. Hope the problem gets fixed soon
by CentOS devs.

Akemi
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Broadcom BCM4352 on Centos 7

2017-12-14 Thread Akemi Yagi

On Thu, Dec 14, 2017 at 5:39 AM, Gary Stainburn  wrote:

> After getting nowhere with the mokutil command I decided to use the other
> option and turn off secure boot in the BIOS settings.
>
> I had been loathed to do this because every time I do anything in the BIOS
> it
> stuffs the boot order and reverts to booting straight into Win8.  Guess
> what,
> as soon as I turned off secure boot it did exactly that. Turnng secure boot
> back on made no difference.
>
> Thankfully, the mailing list archives for this list still contain the
> instructions on how to fix it.
>
> For those interested, it involved pressing F9 at boot time to select the
> boot
> menu and selecting the Centos option. This then went through GRUB as normal
> and booted.  I then used 'eftbootmgr -o' to define the correct boot
> sequence.
>
> The upshot is that I now have a laptop that boots correctly, and that
> successfully uses the built in Broadcom WiFi adaptor.
>
> Thanks everyone for your help
>

Glad to hear things are now working for you.

Just wanted to add a note that you can use ELRepo's drivers with SecureBoot
enabled if you so wish. 
Here's how:


http://elrepo.org/tiki/SecureBootKey

Akemi
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Broadcom BCM4352 on Centos 7

2017-12-14 Thread Gary Stainburn

After getting nowhere with the mokutil command I decided to use the other 
option and turn off secure boot in the BIOS settings.

I had been loathed to do this because every time I do anything in the BIOS it 
stuffs the boot order and reverts to booting straight into Win8.  Guess what, 
as soon as I turned off secure boot it did exactly that. Turnng secure boot 
back on made no difference.

Thankfully, the mailing list archives for this list still contain the 
instructions on how to fix it.

For those interested, it involved pressing F9 at boot time to select the boot 
menu and selecting the Centos option. This then went through GRUB as normal 
and booted.  I then used 'eftbootmgr -o' to define the correct boot sequence.

The upshot is that I now have a laptop that boots correctly, and that 
successfully uses the built in Broadcom WiFi adaptor.

Thanks everyone for your help
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Broadcom BCM4352 on Centos 7

2017-12-14 Thread Gary Stainburn

On Monday 11 December 2017 18:50:06 Akemi Yagi wrote:
> As far as I know, the contents on the CentOS wiki are for CentOS 7.3 (or
> earlier) and a patch is needed to use the driver under 7.4.
>
> You may want to go to the ELRepo article that is referenced on that page (
> http://elrepo.org/tiki/wl-kmod
>  ). The ELRepo instructions are up to date and should cover EL7.4.
>
> Akemi

I have followed your suggestion and all seemed fine. 

After rebooting I tried to do the modprobe but got the following:

[root@gary ~]# modprobe wl
modprobe: ERROR: could not insert 'wl': Required key not available
[root@gary ~]# 

This relates to the secure boot that is mentioned on the page. I therefore 
went through the process of disabling secure boot.  This consisted of 
running:

[root@gary ~]# mokutil --disable-validation
password length: 8~16
input password: 
input password again: 
[root@gary ~]# 

After doing this I rebooted. As part of the reboot I was supposed to be asked 
for the password that I had just created but I wasn't. Then, after the reboot 
I tried the modprobe command but received the same error message.

Anyone got  ideas what I need to do next?
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos

Re: [CentOS] Question on CentoS 7.4 on nvidia

Re: [CentOS] Accessing crashed disk

Re: [CentOS] Traffic shaping on CentOS

[CentOS] Traffic shaping on CentOS

Re: [CentOS] Question on CentoS 7.4 on nvidia

Re: [CentOS] Question on CentoS 7.4 on nvidia

Re: [CentOS-virt] Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set triggers domU kernel WARNING, then domU becomes unresponsive

Re: [CentOS] Accessing crashed disk

Re: [CentOS] Question on CentoS 7.4 on nvidia

Re: [CentOS] Question on CentoS 7.4 on nvidia

Re: [CentOS-virt] Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set triggers domU kernel WARNING, then domU becomes unresponsive

[CentOS] Question on CentoS 7.4 on nvidia

Re: [CentOS] Accessing crashed disk

Re: [CentOS] Accessing crashed disk

Re: [CentOS] Problems with dnscrypt's package from EPEL

Re: [CentOS] Spamassassin vs. SELinux trouble

Re: [CentOS] Broadcom BCM4352 on Centos 7

Re: [CentOS-virt] Xen PV DomU running Kernel 4.14.5-1.el7.elrepo.x86_64: xl -v vcpu-set triggers domU kernel WARNING, then domU becomes unresponsive

Re: [CentOS] Broadcom BCM4352 on Centos 7

Re: [CentOS] Broadcom BCM4352 on Centos 7

Re: [CentOS] Broadcom BCM4352 on Centos 7

Re: [CentOS] Broadcom BCM4352 on Centos 7

22 matches

Site Navigation

Mail list logo

Footer information