How to compile the kernel?

[Graf_Koks]

Hi,

I would like to compile kernel 3.9.11 to add additional modules to precise puppy.

I loaded the corresponding devx.sfs and followed

http://puppylinux.org/wikka/CompilingKernel

However, step

Code: Select all

make modules_install

gives some warnings - I guess this is ok - but step

Code: Select all

make install

fails with

Code: Select all

sh <bla>/linux-3.9.11/arch/x86/boot/install.sh 3.9.11 arch/x86/boot/bzImage \
                System.map "/boot"
<bla>/linux-3.9.11/arch/x86/boot/install.sh: line 49: /boot/vmlinuz: No such file or directory
cp: cannot create regular file `/boot/System.map': No such file or directory
Cannot find LILO.

maybe because I am compiling on a different partition (with <bla> being the path) since my puppy partition has only 512M.

How do I go on correctly? It seems that I have to exchange the old vmlinuz file with the new one and then I have to do something with LILO. But is LILO used on puppy?

Thanks in advance for help

[Graf_Koks]

This tut is based on the description of aaa3 (http://murga-linux.com/puppy/viewtopic.php?t=32186) and describes how to compile additional kernel modules for encryption. It concentrates on installing xts.ko, other modules work analogously (actually each cryptographic module is compiled).

Prerequisites:

(0) this is for precise puppy 5.7.1;
(i) it is assumed that sudo rights are necessary for important steps;
(ii) it is assumed that data is stored on a second partition: /mnt/<device>/home/<user>/<workingdir>,
(a) <device> = something like sda1,
(b) <user> = your name on the second partition, e.g. john,
(c) <workingdir> = some directory, e.g. stuff,
might be necessary that you mount this partition in the first place;
(iii) download devx_precise_5.7.1.sfs from http://distro.ibiblio.org/quirky/precise-5.7.1/ and store it below /mnt/sda1/home/john/stuff;
(iv) download kernel_src-3.9.11-patched.sfs from http://bkhome.org/sources/kernel-3.9.11/, use "puppy" and "linux" for login and store the file below /mnt/sda1/home/john/stuff;
(v) install cryptsetup using the package manager for being able to encrypt something.

Loading sfs-files:

Open a terminal.

Code: Select all

sudo sfs_load

Select /mnt/sda1/home/john/stuff/devx_precise_5.7.1.sfs and press the "load"-Button. When the messages appears, that the file should be located somewhere else, press "No". When you are questioned if the application should be run, press the "run"-Button. Do it again:

Code: Select all

sudo sfs_load

You will see that the first file was loaded. Select /mnt/sda1/home/john/stuff/kernel_src-3.9.11-patched.sfs and do the same as described before.

Copy sources to the right place:

Code: Select all

cd /usr/src
sudo mkdir /mnt/sda1/home/john/stuff/usr/src/
sudo cp /usr/src/* /mnt/sda1/home/john/stuff/usr/src/ -Rf
cd /mnt/sda1/home/john/stuff/usr/src/linux

Preparing the kernel:

Code: Select all

sudo make menuconfig

Select "Cryptographic API" and press enter. Select each unselected line and press "m" so that "< >" turns to "<M>". If everything is selected, select "Exit" at the bottom and press enter. Do it again. If you are asked for saving select "yes".

Building the kernel:

Code: Select all

sudo time make -j <number of cores of your machine>

The -j parameter will speed compiling up. time will return duration of compiling. Get a coffee.

After compiling has finised:

Copying the modules to the right place:

Code: Select all

cd crypto
ls *.ko

shows you all cryptographic modules.

Code: Select all

sudo cp gf128mul.ko /lib/modules/3.9.11/kernel/crypto/
sudo cp xts.ko /lib/modules/3.9.11/kernel/crypto/

The first module is needed for xts to work.

Code: Select all

sudo depmod -a
sudo modprobe gf128mul
sudo modprobe xts

Testing xts:

Code: Select all

cd /root/my-documents
dd if=/dev/zero bs=1M count=64 of=container.img
sudo cryptsetup luksFormat -c aes-xts-plain64 -s 512 -h sha512 container.img

If there is no error until this point, excellent. Insert some passphrase (do not forget).

Open the container:

Code: Select all

sudo cryptsetup luksOpen container.img container

Create a file system:

Code: Select all

sudo mkfs.ext4 /dev/mapper/container

Create a mountpoint:

Code: Select all

sudo mkdir /mnt/container

Mount the encrypted container:

Code: Select all

sudo mount /dev/mapper/container /mnt/container

And finally, after

Code: Select all

cd /mnt/container
ls

you sould see:

Code: Select all

lost+found

Removing the mounted container works the otherway around:

Code: Select all

sudo umount /mnt/container
sudo cryptsetup luksClose container
sudo rm /mnt/container -Rf

[Karl Godt]

LILO is the LI nux LO ader -- a bootloader .

Puppy uses Grub -- The LILO warning is ignorable .

Of course , a frugal installation might not have a /boot directory .
That may make cp fail .

Otherwise your Compilation failed at the last steps .

Kernel 3.13.11 was compiling 4 times for six hours or something using one thread of 2 Cores a 1800MHz with each 2 Threads a 900Mhz ..
And then at the final stage failed to link in Memory related functions or whatever into vmlinuz directly .

My DOTconfig for 3.5.0 was not working .

Finally had to select

~ # modprobe -v configs
~ # zcat /proc/config.gz | grep -E 'SLAB|SLUB'
CONFIG_SLAB=y
# CONFIG_SLUB is not set
CONFIG_SLABINFO=y
# CONFIG_DEBUG_SLAB is not set
CONFIG_FAILSLAB=y

for
~ # uname -r
3.13.11-KRG-iATOM-2

something like this .

But this has no AUFS or UNIONFS driver -- so just a Full install kernel .

Am not paranoid -- but

~ # modprobe -l | grep crypt
kernel/crypto/crc32.ko
kernel/crypto/xts.ko
kernel/crypto/ccm.ko

# modprobe -l | grep gf
kernel/crypto/gf128mul.ko

are there ..

Happy snorkeling ..

[aaa3]

nice thread & guide, i'd like to add just 2 things,
it might have been forgotten to be mentioned, that if no

Code: Select all

sudo pkill udev

is done, cryptsetup may still fail,
and that if someone is fine with the kernel version provided, and just wants more modules, then while the full compile still seems to be needed, he can ignore the resulting vmlinuz and any warnings related to them, because the default kernel is already capable of useing them out of the box. (i have read here just a few days ago that a few years ago it wasnt the case and puppy was very hard to use with 3rd-party programs due to a stripped kernel but im sure its not the case anymore). oh, and as i wrote, the new version files (modules.dep, modules.symbols) need to go to /lib/modules/3.9.11/, not just the *.ko-s.

p.s.: ah, and i didnt like the wikka tut (seems more complex and scary than the real process is with the two sfs-es): i'd be careful with (i.e., read "would never in my right mind run!")

Code: Select all

make <*>install

, as it might almost irreversibly contaminate my savefile with a huge untrackable list of new files.

(i prefer creating a temporary folder, then a folder hierarchy in it as it would be seen from the root, copy everything you decide to need into there, and run

Code: Select all

dir2sfs .

launched from there to have it manually packaged.)

[aaa3]

and other security remarks: a full install (for which make install, and /boot is relevant) is, imo, losing a layer of quasi-defence with not being loaded from an inconvenient-to-change (i.e., infect) sfs file, while still running root (for most users at least, i know not for GK)

and setting a strong (ten second) cryptsetup key stretching time with

Code: Select all

--iter-time 10000

might be seen as more important than specifíing anything else: strength bits (256x2 & 512) (it is said that their halves are still ways overstrong for decades, yet easier on old hardware; on the other hand, quick bruting the passes is an already and ever increasingly extremely relevant vulnerability... common thief-level)...

[Graf_Koks]

Additonally, to what aaa3 said:

Always backup your puppy save file (i), or make an image of your puppy partition (ii)!
(encrypted of course)

(i) this is trival, simply copy it to some external device;
(ii)

Code: Select all

dd if=/dev/<puppy partition> of=<path to backup>/puppy.img 

should do it with <puppy partition> = s.th. like sdb1 and <path to backup> = e.g. /mnt/container from above (provided that the container is large enough).

Do this once a month or so, it will spare you a lot of time and headache.