Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I need to rebuild the Centos-6 / elrepo 3.10.19 kernel from source.

Background: the GVision touch screen drivers are incompatible with kernels > 3.8 and require source code patches to add code to avoid conflicts with their touchscreen drivers. My first step is to build an unmodified driver from source that works before I try to apply the GVision patches.

When I build the kernel as noted below, the kernel fails to boot properly with (hand typed!):

Kernel panic - not syncing: Attempted to kill init! exitcode=0x000000100
<some register dumps>
dump_stack
panic
remote_function+0x38/0x40
find_new_reaper_0x512/0x160
forget_original_parent+0x34/0x250
perf_cgroup_switch+0x160/0x160
exit_notify+0x16/0x120
do_exit+0x1b4/0x400
do_group_exit_0x3e/0xb0
SyS_exit_group_0x3e/0xb0
sysenter_do_call+0x12/0x28
drm_kms_helper: panic occurred, swithcing back to text console

Here how I built the kernel guided by https://fedoraproject.org/wiki/BuildingUpstreamKernel

Get config file elrepo used:
- First, get the config files that were used to build the elrepo kernel
- - wget http://elrepo.org/linux/kernel/el6/SRPMS/kernel-t-3.10.19-1.el6.elrepo.nosrc.rpm
- - rpm -i kernel-lt-3.10.19-1.el6.elrepo.nosrc.rpm
The key thing that you want from here is rpmbuild/SOURCES/config-3.10.19-i686
Next, get the kernel source
- wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.19.tar.xz
Change perms on /usr/src/kernels
- chmod o+w /usr/src/kernels

Then, as non-root
- cd /usr/src/kernels
- tar xJf ~/linux-3-10-19.tar.xz
- cd linux-3-10-19
- copy the config file from the rpmbuild/SOURCES/config-3.10.19-i686 to ./.config
- edit the Makefile to make a unique kernel name with an extesion in the variable "EXTRAVERSION"
- make bzImage && make modules

As root
- make modules_install
- make install

This all completes cleanly

In /boot, the original and newly build vmlinuz and System.map are the same file size (but different md5sum) and the newly built initramfs is much smaller.

drwxr-xr-x 3 root root     1024 Nov 11 18:23 boot
-rw-r--r-- 1 root root   142933 Nov 12 23:22 config-3.10.19-1.el6.elrepo.i686
drwxr-xr-x 3 root root     1024 Aug  5  2011 efi
drwxr-xr-x 2 root root     1024 Nov 14 20:07 grub
-rw-r--r-- 1 root root 16589977 Nov 14 14:16 initramfs-3.10.19-1.el6.elrepo.i686.img
-rw-r--r-- 1 root root  4645843 Nov 14 20:07 initramfs-3.10.19-MDV1.img
drwx------ 2 root root    12288 Aug  5  2011 lost+found
-rw-r--r-- 1 root root   254858 Nov 12 23:23 symvers-3.10.19-1.el6.elrepo.i686.gz
lrwxrwxrwx 1 root root       29 Nov 14 20:06 System.map -> /boot/System.map-3.10.19-MDV1
-rw-r--r-- 1 root root  2342208 Nov 12 23:22 System.map-3.10.19-1.el6.elrepo.i686
-rw-r--r-- 1 root root  2342208 Nov 14 20:06 System.map-3.10.19-MDV1
lrwxrwxrwx 1 root root       26 Nov 14 20:06 vmlinuz -> /boot/vmlinuz-3.10.19-MDV1
-rwxr-xr-x 1 root root  4868224 Nov 12 23:22 vmlinuz-3.10.19-1.el6.elrepo.i686
-rw-r--r-- 1 root root  4868224 Nov 14 20:06 vmlinuz-3.10.19-MDV1

What step am I missing?

==== Solved ====

The key problem here was the initramfs that I generated was missing lots of material that was in the original elrepo distributed initramfs. As @terdon pointed out something is missing in there that is obviously essential to a successful boot.

I don't know why the initramfs created by "make install" didn't work -- I didn't dig into that.

To recreate the initramfs:

cd /boot
dracut -f initramfs-3.10.19.el6.elrepo.i686-MDV1.img 3.10.19.el6.elrepo.i686-MDV1

With the new initramfs, this kernel boots cleanly.

While digging into this I found that the config file in /boot was exactly the same as I had pulled from the elrepo archive so the wget for the elrepo config file can be eliminated.

With a clean process to build from source, I was able to apply the source code patches to make the GVision touch screen work. The GVision instructions are a bit confusing, and in some places incorrect, and I've provided feedback to the vendor to update their documentation.

share|improve this question
1  
The important bits are likely before the kernel panic. Most of time I have seen this it's due to something missing from the initramfs (such as missing the driver required to mount /). –  jordanm Nov 15 '13 at 4:07

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.