# tweaking your kernel /without/ changing everything else

## D-LINC

I  needed to rebuild my kernel (same version) because I accidentally left out iptables support (yes, and I'm not sure how...) I wanted to pass in the correct options to Genkernel so that I would be able to bring up menuconfig, but all the options would be the same as they were before. I thought genkernel --no-clean --menuconfig all would work. But when I got into menuconfig I saw that half of the options had been changed from [*] to [M]. (@#$!!!) So, what are the correct flags to pass in?

----------

## golagoda

Look in /etc/kernels for your old config file (or anywhere else it might be, genkernel copies it there by default) that you used then pass the flag --kernel-config=/path/to/config to genkernel.

----------

## Hu

Running make menuconfig does not do the changes you describe.  It sounds like either a genkernel problem or you picked up the wrong starting .config on your second build.

----------

## D-LINC

On a related note: those of you who don't use Genkernel: do you manually put together your own initramfs? Or do you use some tool for that? (E.g., for LVM or RAID mounting during boot.)

----------

## NeddySeagoon

D-LINC,

Whats Genkernel ?  :)

You don't need an initrd for root on raid - yet. You do for root in lvm, as you need the userspace tools to start lvm.

Its fairly easy to make an inirtrd for raid and lvm.  It only gets messy if you need it to load kernel modules, then you have to remake it for every kernel.

The is a good HOWTO leave out the bits of the initrd you don't need.

You  only need the initrd bit.

----------

## D-LINC

 *NeddySeagoon wrote:*   

> D-LINC,
> 
> Whats Genkernel ?  
> 
> You don't need an initrd for root on raid - yet. You do for root in lvm, as you need the userspace tools to start lvm.
> ...

 

Hey Neddy, I've been following the HOWTO you linked me to, but I'm having some trouble: vgscan and vgchange aren't able to find my volume group. (Which contains the root LV.) The kernel/initramfs from genkernel is able to access it just fine, but the kernel/initramfs I've built myself claims it can't find any volume group.

I used the init script provided in the HOWTO, except I commented out the RAID parts, and I edited the VG name to match my own. I copied the files /dev/sda, /dev/sda1, and /dev/sda2 into the dev folder of the initramfs. (/dev/sda2 is the VG and contains the root LV.) I inserted more sleep statements into the init script so I could watch what is going on, and it appears as though every command in the init script is running. But since vgchange is not able to mount my VG, then I don't have a root LVM and so the other commands are unable to mount the root file system or chroot into it.

Do you have any idea why vgchange/vgscan wouldn't be able to detect the volume group?

(If it makes a difference, I'm using a hardened kernel.)

Here is the initramfs contents:

```
.

|-- bin

|   |-- busybox

|   |-- cat -> busybox

|   |-- lvm

|   |-- mount -> busybox

|   |-- sh -> busybox

|   |-- sleep -> busybox

|   |-- switch_root -> busybox

|   |-- umount -> busybox

|   |-- vgchange -> lvm

|   `-- vgscan -> lvm

|-- dev

|   |-- console

|   |-- mapper

|   |-- null

|   |-- sda

|   |-- sda1

|   |-- sda2

|   |-- urandom

|   `-- vc

|-- etc

|   `-- msg

|-- init

|-- newroot

|-- proc

`-- sys

8 directories, 18 files
```

Here is the init script:

```
#!/bin/sh

mount -t proc none /proc

CMDLINE=`cat /proc/cmdline`

mount -t sysfs none /sys

#wait a little to avoid trailing kernel output

sleep 5

#If you don't have a qwerty keyboard, uncomment the next line 

#loadkmap < /etc/kmap-fr

#raid

#/bin/mdadm --assemble /dev/md2 /dev/sda2 /dev/sdb2

#If you have a msg, show it: 

cat /etc/msg

sleep 5

#dm-crypt

#/bin/cryptsetup luksOpen /dev/md2 vault

#lvm

/bin/vgscan

sleep 5

/bin/vgchange -ay

sleep 5

#root filesystem

mount -r /dev/mapper/vg0-root /newroot

sleep 5

#unmount pseudo FS

umount /sys

umount /proc

sleep 5

#root switch

exec /bin/busybox switch_root /newroot /sbin/init ${CMDLINE}
```

I've tried switching back and forth between /bin/vgchange -ay and /bin/vgchange -ay vg0 thinking perhaps it might make a difference if I didn't specify the name of the volume group, but the results are the same.

----------

## D-LINC

Gahh! I realized that I build all the LVM stuff in the kernel as modules instead of built-in.

*beats head against wall*

Why does vgscan only tell you that it can't find a volume group, when it doesn't even have the ability to look! An error message like "um... the kernel doesn't even have LVM support" would be a lot more helpful.

Rebuilding the kernel now...

----------

## Hu

You may need to find your physical volumes before you can determine what volume groups are on them.  You are missing a pvscan.

----------

## D-LINC

Still no luck. Reinstalled the kernel and followed Hu's suggestion. pvscan is not detecting any physical volumes either.

 :Exclamation:   :Question:   :Exclamation: 

I wonder if there is something wrong with the device files...? Isn't devfs supposed to be mounted or something? (I don't see that in the tutorial provided init script.)

----------

## NeddySeagoon

/dev should be static.

You did use cp -a ?  

thats key as you need to preserve the dev special nature of the files.

I won't be back at a system with lvm for s week.

All I can say is it works for me on hardened, which is no help to you at all :(

----------

## Hu

If I recall correctly, the automatic mounting of devtmpfs occurs only if you do not use an initrd.  If you use an initrd, then you need to mount devtmpfs yourself.  I prefer this over using a static initrd dev.  Add the line mount -n -t devtmpfs devtmpfs /dev right after you mount /proc.

----------

## D-LINC

I'm still working on this problem. I got devtmpfs to work; it is populating /dev with a whole bunch of files, but not any of the sda* files. For this reason, I'm thinking that this issue must have something to do with SATA drivers, but also because when I was using the static dev directory (and adding my own sda* block files), I tried inserting an fdisk -l /dev/sda into the init script, and it couldn't read the disk.

I thought I had all the relevant SATA drivers enabled in the kernel, but perhaps I missed something. Is there some way to grep dmesg output or read a proc file to find out exactly what brand of SATA controller my system has, or what kernel module it uses?

----------

## Hu

If you have a LiveCD that can use the disk, then lspci -k will show you what kernel driver it is using.  You can also inspect the dmesg output of that CD to try to learn more about the drive.  I would expect that the kernel that fails to use the drive will have little or nothing about the drive in its dmesg.

----------

## D-LINC

It would (appear) that everything is now working. lspci -k showed me the correct driver, which it so happens was being built in the kernel as a module rather than static. (Why am I even using modules...?) Rebuilding the kernel fixed that core problem, though I also discovered there were some typos in the mount locations in the init scripts, but that was fixed quickly enough. Also had to deal with the error PTY allocation request failed on channel 0 which showed up when I tried to login over SSH. I had to add this to the fstab:

```
none         /dev/pts   devpts      defaults   0 0
```

The system boots up now, and so far there are no other significant problems.

----------

