We are in the process of migrating this forum. A new space will be available soon. We are sorry for the inconvenience.

kernel error crashing my server


JIM C
11/02/2014, 20h59
it doesnt matter any more,pointless trying to rescuse the data. i ordered a soyoustart server instead

Hwh
10/02/2014, 22h40
OK, then I've lost you, sorry. Why are you quoting an apt error?
Did you really install Linux on an NTFS filesystem? That's most probably not a good idea and I would be somewhat surprised if it worked...

As for mounting NTFS writable, you should probably use ntfs-3g for mounting. The in-kernel NTFS driver will by default mount read-only.

This is for data rescue, right? Since otherwise, I would start from scratch if I were in your place.

JIM C
10/02/2014, 22h17
it doesnt let me mount the disk

Hwh
10/02/2014, 13h00
So you seem to be a step further - but probably mounted the partition read-only. Depending on whether you really know what you're doing, a fsck seems to be in order. The kernel log (dmesg) probably tells you why that filesystem got mounted read-only?

JIM C
09/02/2014, 15h55
if i try to do anything i get
Not using locking for read only lock file /var/cache/apt/archives/lock

nowwhat
09/02/2014, 00h36
NTFS ?
Is a NTFS partition important for you Debian OS ?
.....

JIM C
08/02/2014, 23h21
Citation Envoyé par nowwhat
Mounting a drive(s) in rescue mode is possible even if the all partitions contain pure crap ....
If mounting isn't possible (show us !) the your drives are "out" physical.

Remember that in rescue mode, you OS or kernel isn't booting - your drives aren't even accessed.
Yes i know that,but i cant take the server out of resuce mode or the server crashes,ill post the ntfs mounting error and you can see.

mount: block device /dev/sda1 is write-protected, mounting
read-only
NTFS signature is missing.

nowwhat
08/02/2014, 19h06
Mounting a drive(s) in rescue mode is possible even if the all partitions contain pure crap ....
If mounting isn't possible (show us !) the your drives are "out" physical.

Remember that in rescue mode, you OS or kernel isn't booting - your drives aren't even accessed.

JIM C
08/02/2014, 17h42
Citation Envoyé par ostree
this cpu is 64bit so is ment to work under a 64bit linux. what is worst is that look like you run debian-32bit with 32bit kernel - right? is this true?
Yes it was,but now server offline in rescuse mode and it wont mount so cant access it and cant access the harddrive.

ostree
07/02/2014, 13h59
Citation Envoyé par JIM C
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU W3520 @ 2.67GHz
stepping : 5
microcode : 0x11
cpu MHz : 2668.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_ tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds _cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dther m tpr_shadow vnmi flexpriority ept vpid
bogomips : 5333.48
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:
this cpu is 64bit so is ment to work under a 64bit linux. what is worst is that look like you run debian-32bit with 32bit kernel - right? is this true?

JIM C
07/02/2014, 01h10
Citation Envoyé par nowwhat
A "live" server ?

You can compile/rebuild while it's up. Putting in place is just a question of a reboot.
And, anyway, it is a KS after all.

You said it already, a KS is good for "fixing it up" and "messing around"

But don't keep a brain dead kernel. Thats not good.
Its not the kernel thats the problem,its debian os.
i tried to put the server in rescue mode to fix the problems but it wouldnt let me mount it,not the server has gone offline and wont power on back up.

nowwhat
07/02/2014, 00h42
A "live" server ?

You can compile/rebuild while it's up. Putting in place is just a question of a reboot.
And, anyway, it is a KS after all.

You said it already, a KS is good for "fixing it up" and "messing around"

But don't keep a brain dead kernel. Thats not good.

JIM C
06/02/2014, 21h02
its a live server,server is up but i have no access to ssh now.

nowwhat
06/02/2014, 20h57
Basculer de 32 vers 64 .......
Je te conseille de
make clean
avant.

JIM C
06/02/2014, 20h53
Citation Envoyé par nowwhat
A bear kernel source code package compiles without any error.
It doesn't need a fix-up - that will generate errors.

But ... tell me something.
Did you put an initial /.config file in place ??

Let say you take the lastest kernel source package from here: www.kernel.org
Exemple, you want a basic 64 bits - IPv6 kernel build - without grsec etc.

ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.23/

and take this config file config-3.10.23-xxxx-std-ipv6-64 from here ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.23/

Put this file in the root of the kernel source package: cd to the kernel source root dir, and
wget ftp://ftp.ovh.net/made-in-ovh/bzImag...xx-std-ipv6-64

Now:
make clean
make menuconfig
and < Load > your config file: config-3.10.23-xxxx-std-ipv6-64
Make your changes (at least => General setup => third option: the kernel unamel)
Now, < Save > your config and name it dot config == ".config"

make

and go for a walk.
When done:
make install
Its not kernel related,i tried to upgrade from 32 to 64 and a long the way messed up and when i tried to put things back i got an unmet dependencies errors.

nowwhat
06/02/2014, 20h42
A bear kernel source code package compiles without any error.
It doesn't need a fix-up - that will generate errors.

But ... tell me something.
Did you put an initial /.config file in place ??

Let say you take the lastest kernel source package from here: www.kernel.org
Exemple, you want a basic 64 bits - IPv6 kernel build - without grsec etc.

ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.23/

and take this config file config-3.10.23-xxxx-std-ipv6-64 from here ftp://ftp.ovh.net/made-in-ovh/bzImage/3.10.23/

Put this file in the root of the kernel source package: cd to the kernel source root dir, and
wget ftp://ftp.ovh.net/made-in-ovh/bzImag...xx-std-ipv6-64

Now:
make clean
make menuconfig
and < Load > your config file: config-3.10.23-xxxx-std-ipv6-64
Make your changes (at least => General setup => third option: the kernel unamel)
Now, < Save > your config and name it dot config == ".config"

make

and go for a walk.
When done:
make install

JIM C
06/02/2014, 20h29
Citation Envoyé par nowwhat
Not a problem.

When putting in place a new kernel, and telling the "boot manager" (grub or lilo) to take in account the new kernel, you never throw away the kernel that you used before.
If problems pop up, boot in rescue mode, mount disks, point grub or lili to the kernel before and (switch back to HD boot in Manager OVH)... then type:
reboot
And your are back there you started.

Always keep the latest 2,3 kernel files.

Btw: messing around does mess up things. That normal
yea but i try to fix it im getting alot of dependencies errors when i try to fix it.

nowwhat
06/02/2014, 20h11
Not a problem.

When putting in place a new kernel, and telling the "boot manager" (grub or lilo) to take in account the new kernel, you never throw away the kernel that you used before.
If problems pop up, boot in rescue mode, mount disks, point grub or lili to the kernel before and (switch back to HD boot in Manager OVH)... then type:
reboot
And your are back there you started.

Always keep the latest 2,3 kernel files.

Btw: messing around does mess up things. That normal

JIM C
06/02/2014, 19h49
I was messing around with this last night,i think i might have done some damage to the os.

Kitty
06/02/2014, 06h08
Citation Envoyé par nowwhat
http://guides.ovh.com/KernelInstall (be carefull : French !!)
Many (most? all?) of these guides are also available in English at help.ovh.com

For instance: http://help.ovh.com/KernelInstall

JIM C
06/02/2014, 04h03
Citation Envoyé par ostree
@nowwhat: as selinux is, so grsec/pax are good standards (times have changed) https://en.wikipedia.org/wiki/Grsecurity.
@JIM C: just q, in ur post i see Supermicro X8STi/X8STi, this board is for Intel® Core™ i7 / i7 Extreme Edition, and Intel® Xeon® 5600/5500/3600/3500 series processors (QPI up to 6.4 GT/s) - all are 64 arch, so why i see kernel 3.10.9-xxxx-grs-ipv6-32 on this host? can u pastebin output of: cat /proc/cpuinfo?
regards

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Xeon(R) CPU W3520 @ 2.67GHz
stepping : 5
microcode : 0x11
cpu MHz : 2668.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx rdtscp lm constant_ tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds _cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 sse4_2 popcnt lahf_lm ida dther m tpr_shadow vnmi flexpriority ept vpid
bogomips : 5333.48
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

nowwhat
04/02/2014, 21h06
I know, I know.
I'm not saying grsec is bad or something like that.
Just trying to propose something that makes things to happen, not just core-dump.

ostree
04/02/2014, 20h17
@nowwhat: as selinux is, so grsec/pax are good standards (times have changed) https://en.wikipedia.org/wiki/Grsecurity.
@JIM C: just q, in ur post i see Supermicro X8STi/X8STi, this board is for Intel® Core™ i7 / i7 Extreme Edition, and Intel® Xeon® 5600/5500/3600/3500 series processors (QPI up to 6.4 GT/s) - all are 64 arch, so why i see kernel 3.10.9-xxxx-grs-ipv6-32 on this host? can u pastebin output of: cat /proc/cpuinfo?
regards

nowwhat
04/02/2014, 19h44
What about a kernel without 'gadgets, bells, ice cream and other plugins, patches, and mods" ??

Most servers on planet earth run a basic kernel, straight from the box kernel, like bzImage-3.10.28-xxxx-std-ipv6-32 or bzImage-3.10.28-xxxx-std-ipv6-64.

I use them for years now.

Can only say one thing : I still don't know what a kernel is, but it isn't crash-dump on me .......
Try for yourself.

JIM C
04/02/2014, 19h36
i tried the xxxx-grs-ipv6-32? one. ill try -xxxx-grspax-ipv6-32

ostree
04/02/2014, 14h39
@JIM C: have you tried -xxxx-grspax-ipv6-32 one or just -xxxx-grs-ipv6-32?
@ovh: please do patch all grsec and grsec/pax kernels
refs: https://forums.grsecurity.net/viewto...t=3909&p=13813
regards

JIM C
03/02/2014, 14h44
Citation Envoyé par Felix
What kind of workload do you have on this server?
Maybe you can try the latest test kernel (version 3.10.28) available on our ftp server: ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-test/

Best regards,
Felix
ill try that without the grs,it wouldnt be doing much.not under stress.

Felix
02/02/2014, 16h06
What kind of workload do you have on this server?
Maybe you can try the latest test kernel (version 3.10.28) available on our ftp server: ftp://ftp.ovh.net/made-in-ovh/bzImage/latest-test/

Best regards,
Felix

JIM C
02/02/2014, 15h08
i updated the kernel and still getting the error.its been 9 days since i updated the kernel,this happens every 7-9 days. name is ks205760.kimsufi.com

JIM C
30/01/2014, 17h53
I updated the kernel to the latest one,im gonna wait a few days to see if its ok.

Felix
30/01/2014, 12h49
If you still get this error message: "PAX: size overflow detected in function atomic_add_return" please post your server number so I can look into it.

Felix

nowwhat
14/01/2014, 22h48
Well, you could go for the source.
Why copying something from somewhere if you could have de original.
You already have a 'Linux' based system to build one.

There is a more easy way: consult the manual that is still valid for your server http://guides.ovh.com/KernelInstall (be carefull : French !!)
Think about getting a non-GRSEC version.

Note that GRSEC doesn't bug: it warns you (the result of this thread) what happens is GRSEC discovers a dangerous 'kernel' situation.
Now a day, these errors happen ..... when software installed on the server stresses the kernel on a 'nonstandard' way.

Joujdaks
13/01/2014, 10h23
Hello,

So if i got this right i should go ahead with a kernel update om the kimsufi server from https://www.kernel.org/?
By the way I contacted GRSecurity as they were the cause of the problem and PaX Team told me that the kernel that its being distributed v3.10.X has this bug.

Thanks!

JIM C
12/01/2014, 21h36
Ok ill try thanks

Citation Envoyé par nowwhat
No way.
But you're building an executable that starts when your server starts.
It's the very first 'file' that gets loaded.
Remember: the kernel is not your OS !!

Recent install procedures even do the 'lilo' or 'grub' thing for you (putting in place the info in the boot record so the correct kernel file is loaded - several kernel files can exists in /boot - I always keep the last two stable version)

But, first, look up how it's done.
And backup your server first (you already did that anyway, otherwise, stop right now ...)

nowwhat
12/01/2014, 19h49
Citation Envoyé par Joujdaks
but would this mean my server will format? and i will loose the data i have in it?
Citation Envoyé par JIM C
Will the data be safe or will it be deleted?
No way.
But you're building an executable that starts when your server starts.
It's the very first 'file' that gets loaded.
Remember: the kernel is not your OS !!

Recent install procedures even do the 'lilo' or 'grub' thing for you (putting in place the info in the boot record so the correct kernel file is loaded - several kernel files can exists in /boot - I always keep the last two stable version)

But, first, look up how it's done.
And backup your server first (you already did that anyway, otherwise, stop right now ...)

JIM C
12/01/2014, 15h52
Citation Envoyé par nowwhat
So, as I said above, first line:
Do not keep a kernel for live.
Upgrade.

For years now, I don't even use the kernel elected for my OS (Debian 7.x) anymore.
I just take the latest stable from here: https://www.kernel.org/ - that is, the source code.
Then, roughly:
./configure
make menuconfig
make
make install
reboot

25 minutes it will take, 23 for the compile and build.

I should try doing that for my Windows PC ones
Will the data be safe or will it be deleted?

Joujdaks
12/01/2014, 11h08
Hello,

I just got yesterday the same problem!
I don't mind upgrading my kernel but I have no idea how to do that (Its ok I'll google)
but would this mean my server will format? and i will loose the data i have in it?

Thanks

nowwhat
11/01/2014, 03h13
So, as I said above, first line:
Do not keep a kernel for live.
Upgrade.

For years now, I don't even use the kernel elected for my OS (Debian 7.x) anymore.
I just take the latest stable from here: https://www.kernel.org/ - that is, the source code.
Then, roughly:
./configure
make menuconfig
make
make install
reboot

25 minutes it will take, 23 for the compile and build.

I should try doing that for my Windows PC ones

JIM C
11/01/2014, 02h42
Citation Envoyé par nowwhat
That doesn't mean that kernel X, installed on date X, should be kept.
OVH just pre-installs a kernel that works (for thousands of us).

Never ever think that you should keep that one. FOLLOW the upgrade path.
Years ago, I loaded the source code of a new kernel from here https://www.kernel.org/ - I configued the "thing" (took all the default values) - compiled it - takes 30 minutes - and installed it - on a KS.
That just plain works.
I'm running a vanilla 3.12.6 right now.

But, that's not the real issue.
You use a pretty basic standard good kernel, WITH GRSEC security patches. GRSEC ( http://grsecurity.net/ ) is a concept, thats helps you to keep a server (kernel) safe.
Or, you managed to crash a kernel - and GRSEC protection is warning you.
This is not normal at all !

The software (that you chosed !!!) makes the kernel goes down. That software should be ditched if you can not repair it ...
Or upgraded ....

Remember: this is free code. If it works for you, great !
If it doesn't, and (example) Apache makes your system going down, go speak with the Apache people.
Again, if a soft breaks your kernel don't even think. Throw it away right now.
(or, again, repair it (have it repaired by some one))
I spoke with the software people and they concluded it was a kernel problem.

nowwhat
09/01/2014, 02h17
Citation Envoyé par JIM C
not sure its what was supplied with the server.
That doesn't mean that kernel X, installed on date X, should be kept.
OVH just pre-installs a kernel that works (for thousands of us).

Never ever think that you should keep that one. FOLLOW the upgrade path.
Years ago, I loaded the source code of a new kernel from here https://www.kernel.org/ - I configued the "thing" (took all the default values) - compiled it - takes 30 minutes - and installed it - on a KS.
That just plain works.
I'm running a vanilla 3.12.6 right now.

But, that's not the real issue.
You use a pretty basic standard good kernel, WITH GRSEC security patches. GRSEC ( http://grsecurity.net/ ) is a concept, thats helps you to keep a server (kernel) safe.
Or, you managed to crash a kernel - and GRSEC protection is warning you.
This is not normal at all !

The software (that you chosed !!!) makes the kernel goes down. That software should be ditched if you can not repair it ...
Or upgraded ....

Remember: this is free code. If it works for you, great !
If it doesn't, and (example) Apache makes your system going down, go speak with the Apache people.
Again, if a soft breaks your kernel don't even think. Throw it away right now.
(or, again, repair it (have it repaired by some one))

JIM C
09/01/2014, 01h04
Citation Envoyé par nowwhat
Hi there.
What about another, more recent kernel ?

The "PAX: size overflow detected in function atomic_add_return " seems to say sometlik this this http://forums.grsecurity.net/viewtopic.php?f=1&t=2991
not sure its what was supplied with the server.

nowwhat
08/01/2014, 17h42
Hi there.
What about another, more recent kernel ?

The "PAX: size overflow detected in function atomic_add_return " seems to say sometlik this this http://forums.grsecurity.net/viewtopic.php?f=1&t=2991

JIM C
07/01/2014, 19h40
so due to a some sort of kernel error it crashes my server at least once a week?

> Jan 3 04:28:52 ks205760 kernel: PAX: size overflow detected in function atomic_add_return /var/home/fx/src/ovh-kernel/ovhkernel-xxxx-grs-ipv6-32/linux-3.$
> Jan 3 04:28:52 ks205760 kernel: CPU: 7 PID: 16462 Comm: sc_serv Not tainted 3.10.9-xxxx-grs-ipv6-32 #1
> Jan 3 04:28:52 ks205760 kernel: Hardware name: Supermicro X8STi/X8STi, BIOS 2.0 09/17/10
> Jan 3 04:28:52 ks205760 kernel: c1e709b6 c1e709b6 e4e5be54 c1c3f553 e4e5be74 c113090b c1e8c644 c1e60776
> Jan 3 04:28:52 ks205760 kernel: c1e56d60 00000151 c1e709b6 eb38cc70 e4e5be8c c1141321 c1e709b6 e54e319c
> Jan 3 04:28:52 ks205760 kernel: 00000005 a5730340 e4e5be98 c1a6715c eab05380 e4e5bf54 c1a68357 00000000
> Jan 3 04:28:52 ks205760 kernel: Call Trace:
> Jan 3 04:28:52 ks205760 kernel: [] dump_stack+0x16/0x18
> Jan 3 04:28:52 ks205760 kernel: [] report_size_overflow+0x2b/0x40
> Jan 3 04:28:52 ks205760 kernel: [] get_next_ino+0x81/0x90
> Jan 3 04:28:52 ks205760 kernel: [] sock_alloc+0x1c/0x60
> Jan 3 04:28:52 ks205760 kernel: [] SYSC_accept4+0x57/0x240
> Jan 3 04:28:52 ks205760 kernel: [] ? ktime_get_ts+0x38/0x100
> Jan 3 04:28:52 ks205760 kernel: [] ? poll_select_copy_remaining+0xff/0x1f0
> Jan 3 04:28:52 ks205760 kernel: [] SyS_accept4+0x1a/0x20
> Jan 3 04:28:52 ks205760 kernel: [] SyS_socketcall+0x253/0x3f0
> Jan 3 04:28:52 ks205760 kernel: [] ? SyS_select+0xdb/0x130
> Jan 3 04:28:52 ks205760 kernel: [] sysenter_do_call+0x12/0x2c
>