Home » forums » Debian Help Forums: Users Helping Users » Kernel Issues

Root filesystem for new kernel

Tags:

Hi all

What are the minimal requirements for files/directories/programs on empty ext2 filesystem to boot new kernel (very, very basic kernel) in the simplest way? I need to avoid init process and all these scripts. I want it for testing some kernel configs.

my GRUB:
root (hd1,0)
kernel (hd1,0)/boot/bzImage init=/bin/bash root=/dev/hdb1
boot

I get Kernel panic: couldn't find /bin/bash, try init=

Of course there is /bin/bash on hd1,0. I can find it even in Grub cmd: cat /bin/bash. So I guess there are some lacks on my partition (I've created those basic dirs like: bin, dev, etc, boot..etc)

Also tried qemu. No luck.

Bookmark/Search this post with:
  • Delicious
  • Digg
  • StumbleUpon
  • Propeller
  • Reddit
  • Magnoliacom
  • Newsvine
  • Furl
  • Google
  • Yahoo
  • Technorati
0
‹ Loading uhci-hcd module confuses Trident graphics card Kernel 2.6 config for Xeon 5100 ›

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Root filesystem for new

Submitted by pinniped on Mon, 2007-07-30 18:40.

Some drivers need to be compiled into the kernel rather than as a module. Which drivers depends on your particular hardware; you can spend many hours making a list and getting it right. The not-so-hardware-dependent items are:

1. CONFIG_EXT2_FS (you may also want to compile some other ext2 options, if you use them, like extended attributes)
2. CONFIG_BLK_DEV_FD (floppy drive support)
3. CONFIG_BLK_DEV_LOOP (udev init script may fail if you don't do this)
4. The tmpfs and other pseudo-fs stuff:
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=y
5. IDE stuff:
CONFIG_IDE
CONFIG_BLK_DEV_IDE
CONFIG_BLK_DEV_IDEDISK
6. SCSI/Pseudo-SCSI stuff: (whether you need it or not depends on how you want your system to run)
CONFIG_SCSI
CONFIG_SCSI_PROC_FS
CONFIG_RAID_ATTRS
CONFIG_BLK_DEV_SD
CONFIG_CHR_DEV_SG
7. RAIDCONFIG_MD
CONFIG_BLK_DEV_MD
CONFIG_MD_LINEAR
CONFIG_MD_RAID(0,1,456,10)
8. SATA - ok I'm getting lazy to find the config parameters

And now for the fun part - you need to identify the chipsets in your system, find out what functions you need activated at boot time, and find their drivers so you can compile them into the kernel. For example, if you need SATA support then you need to identify your SATA controller and any chipsets which are part of the interface chain and make sure drivers are compiled for them. Usually that means grepping the kernel source for names, models, IDs, etc.

»

Root filesystem for new

Submitted by m4mach on Tue, 2007-07-31 05:47.

thanks for reply

I think that there is no kernel problem itself. I've compiled all drivers and all support for fs into the kernel (even more than needed). Besides I've tested this kernel with my main file system (from Debian dist) It works fine, lsmod shows nothing, no ramdisk all internal, only bash.

I think that the kernel can't access to the root filesystem on my second hard disk or it thinks that it is a ramdisk and fails.

Do you know if there should be any files (like /dev/*) on the rootfs A to start the kernel with root=A option?? Or maybe the kernel is able to create all files alone?

»

Root filesystem for new

Submitted by pinniped on Tue, 2007-07-31 06:29.

The kernel never creates device nodes on its own. You need to create a device node for hda/hdb (and others if you want your CD to work!) in your root filesystem:

cd /dev
mknod hda b 3 0
mknod hda1 b 3 1
mknod hda2 b 3 2
mknod hda3 b 3 3
mknod hdb b 3 64
mknod hdb1 b 3 65
mknod hdb2 b 3 66
mknod hdb3 b 3 67

Or something similar - Read the Documentation/devices.txt for more information about what the expected major/minor numbers are. In the future this may become obsolete - the driver model is currently able to assign arbitrary major/minor numbers to any device and a few device drivers already use this dynamic allocation. But that will be a long way in the future - all the current drivers need some work to really convert them to the current driver+udev model.

The way udev works is something like this:
1. You have a /dev directory with 'console' and 'null'; if you're not using an initram image then you also need entries for your partitions.
2. The udev start script temporarily remounts /dev in a safe place
3. udev script mounts a 'tmpfs' over /dev
4. udev script loads a few essential modules, creates nodes for essential devices which do not automatically create nodes, 'replays' events to automatically create nodes for drivers compiled into the kernel, and then creates nodes to match what's in the (temporarily remounted) old /dev.

If you don't run udev, no nodes will be created at all; you will only have the few that you manually created. Internally the drivers generate an 'event' which udevd is meant to catch and use to create the device node - no udev, no nodes.

»

Root filesystem for new

Submitted by m4mach on Tue, 2007-07-31 08:26.

So I understand that in my situation there is no any udev help, assuming udev works after kernel boots and it is not a part of the kernel itself.

Ok I've copied all /dev/* files from Debian rootfs to my new fs, guess what, no change...

To make it clear: Does kernel fail if there is a device it detects (apart from /dev/hd*) but there is no block file equivalent in /dev ? Assuming that the device is not needed for running simple app like bash?

All I want is to boot the KERNEL, mount empty (or almost empty) file system in the root directory, then launch BASH. Something alike the base for "my first simple distro". Till now I can do the first two stages without error, running anything from / causes kernel panic. Now I'm out of ideas...

»

Root filesystem for new

Submitted by pinniped on Tue, 2007-07-31 17:01.

You can clean up your Grub entry - you have specified root twice; you should be able to remove the root=/dev/hdb1.

The kernel will not fail just because there is no entry in /dev/hd* - not having a device node just means that no one can use the device.

Are you booting with 2 HDs, or did you unplug one?

Also, if you built bash with shared libraries, you need the runtime linker/loader and libraries to be available. For example, on my system:
ldd /bin/bash
libncurses.so.5 => /lib/libncurses.so.5 (0x00002adbf6a17000)
libdl.so.2 => /lib/libdl.so.2 (0x00002adbf6c73000)
libc.so.6 => /lib/libc.so.6 (0x00002adbf6e77000)
/lib64/ld-linux-x86-64.so.2 (0x00002adbf67f9000)

If you're missing a library or the loader then a shared bash cannot run and you will get that kernel message.

Look carefully at your messages; if there is no message about "cannot mount the root partition" then your problem is not with the HDs but probably with bash itself.

The LFS project is also useful: www.lfs.org. If you really want a minimal system, you should look at the 'clfs' project which is linked from that site. If you're just copying things from your Debian root, then you can make a copy of your initrd image somewhere and unpack it to see what's been included. If even that has too many things in it, then you need to look at the dependencies of all the tools you want using 'ldd' and copy them to the correct locations on your bare root partition. If you're trying to trim the kernel for embedded applications then Debian is a very bad place to start; I tried trimming Debian, then had a look at embedian, and ultimately went for clfs.

»

Root filesystem for new

Submitted by m4mach on Wed, 2007-08-01 06:11.

Thanks, you helped me a lot!

Quote:
Are you booting with 2 HDs, or did you unplug one?
yes, 2 HDDs. but I've tried USB pendrive and disk image also.

The problems are these libraries, manual copying is not the solution. I think I will have to install it into the embedded rootfs, but I don't know how and what to install. Can you tell me if I can install only these libs libc.so.6 and libncurses.so.5 from source? Because I don't want to install too much (too many MBs) it should be simple.

greetings

»

Root filesystem for new

Submitted by pinniped on Wed, 2007-08-01 08:23.

If you know what you're doing it takes most of the day just to set up to build the compiler set etc. for an embeded system. If you're only playing with the kernel on the same machine or the same class machine (for example, both Pentium M), I suggest you read on how to unpack the initrd image and use that.

There is no reason why you shouldn't be able to simply copy the necessary libraries and the linker/loader. Just remember for every library and executable you use, you need to check the dependencies and copy those files as well. This is why it's easiest to copy the contents of the initrd image to use as a basic root filesystem.

If you're really working with an embedded system then you should read the LFS and CLFS documentation - it will take at least a few days of reading before you can really start to work. I have been building a system for an embedded instrument and it took over 2 months of work, but I had taken the time to automate the entire process so now I can rebuild the entire system in around 40m. (This system is on a 366MHz Geode, boots in 8s, and provides pppd, ssh and many other tools in around 23MB.)

If you want to copy only a single file, then you can compile bash with static linking - no more need for the dynamic loader and separate libraries. In fact if you build bash from source you may be able to remove other dependencies such as 'ncurses' (but of course you have fewer features then). In this case I'd suggest you get the source; one way to do it is:
apt-get source bash
which will download the source, unpack it, and patch it in the current directory. You can then spend the next few hours reading the documentation and the build files and figuring out how to compile it and trim out all unnecessary parts (and perform the static link).

»

Root filesystem for new

Submitted by m4mach on Wed, 2007-08-01 09:50.

As you said I'm only playing with my kernel, but I want to learn something also.

I've copied busybox and few libraries and It works now!

BusyBox
# du -sh
7MB

I'm proud :) mainly because I'm... a Windows user, but it will change soon. I'm going to read more how to build my own system and about Linux in general. I think it is system form me.

Thanks for all.

»
Syndicate content