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 http://ftp.de.debian.org/debian/ wheezy main contrib non-free
deb http://security.debian.org/ wheezy/updates main contrib non-free
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 ?
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
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.
First check and download any latest available kernel from The Linux Kernel Archives
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.
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!
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.
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.
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.
Question: has anyone attempted to install the liquorix kernel into an Elive installation?
Which prompts another question, in my mind: Is the default Elive kernel optimized in any manner similar to the liquorix kernel?
I ask because there is a noticeable difference between the optimized liquorix and the default kernel in almost every Linux Iâve installed. There are times when the machine just seems unresponsive, because it is tending to background things. With the liquorix kernel, priorities are shifted, so the machine remains responsive, at the possible expense of those background tasks.
This can be reviewed and implemented :), suggestions to add? this is also a delicated topic which requires a big betatesting, power usage is also an important point (battery usage, some options makes bigger usage of battery/power)
Not here but if you try, share your experience :), if package installing fails try to copy the inside files which can make it work (boot), but there may be dependency issues (like the required version of dbus/udev/filesystems-and-mountpoints/etc)
