On Saturday, 19 December 2009 16:19:31 -0300, Daniel Bareiro wrote: > > > I assume that it must have differences between both kernels > > > versions; for that reason, as I've mentioned in another mail of > > > this thread, after to have copied the file, I followed a similar > > > procedure to which mentioned above, but with the ARCH=x86_64 > > > variable: > > > > > > # cd /usr/src/linux-2.6.32 > > > # cp /boot/config-`uname -r` ./.config > > > # make ARCH=x86_64 menuconfig > > > # make > > > > > > But in spite of to have used 'make menuconfig', 'make' did > > > 'restart config' beginning to do questions to me. > > If you are not running a 64-bit kernel, you have to specify > > ARCH=x86_64 for _all_ make invocations. > Well. I didn't know that there was to do it with all. Using the > following steps I was not interrogated: > > # cd /usr/src/linux-2.6.32 > # cp /boot/config-`uname -r` ./.config > > # make ARCH=x86_64 menuconfig > # make ARCH=x86_64 > # make ARCH=x86_64 modules_install > # make ARCH=x86_64 install > > > But when boot, the process is interrupted with the following message: > > request_module runaway loop modprobe binfmt-464c > > > It draws attention to me that this has not happened after compiling > after to have booted with amd64 kernel using the same environment (KVM > VM with host amd64). The unique difference in the process was the > aggregate of the ARCH=x86_64 variable with each invocation of make. Reading [1] and [2], I already found the cause of this problem. The configuration in "Executable file formats / Emulations" must be the following one in order to use a kernel x86_64 in userland 32. [*] Kernel support for ELF binaries [ ] Write ELF core dumps with partial segments <M> Kernel support for MISC binaries [*] IA32 Emulation <*> IA32 a.out support I didn't have this problem after to boot with kernel amd64 because to configure the new kernel I was based on the configuration of running amd64 kernel, in which these options already were setted of this way. Then, making an analysis of the tests that I was doing, I reached these results: a) Traditional compilation: a.1) Having booted an i386 kernel and userland 32: # make ARCH=x86_64 menuconfig # make ARCH=x86_64 # make ARCH=x86_64 modules_install # make ARCH=x86_64 install It does not present questions during "make" and it boots ok enabling the options mentioned above. a.2) Having booted an amd64 kernel and userland 32: # cp /boot/config-`uname -r` ./.config # make # make modules_install # make install It does not present questions during "make" and it boots ok. b) Debian way compilation: b.1) Having booted an i386 kernel and userland 32: # cp /boot/config-`uname -r` ./.config # make ARCH=x86_64 menuconfig # fakeroot make-kpkg clean --cross-compile - -arch amd64 # fakeroot make-kpkg --initrd --cross-compile - -arch amd64 \ --append-to-version=-dgb kernel_image kernel_headers It does not present questions during "make" and it boots ok enabling the options mentioned above. Another thing that I have noticed is that the packages are generated with a suffix i386, although after boot the kernel is x86_64: linux-headers-2.6.32-dgb_2.6.32-dgb-10.00.Custom_i386.deb linux-image-2.6.32-dgb_2.6.32-dgb-10.00.Custom_i386.deb b.2) Having booted an amd64 kernel and userland 32: # cp /boot/config-`uname -r` ./.config # make menuconfig # fakeroot make-kpkg clean # fakeroot make-kpkg --initrd --append-to-version=-dgb kernel_image \ kernel_headers After to execute this last line, the process starts but I begin to be interrogated again by configuration options. If in this environment (having booted an amd64 kernel an userland 32) I use the syntax mentioned in (b.1), I don't have this problem. It would seem to be that for some reason fakeroot make-kpkg finds a complete environment of 32 bits. Still using the syntax of (b.1) in this environment, I obtain the packages with a suffix i386 again. linux-headers-2.6.32-dgb_2.6.32-dgb-10.00.Custom_i386.deb linux-image-2.6.32-dgb_2.6.32-dgb-10.00.Custom_i386.deb Regards, Daniel [1] http://www.informaticien.be/index.ks?page=forum_topic&id=5388&index=0 [2] http://saalwaechter-notes.blogspot.com/2008/10/requestmodule-runaway-loop-modprobe.html -- Fingerprint: BFB3 08D6 B4D1 31B2 72B9 29CE 6696 BF1B 14E6 1D37 Powered by Debian GNU/Linux Lenny - Linux user #188.598
Attachment:
signature.asc
Description: Digital signature