HowTo: Build a 64bit kernel on Elive 2.99.9


#1

I’ve build a own 64bit kernel and it works.
My System was only detecting 2GB from the 10GB, not 4GB.

So, we need a complete /etc/apt/sources.list.d/debian.list:
deb http://ftp.debian.org/debian wheezy-backports main contrib non-free
deb Index of /debian wheezy main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free

then:

dpkg --add-architecture amd64

after this:

sudo apt-get update
sudo apt-get install libelf1:amd64 libelf-dev:amd64 ncurses-dev bison flex

Then, you can configure and compile your kernel.


#2

for newbies : how do you " Then, you can configure and compile your kernel. " ?
Will test what you’re saying as soon as I have all the " steps for dummies" LOL
Tks !
Yoda

@Thanatermesis any comments on this ? Are those the same steps you suggested to me in the past on the old forum ?


#3


#4

I did all of the above but don’t know how to
Then, you can configure and compile your kernel.


#5

There’s no “for dummies” possibility in compiling kernels lol, it is a complex thing… in old times when linux was more hard to use, compile a kernel was “just another common thing” but today sounds like a very complex thing to do lol

you can try to google a howto “compile linux kernel easy way” or “for dummies” to see what results exists around


#6

LOL won’t try tks
JF
Will wait that it is 64 if it’s not simple to do as 1-2-3


#7

Bit late in reacting but the following guide is i.m.o fairly simple and doable. It’s from quora by Vivek Pawnar.

Please follow below steps for building, configuring your own Linux kernel.

  1. First check and download any latest available kernel from The Linux Kernel Archives
  2. Change to the directory where the file was downloaded and extract using below, It should contain folders called arch, fs, crypto, etc.

tar xf linux-x.y.z.tar.xzcd linux-x.y.z

Configuring and Compiling:
Before compiling the kernel, we need to configure which modules are to be included and which ones are to be left out. An easy and straightforward way to do this is to first copy your existing kernel config file and then use ‘make menuconfig’ to make changes (if necessary). This is the fastest way to do it and probably, the safest. Please use below commands:

cp /boot/config-$(uname -r) .config make menuconfig

This is the part where you could end up removing support for a device driver or do something of the sort which will eventually result in a broken kernel. If you are unsure about making changes, just save and exit.
To compile the kernel and its modules, we use the “make” command. This is followed by using “make modules_install” to install the kernel modules.
Finally, we use “make install” to copy the kernel and the .config file to the /boot folder and to generate the system.map file (which is a symbol table used by the kernel contain declaration of all kernel functions).
These three steps put together usually take up a lot of time. Use the following command to perform the above tasks:

sudo make -j 4 && sudo make modules_install -j 4 && sudo make install -j 4

Note: I have used the -j option to specify the number of cores to be used. This tends to speed up the process considerably. You can use “nproc” to check the number of processing units available.
Final steps replace existing kernel with new one:
Once the kernel and its modules are compiled and installed, we want to be using the new kernel the next time we boot up. For this to happen, we need to use the following command:

update-initramfs -c -k x.y.z.1

Then, use the following command, which automatically looks for the kernels present in the /boot folder and adds them to the grub’s config file.

update-grub

Now, restart the system and you should see that the new kernel is added to the boot loader entries.
On following the instructions, assuming there’s enough space available on disk and the current kernel configuration works fine, you shouldn’t encounter any problems. Note that you could always use the old kernel version in case of any problem and try the whole thing again!
The command “uname -r” should now show you the current kernel version being used.


#8

I totally agree with @Thanatermesis on this topic. But because this question will pop up in every forum, I’ve write a little ‘how to kernel and debian without big changes’ some days ago (2006).
https://www.lupuse.de/linux/quick_n_dirty/kernel_debian

This is the base for any patching direct in the kernel source. Of course you could use the debian kernel-source packages as well. But where is the fun? (A little secret: I am not using /etc/src as Destination!)

A quick translation:

\\ Install development packages 
# aptitude install wget bzip2 kernel-package tk8.4-dev kernel-package libncurses5-dev binutils bin86 make fakeroot

\\ Give the needed permission for /usr/src to the user  ... 
# adduser [user] src 
\\ ... then logout/login with the user!

\\ Get the Kernel, move, extract, symlink, configure
$ cd /usr/src;
$ wget ftp://ftp.de.kernel.org/pub/linux/kernel/v2.6/linux-<version>.tar.bz2;
$ tar xfvj linux-<version>.tar.bz2; \ ln -s linux-<version> linux;
$ cd linux; 
$ make menuconfig

\\ Here is the magic beginning.
\\ For starters it could help to load the defaults
\\ On the very bottom of 'make menuconfig' is the point: Load an Alternate Configuration File
\\ Here you cloud choose the running config from /boot/config-<version> (see 'ls /boot/')

\\ Build the kernel as .deb Package
$ fakeroot make-kpkg kernel-image --revision=<hostname>1.0
\\ ... install the new kernel ...
# cd .. ; dpkg --install linux-image-<version>_<hostname>_i386.deb
\\ ... start the new kernel
# shutdown -r now
\\ check if the right kernel is started
$ uname -a Linux <hostname> <version> #1 Mon Sep 12 21:04:19 CEST 2005 i686 GNU/Linux 

\\ good luck!

\\ You could add and remove modules in your running kernel without a reboot.
# cd /usr/src/linux
# make menuconfig
\\ Select or unselect the wanted module.
# make modules modules_install && depmod -a 
# modprobe <$module>
\\ But keep in mind, the changes are not in the  linux-*.deb!

#9

Hmmm, bear in mind that the reference was to the hardships expected with “configure and compile your kernel” after enabling amd64 architecture builds.
So maybe you should be more clear as to what arch packages (not i386.deb) you are referring to. Admittedly an amd64 kernel will have other and newer modules and require a tad of tweaking on current elive. :wink:


#10

You are right, I’ve only used this from one version to another in the same $ARCH. But even here, for the new modules the defaults will be set. So I’ve never experienced any problem. (Beside the Slab-Slurb change for USB in 2.4 Kernels … But this is a different sorry).
I expect the same behavior in using a 32-bit config for 64-bit building. Even if I won’t change the Kernel Version in this case. 2 dimensional changes are harder to debug.

I bear in mind ‘why not using 32-bit kernel with PAE?’ (PAE -> Physical Address Extension). Here the system is able to map more than 3,2 GB of RAM within 32-bit registers.
As I wrote in another place in this forum, I can’t imagine anything that is desperately need 64-bit, today. The more often case is to user 32-bit packages on 64-bit systems.
If Thanatermesis got enough volunteers, they are interested in 64-bit Elive, I see a change. Until than I totally understand his way of only support 32-bit.


#11

Agreed on the 32bit choice, though there are 64bit-only apps out there in the wild. My point was primarily that things were getting off-(amd64)-topic.and might make things unnecessarily complicated.


#12

Since this is related to the 64 bit topic, what do you* think about this post idea?


#13

I have to think about it… Bit, it wouldn’t hurt to " try " ?
JF