• Home
  • Help
  • Search
  • Login
  • Register
Pages: [1]
Author Topic: Esata Kernel problems  (Read 1997 times)
peter a
Full Member
***

Karma: 0
Posts: 132


View Profile
« on: April 24, 2010, 09:24:14 AM »

Hi , having another go at installing the latest kernel with Esata support ,
Similar to before I`m still having problem, but this time I hope I’m a bit wiser in what’s happening.
 
O.k I`m running Debian as per :- http://Http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html
And compiled the kernel as per :- http://www.newit.co.uk/forum/index.php/topic,285.0.html

If I boot up from Esata it doesn`t load any modules ( Modules are there ) , but will boot and access the Esata port .
My workaround was don`t use modules build them into the kernel !!!

If I boot from the SD card it loads the modules, but I can`t get access to the Esata drive.

So how can I get access to the Esata drive while booting from the SD card , or why ,when I`m booting from the Esata port isn`t loading the modules .
Logged

peter a
Full Member
***

Karma: 0
Posts: 132


View Profile
« Reply #1 on: April 25, 2010, 05:55:59 AM »

I`ve found when I said that “boot from SD loaded the modules”, that was an uboot env error.
( it loaded my image with modules built in )

I`m going crazy with this one !!!!!

I just can`t get it to load the modules which I`ve compiled with the(m)
But :-
 Setting the system clock.
Cleaning up ifupdown....
Loading kernel modules...done.
Assembling MD arrays...failed (failed to load MD subsystem).
Checking file systems...fsck 1.41.3 (12-Oct-2008)
e2fsck 1.41.3 (12-Oct-2008)
/dev/mmcblk0p1: clean, 29/14112 files, 44137/56416 blocks
done.
Setting kernel variables (/etc/sysctl.conf)...done.
Setting kernel variables (/etc/sysctl.d/10-process-security.conf)...done.
Mounting local filesystems...done.

Oh well back to compiling all the modules back in the kernel I guess !!!!!!
Logged

peter a
Full Member
***

Karma: 0
Posts: 132


View Profile
« Reply #2 on: April 27, 2010, 02:36:19 AM »

IU think my problem is I don`t understand how it boots and which files I need :-

DO I NEED ALL OF THESE TO MAKE IT BOOT ?

/boot/config-whatever
/boot/initrd.img
/boot/whatever-uImage
/boot/System.map-whatever
/boot/uInitrd
/boot/vmlinuz-whatever

Any links so I can uderstand it would be helpfull

Thanks Peter
Logged

cjm
Jr. Member
**

Karma: 6
Posts: 69


View Profile
« Reply #3 on: April 27, 2010, 11:39:32 AM »

You only need uInitrd and uImage for u-boot. The modules are loaded by the kernel in two stages:

1) modules in the initrd image (uInitrd when using u-boot)
2) modules in /lib/modules/... after the root partition has been mounted

This implies that you need to have the modules for your root file system in the initrd image. The script mkinitramfs will create an initrd image with modules as it deems required for booting. This is partially automatic (looking at the driver used for the root partition and filesystem) but can be configured in /etc/initramfs-tools/initramfs.conf as well as with files in /etc/initramfs-tools/conf.d. On top of that, there's a file /etc/initramfs-tools/modules which contains a list of modules that must loaded, regardless of the modules that it guesses.

Another aspect worth mentioning is that modules have dependencies on each other and those are stored in /lib/modules/.../modules.dep and friends. mkinitramfs expects those files to exist and this might be a problem when cross-compiling a kernel -- I never tried that and build my kernels directly on the plug. The command "depmod -a" can be used to create the module dependencies.

On my plug, I use the following script to build a custom kernel and move the core kernels out of the way for the initramfs tools:

Code:
#!/bin/bash
version=2.6.32-cm1.1-kirkwood
echo building version $version

if [ $# -gt 0 -a "$1" == "-r" ] ; then
  # rebuild kernel
  make clean
fi

if ! make || ! make zinstall; then
  echo error: build failed....
  exit 1
fi

if [ ! -d /lib/modules/$version ] ; then
  mkdir /lib/modules/$version
fi

if ! make modules_install; then
  echo error: modules_install failed....
  exit 1
fi

if ! cd /boot || ! mkinitramfs -o /boot/initrd.img-$version $version; then
  echo "error: mkinitramfs failed...."
  exit 1
fi
ln -fs initrd.img-$version initrd.img

# Make this kernel known to update-initramfs. This is not exactly sufficient
# because update-initramfs will use "dpkg --compare-versions" to compare the
# versions of installed kernels and select the most recent one. Since our kernel
# has never been installed via dpkg and we don't exactly follow debian
# versioning rules (e.g. using "cm1.0" vs. "trunk"), we'll lose every time. But
# if we're the only kernel available, we'll win. We'll do this final step, i.e.
# making sure we're the only kernel, once we successfully flashed the kernel
# image further down. For now, just make sure update-initramfs knows about this
# new kernel
shasum /boot/initrd.img-$version >/var/lib/initramfs-tools/$version

if ! flash-kernel; then
  echo "error: flash-kernel failed...."
  exit 1
fi

# Everything went fine so far and the kernel has been installed; now disable
# other kernels in /var/lib/initramfs-tools to make sure further calls to
# update-initramfs will use our new kernel. Quite a hack but I never got around
# (or, in better words, bothered) to master the "official" zen of debian kernel
# compilation...
for i in /var/lib/initramfs-tools/*; do
  if [ "$i" != "/var/lib/initramfs-tools/$version" ] ; then
    rm $i
  fi
done

In order to use this script, extract the linux source into /usr/src/linux-<version>, change into the source directory, copy the Debian config file from /boot/config-<version> into .config, patch the kernel and/or update the configuration with make menuconfig, then run the script above to build and install the kernel.

This script is a bit of a hack but I never got around using the Debian kernel build tools and I also like having full control over the build process...

Thanks,
--Christian
Logged

peter a
Full Member
***

Karma: 0
Posts: 132


View Profile
« Reply #4 on: April 27, 2010, 02:44:52 PM »

Thank for the info Christian

So from what I can work out . what you are saying that my kernel may be correctly complied ,but I need to make a new version of uInitrd for each time I change the kernel and add the modules inside it.

I was not able to decompress the uInitrd file when I tried.
Logged

cjm
Jr. Member
**

Karma: 6
Posts: 69


View Profile
« Reply #5 on: April 27, 2010, 03:31:21 PM »

The short answer is "yes". initrd images are usually created/updated more or less automatically but if anything fails, debugging is a bit tedious.

Regarding the problem extracting the initrd image: uInitrd is an initrd image with a u-boot header. You won't be able to use gunzip and cpio to look at the contents unless you remove the u-boot header. In order to keep things simple, I would suggest to focus on the original initrd image:


$ cd /tmp
$ cat /path/to/initrd | gunzip | cpio -id


Logged

peter a
Full Member
***

Karma: 0
Posts: 132


View Profile
« Reply #6 on: April 27, 2010, 03:49:20 PM »

Someone came up this this :- cat /boot/initrd.img | gunzip | cpio -ivdm

I`ve had my look inside and WOW , it a lot more complex I imagined .
But I know why it`s not loading the FTDI modules and the IPv6 modules , Yep there not there.

Sorry to be a newbie , which I am , But is the initrd.img in the compiled source ?
Logged

cjm
Jr. Member
**

Karma: 6
Posts: 69


View Profile
« Reply #7 on: April 27, 2010, 07:21:15 PM »

The initrd image is created independentlly from the kernel build. It's basically a ramdisk with a bunch of modules required to boot plus some scripts and executables required to to get the system up an running. The main point is to load all modules required to access the root filesystem -- adapter driver modules, filesystem modules, etc. Once root has been mounted, the boot process continues without the initrd image and all memory associated with the ramdisk is released.

BTW, creating a kernel with all drivers required to mount the root file system compiled right into the kernel is perfectly legitimate -- initrd images are mainly used to allow distributions to adjust to different hardware environments without having to recompile the kernel.
« Last Edit: April 27, 2010, 07:28:17 PM by cjm » Logged

Pages: [1]
Print
Jump to: