linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

archuser26 · 2015-10-17 19:29:27

Hello,

I ran sudo pacman -Syu this morning, and rebooted my computer because of a kernel update. After selecting Arch from the grub menu I saw the usual loading linux-grsec, and then loading initramfs. On loading initramfs my system froze up. I let it sit for a few minutes with no change, tried ctrl-alt-del with no luck, and eventually hit the reset button. I didn't have much time to deal with this issue, so to fix this I booted into a live usb, chroot into the broken system, removed linux-grsec and paxd, sudo pacman -S linux, and ran grub-mkconfig to generate a new boot menu. So far I am unable to find another bug report about this, and I am unable to provide detailed information as I had to remove the bad kernel update instead of doing more troubleshooting. I notice this version of grsec is already flagged out of date, so maybe this will be fixed soon? I did not want to create a bug report due to lack of information on my part, so I am creating this thread to see if anyone else may have run into this problem and knows how to fix it. Any ideas?

Head_on_a_Stick · 2015-10-17 19:33:27

Do you have a separate /boot partition and was it mounted during the upgrade?

EDIT: I had that grsec upgrade today and my system boots fine.

Last edited by Head_on_a_Stick (2015-10-17 19:35:17)

nail · 2015-10-17 19:58:50

The similar problem with linux-grsec 4.2.3.201510161817-1.
This release has a few bugs i think. Because bugs are not the same for all users.
But after these bugs system hangs on. (:

Black screen after reboot instead of LightDM login screen.
System freezes and only reset button solved it.
Me downgraded linux-grsec to previous version.

Today there is new linux-grsec released after post https://forums.grsecurity.net/viewtopic.php?f=3&t=4277 :
https://grsecurity.net/testing_rss.php

ps: me waiting for new version from Daniel Micay

Last edited by nail (2015-10-17 20:30:59)

nail · 2015-10-18 07:28:03

New version linux-grsec 4.2.3.201510171833-1 didn't solve the issue.

Downgraded to linux-grsec-4.2.3.201510130858-1

Last edited by nail (2015-10-18 07:28:27)

blm · 2015-10-18 09:00:48

nail wrote:

New version linux-grsec 4.2.3.201510171833-1 didn't solve the issue.
Downgraded to linux-grsec-4.2.3.201510130858-1

I have experienced the same thing with 4.2.3.201510171833-1 today. /var/log/boot.log shows nothing interesting since the boot hangs too early in the process (I think).

The output to the console claimed that the kernel "crashed suspiciously"

Perhaps I should have taken a picture with my phone; I just downgraded to 4.2.3.201510130858-1 also as a result.

sylvite · 2015-10-18 16:48:17

Same here. 20151017* hangs at initramfs. Downgraded to *20151013*.
I don't have a /var/log/boot.log.
But journalctl -xb -1, journalctl -xb -2, etc. don't have log entries for linux-grec when I switch between linux and linux-grsec from grub. Only "linux-4.2.3-1" entries. So, linux-grsec isn't getting to the point of logging to the journal.

Amanda S · 2015-10-19 02:54:44

I'm experiencing this too. The problem is, I just re-installed Arch, I don't have the older Kernel to downgrade. I'll see what I can do.

EDIT: I'll test 201510072230 (from the archive) and see if it works.

EDIT 2: It worked. http://www.wilderssecurity.com/threads/ … ng.380789/

Last edited by Amanda S (2015-10-19 03:47:10)

nail · 2015-10-19 08:09:13

2 critical bugs are added to BugTracker.
Just waiting...

Last edited by nail (2015-10-19 08:10:43)

Amanda S · 2015-10-19 09:05:45

nail wrote:

2 critical bugs are added to BugTracker.
Just waiting...

Well, I don't think that the Arch developer/TU will be able to fix it since this is not an Arch-specific problem. But it's worth the shot

From the Wiki:

If Arch is not responsible for a bug, the problem will not be solved by reporting the bug to Arch developers. Responsibility for a bug is said to lie upstream when it is not caused through the distribution's porting and integration efforts.
By reporting bugs upstream, you will not only help Archers and Arch developers, but you will also help other people in the free software community as the solution will trickle down to all distributions.

https://wiki.archlinux.org/index.php/Re … or_Arch.3F

Last edited by Amanda S (2015-10-19 09:09:32)

nail · 2015-10-19 09:12:22

Amarildo wrote:

nail wrote:
2 critical bugs are added to BugTracker.
Just waiting...
Well, I don't think that the Arch developer/TU will be able to fix it since this is not an Arch-specific problem. But it's worth the shot

i created new topic also here https://forums.grsecurity.net/viewforum.php?f=3 abou this bug.
2 hours left. Topic is still unmoderated

Last edited by nail (2015-10-19 09:12:50)

Amanda S · 2015-10-19 11:12:51

It's open now.

Aldaris · 2015-10-19 11:48:45

I just tested the linux-grsec package from the repositories and have the same issue. Curiously, I do not have the problem with my own 4.2.3.201510171833 package that was compiled with my custom config. I did not yet enable CONFIG_PAX_SIZE_OVERFLOW and found this warning in the changelog:

Note that size_overflow is currently marked BROKEN.

It's just a guess. I did not compile a kernel with just this option disabled. I did not even look through the entire changelog if this warning was revoked later. But the package from the community repo has CONFIG_PAX_SIZE_OVERFLOW enabled.

Last edited by Aldaris (2015-10-19 11:49:51)

Amanda S · 2015-10-19 12:02:07

It's advised to have CONFIG_PAX_SIZE_OVERFLOW. Compiling your own Kernel is fine but you'd have to disable that protection and it could take several minutes (or hours) to compile.

Have you tried an older Kernel from the Archive? http://www.wilderssecurity.com/threads/ … st-2535496

Irok · 2015-10-19 21:26:43

Please someome tell it when it will fix to allow pacman to update grsec

nail · 2015-10-19 21:37:35

In progress: https://bugs.archlinux.org/task/46794

AND
If it's not difficult - can someone explain how to write dmesg logs to file before system hangs on?
Disabling clearing of boot messages: https://wiki.archlinux.org/index.php/Di … t_messages - doesn't help. No dmesg logs for kernel crashes and panics.

Irok · 2015-10-20 01:08:43

Update 20 October did not solved the problem

Amanda S · 2015-10-20 03:49:21

Irok wrote:

Please someome tell it when it will fix to allow pacman to update grsec

You can still use grsec, just use one from the Archive: http://www.wilderssecurity.com/threads/ … st-2535496

Irok · 2015-10-20 10:49:26

Amarildo wrote:

Irok wrote:
Please someome tell it when it will fix to allow pacman to update grsec
You can still use grsec, just use one from the Archive: http://www.wilderssecurity.com/threads/ … st-2535496

Hi, I tried but was when the usb bug so I need the next to this one that was that worked ok.

nail · 2015-10-20 13:16:53

New release:
https://grsecurity.net/testing_rss.php
grsecurity-3.1-4.2.3-201510200858.patch
--------------------------------------------------------------------------------------------
Add a new config option from Emese to allow SIZE_OVERFLOW to be enabled
while having it not kill the userland process in an overflow condition.
This will help us obtain reports over the next few weeks while not making
some percentage of users' machines unusable.

To enable this option, set CONFIG_PAX_SIZE_OVERFLOW_DISABLE_KILL=y in .config
--------------------------------------------------------------------------------------------

Amanda S · 2015-10-20 14:02:54

So the new kernel that was released today isn't working too?

sylvite · 2015-10-20 16:23:32

Tried 4.2.3.201510191935-1. It boots fine on my laptop, but still won't boot (same symptoms) on my server, which is where I had already downgraded to get around this issue.

Last edited by sylvite (2015-10-20 16:24:51)

sylvite · 2015-10-21 04:42:02

Tried 4.2.3.201510200858-1, and back to up and running now.

Not sure if these are needed or helpful, but these appear to be related to the new CONFIG_PAX_SIZE_OVERFLOW_DISABLE_KILL flag. From journalctl--

Oct 20 23:37:45 x kernel: PAX: slow and weak UDEREF enabled
Oct 20 23:37:45 x kernel: PAX: slow and weak UDEREF enabled
Oct 20 23:37:45 x kernel: PAX: slow and weak UDEREF enabled
Oct 20 23:37:45 x kernel: PAX: slow and weak UDEREF enabled
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_do_math_op drivers/acpi/acpica/exmisc.c:414 cicus.45_57 min, count: 30, decl: acpi_ex_do_math_op; num: 0; context: fndecl;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_do_math_op drivers/acpi/acpica/exmisc.c:414 cicus.45_57 min, count: 30, decl: acpi_ex_do_math_op; num: 0; context: fndecl;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_do_math_op drivers/acpi/acpica/exmisc.c:414 cicus.45_57 min, count: 30, decl: acpi_ex_do_math_op; num: 0; context: fndecl;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;

Each of the size overflow lines is followed by a 20-30 line stack trace dump.
But my server appears to be running fine, apps fine, cpu, memory all look fine.
I'm not sure if this is something to worry about.

Last edited by sylvite (2015-10-21 04:55:20)

nail · 2015-10-21 09:00:05

sylvite wrote:

Tried 4.2.3.201510200858-1, and back to up and running now.

Not sure if these are needed or helpful, but these appear to be related to the new CONFIG_PAX_SIZE_OVERFLOW_DISABLE_KILL flag. From journalctl--

Oct 20 23:37:45 x kernel: PAX: slow and weak UDEREF enabled
Oct 20 23:37:45 x kernel: PAX: slow and weak UDEREF enabled
Oct 20 23:37:45 x kernel: PAX: slow and weak UDEREF enabled
Oct 20 23:37:45 x kernel: PAX: slow and weak UDEREF enabled
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_do_math_op drivers/acpi/acpica/exmisc.c:414 cicus.45_57 min, count: 30, decl: acpi_ex_do_math_op; num: 0; context: fndecl;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_do_math_op drivers/acpi/acpica/exmisc.c:414 cicus.45_57 min, count: 30, decl: acpi_ex_do_math_op; num: 0; context: fndecl;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_do_math_op drivers/acpi/acpica/exmisc.c:414 cicus.45_57 min, count: 30, decl: acpi_ex_do_math_op; num: 0; context: fndecl;
Oct 20 23:37:45 x kernel: PAX: size overflow detected in function acpi_ex_opcode_1A_1T_1R drivers/acpi/acpica/exoparg1.c:319 cicus.62_197 max, count: 15, decl: value; num: 0; context: acpi_object_integer;

Each of the size overflow lines is followed by a 20-30 line stack trace dump.
But my server appears to be running fine, apps fine, cpu, memory all look fine.
I'm not sure if this is something to worry about.

You can send this logs here https://forums.grsecurity.net/viewforum.php?f=3 like others do, to help PAX Team enhance grsecurity.

Irok · 2015-10-21 10:06:25

The new update solved it in my computer

Last edited by Irok (2015-10-21 10:06:46)

blm · 2015-10-21 15:22:05

Same here. Thanks whoever fixed it!

...If you're reading this...

Arch Linux

#1 2015-10-17 19:29:27

linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#2 2015-10-17 19:33:27

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#3 2015-10-17 19:58:50

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#4 2015-10-18 07:28:03

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#5 2015-10-18 09:00:48

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#6 2015-10-18 16:48:17

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#7 2015-10-19 02:54:44

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#8 2015-10-19 08:09:13

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#9 2015-10-19 09:05:45

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#10 2015-10-19 09:12:22

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#11 2015-10-19 11:12:51

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#12 2015-10-19 11:48:45

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#13 2015-10-19 12:02:07

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#14 2015-10-19 21:26:43

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#15 2015-10-19 21:37:35

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#16 2015-10-20 01:08:43

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#17 2015-10-20 03:49:21

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#18 2015-10-20 10:49:26

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#19 2015-10-20 13:16:53

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#20 2015-10-20 14:02:54

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#21 2015-10-20 16:23:32

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#22 2015-10-21 04:42:02

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#23 2015-10-21 09:00:05

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#24 2015-10-21 10:06:25

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

#25 2015-10-21 15:22:05

Re: linux-grsec 4.2.3.201510161817-1 boot hangs on loading initramfs

Board footer