grsecurity forums

We have tried grsec for kernel 2.6.14.7 with hardware RAID (IBM ServeRAID Controller).

Even with no option activated (but grsec and PaX activated), it kernel panics as if he didn't recognise disk controler : VFS: not syncing: unable to mount root filesystem or uknown block(0,0).

Does the same configuration with a vanilla kernel (not a distro-provided kernel) work? Generally these boot-time panics are due to invalid configuration of the kernel (missing some filesystem driver, device driver) or forgetting to change the bootloader configuration (if the distro normally uses LABEL=/ for booting instead of the harddisk device)

-Brad

Wy tried it with a vanilla kernel. With the same .config, if we do not apply Grsecurity patch, it boots. But if we do patch, even with all Grsecutiy options disabled, it panics.

Regards.

You can find more informations here :

http://people.via.ecp.fr/~pam/grsec/

Thanks.

VIA Centrale reseau wrote:We have tried grsec for kernel 2.6.14.7 with hardware RAID (IBM ServeRAID Controller).

Even with no option activated (but grsec and PaX activated), it kernel panics as if he didn't recognise disk controler : VFS: not syncing: unable to mount root filesystem or uknown block(0,0).

would it be possible to capture and post the boot log on serial console for both vanilla and the grsec kernel (just to see any differences that might give us a hint)?

originally i had this problem as well till i foolishly remembered you need to make an initrd image for the kernel to boot, mkinitrd -o /boot/initrd.img-grsec 2.6.12.5-grsec for example

oh, insert an initrd directive in your menu.lst accordingly (if your using grub)

We usually compile all the modules needed by the kernel to acces to / in the kernel, so we do not need any initrd. Actually, untill we tried with linux-2.6.14.7-grsec, it always worked without initrd, so I do not see why it could change anything.

Whatever, we will try it, and we will try to copy the kernel messages before it panics. Do you know if there is another solution than copying those messages by hand? I think dmesg only works if we have booted succesfully...

You need a serial console.

For a Howto read linux-2.6.14.6/Documentation/serial-console.txt or http://www.vanemery.com/Linux/Serial/se ... nsole.html

VIA Centrale reseau wrote:Whatever, we will try it, and we will try to copy the kernel messages before it panics. Do you know if there is another solution than copying those messages by hand? I think dmesg only works if we have booted succesfully...

besides the serial console there's also netconsole, see Documentation/networking/netconsole.txt for details.

We tried using a serial console. Of course, it can only be activated when switching to some runlevel, i.e. after the boot time, when neeeded drivers are loaded. So, we cannot give you all the kernel messages, because it panics during boot time.

With an initrd, it also panics. Actually, I do not see how using an initrd could change anything, because it works with the same kernel, no grsec-patched and the same config. Even if we just patch and do not activate grsec in the config, it panics.

VIA Centrale reseau wrote:We tried using a serial console. Of course, it can only be activated when switching to some runlevel, i.e. after the boot time, when neeeded drivers are loaded. So, we cannot give you all the kernel messages, because it panics during boot time.

uhm, not sure what you are doing but adding something like console=ttyS0,115200n8 console=tty0 to the kernel command line should enable the serial console very early during boot, way before userland starts up.

Okay, we did not understand it completely. We will try it and paste the kernel messages here.