booting without initrd

[aspnair]

I compiled 2.6.34-rc5 vanilla linux kernel on my debian squeeze centrino laptop with ext4 root filesystem. Since I wanted to keep the kernel lite, I decided not to use initrd and rarely used things like firewire, bluetooth, pcmcia etc.
Output of lspci

Code: Select all

00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02)
00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 83)
00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 03)
00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 03)
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)
00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 03)
02:07.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a9)
02:07.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev a9)
02:07.2 FireWire (IEEE 1394): Ricoh Co Ltd R5C552 IEEE 1394 Controller (rev 01)
02:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
02:09.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05)

Since I wanted to use the newer ATA_PII driver, I included the following and many other options to get compiled into the kernel.
CONFIG_SCSI_MOD, CONFIG_SCSI, CONFIG_BLK_DEV_SD, CONFIG_ATA, CONFIG_ATA_PIIX,
CONFIG_EXT2_FS, CONFIG_EXT3_FS, CONFIG_EXT4_FS (included ext2/ext3 even though it is not the root filesystem),
CONFIG_AGP, CONFIG_AGP_INTEL

Current problem.
The above configuration works well when I use a minimal initrd. But after disabling CONFIG_BLK_DEV_INITRD and updating grub not to use the initrd, it could not mount the root filesystem and gives out a kernel panic
"unable to mount root fs on unknown-block(0,0)"
So I decided to analyze the modules in the working initrd.

Code: Select all

gzip -dc  /boot/initrd.img-2.6.34-rc5 | cpio -i
find . -name "*.ko"
./lib/modules/2.6.34-rc5/kernel/arch/x86/crypto/aes-i586.ko
./lib/modules/2.6.34-rc5/kernel/crypto/sha256_generic.ko
./lib/modules/2.6.34-rc5/kernel/crypto/cbc.ko
./lib/modules/2.6.34-rc5/kernel/crypto/xts.ko
./lib/modules/2.6.34-rc5/kernel/crypto/aes_generic.ko
./lib/modules/2.6.34-rc5/kernel/crypto/gf128mul.ko
./lib/modules/2.6.34-rc5/kernel/drivers/acpi/thermal.ko
./lib/modules/2.6.34-rc5/kernel/drivers/acpi/fan.ko
./lib/modules/2.6.34-rc5/kernel/drivers/md/dm-mod.ko
./lib/modules/2.6.34-rc5/kernel/drivers/md/dm-crypt.ko
./lib/modules/2.6.34-rc5/kernel/drivers/thermal/thermal_sys.ko
./lib/modules/2.6.34-rc5/kernel/drivers/video/vgastate.ko
./lib/modules/2.6.34-rc5/kernel/drivers/video/vga16fb.ko

Interestingly with the exception of thermal, fan, thermal_sys no other module got loaded
Is there anything missing here? Any idea would be really appreciated.

Thanks and Regards

Anand

[thewanderer]

The basic things to check for:
What is your root= setting in GRUB? What kind of device does it point to? Is this kind of device available at the boot time? I'm not really sure if LABEL=... or UUID=... is supported in the kernel itself - could be handled by the initrd (udev in particular), and that's what I would bet on.
Are you using root on LVM or RAID? If so, the proper setup tools have to be available to the kernel at boot time - initrd must be present.
Are you booting from your main hard drive, or from a pendrive? In case of pendrives, drive names change (sda on one machine is sdb on another).If booting from USB and using labels, you are facing the problem with udev described above.

[aspnair]

I am using grub2. No raid or lvm is used. The kernel is compiled using make-kpkg

Grub entry (currently with initrd)

Code: Select all

### BEGIN /etc/grub.d/10_linux ###
menuentry "Debian GNU/Linux, with Linux 2.6.34-rc5" --class debian --class gnu-linux --class gnu --class os {
  insmod ext2
  set root='(hd0,2)'
  search --no-floppy --fs-uuid --set ddc23ac8-37bf-4e89-a1cd-d77aefc011c8
  echo  Loading Linux 2.6.34-rc5 ...
  linux /boot/vmlinuz-2.6.34-rc5 root=UUID=ddc23ac8-37bf-4e89-a1cd-d77aefc011c8 ro  quiet
  echo  Loading initial ramdisk ...
  initrd  /boot/initrd.img-2.6.34-rc5
}

There is only a single ide hard disk in the laptop. Currently I am dual booting along with winxp.

Code: Select all

/dev/sda1: UUID="0204B23984A792D4" TYPE="ntfs" 
/dev/sda2: LABEL="ROOT_DEBIAN" UUID="ddc23ac8-37bf-4e89-a1cd-d77aefc011c8" TYPE="ext4" 
/dev/sda3: LABEL="LINUX_SWAP" UUID="3b9a3366-721d-4283-92ea-795e1e75585f" TYPE="swap" 
/dev/sda4: UUID="0647a5f6-8c0e-449b-a466-cd0e167a76d7" TYPE="ext4" 

edit: while not using initrd the last two lines of grub.conf go away.
Do we need to include any particular kernel configuration to use label/uuid?

[thewanderer]

From /init in initrd:

Code: Select all

# Parse command line options
for x in $(cat /proc/cmdline); do
        case $x in
        init=*)
                init=${x#init=}
                ;;
        root=*)
                ROOT=${x#root=}
                case $ROOT in
                LABEL=*)
                        ROOT="${ROOT#LABEL=}"

                        # support any / in LABEL= path (escape to \x2f)
                        case "${ROOT}" in
                        */*)
                        if command -v sed >/dev/null 2>&1; then
                                ROOT="$(echo ${ROOT} | sed 's,/,\\x2f,g')"
                        else
                                if [ "${ROOT}" != "${ROOT#/}" ]; then
                                        ROOT="\x2f${ROOT#/}"
                                fi
                                if [ "${ROOT}" != "${ROOT%/}" ]; then
                                        ROOT="${ROOT%/}\x2f"
                                fi
                                IFS='/'
                                newroot=
                                for s in $ROOT; do
                                        newroot="${newroot:+${newroot}\\x2f}${s}"
                                done
                                unset IFS
                                ROOT="${newroot}"
                        fi
                        esac
                        ROOT="/dev/disk/by-label/${ROOT}"
                        ;;
                UUID=*)
                        ROOT="/dev/disk/by-uuid/${ROOT#UUID=}"
                        ;;
                /dev/nfs)
                        [ -z "${BOOT}" ] && BOOT=nfs
                        ;;
                esac
                ;;
# the rest follows

As you can see, the UUID= and LABEL= parsing takes place in the initrd. I'm not quite sure as to where the /dev/disk/* nodes are generated, so you probably have to check.
Anyway, without an initrd, the UUID/LABEL magic is not going to work as root=.

[aspnair]

Thanks thewanderer

Anyway, without an initrd, the UUID/LABEL magic is not going to work as root=.

That looks correct.
It is working now. This is what I followed.
First I compiled, created initrd, updated grub from debian stock kernel. So it created grub entry as I shown in the previous post.
Then after booting to 2.6.34-rc5 (with initrd), I deleted the initrd-2.6.34-rc5 and regenerated grub.cfg.
So it is working now with the following grub.cfg entry.

Code: Select all

### BEGIN /etc/grub.d/10_linux ###
menuentry "Debian GNU/Linux, with Linux 2.6.34-rc5" --class debian --class gnu-linux --class gnu --class os {
  insmod ext2
  set root='(hd0,2)'
  search --no-floppy --fs-uuid --set ddc23ac8-37bf-4e89-a1cd-d77aefc011c8
  echo  Loading Linux 2.6.34-rc5 ...
  linux /boot/vmlinuz-2.6.34-rc5 root=/dev/sda2 ro  quiet
}

[ShedPaul]

I was going to ask about this, but from a slightly different angle. But this thread came up in a search, so do I understand what has written here?
You cannot write a kernel which will boot without the use of a initrd which uses UUIDs.? I had assumed there was a module I needed to compile into the kernel for this to work, all I needed to do was to find it. Now from this thread it appears not to be the case, so I have either to use an initrd or to change the entries in my fstab file back to plain old /dev/hda etc (not a problem in my case, but not elegant)

[BioTube]

AFAIK, only the "root=" part of the kernel command line is forbidden from using "UUID=" without an initrd. I've heard you can set it to root=/dev/by-uuid/ to get the same effect, but I've never successfully booted without one.

[ShedPaul]

Ah, so there could be something else.
I am at the stage of getting the kernel to boot without the initrd, but it has problems reading the fstab file. So it drops into a maintenance 'Control D' mode. My partitions are ext4 (and swap of course) and I compiled in everything in the ext4 section of 'filesystems' exept debugging (I think). What could I have missed? When this latest kernel finishes compiling if it doesn't work I'll change the UUIDs in the fstab file to /dev/sda1 etc.

[aspnair]

I am using UUID in the fstab for the above mentioned configuration without any problem. Are you able to manually mount in the maintenance shell mode?

[ShedPaul]

Aspnair the answer to your question is no.
Let me review. The system is a squeeze install, which used UUIDs for the partitions. The fstab file contains 3 ext4 partitions and a swap partition. The default kernels boot and mount all the partitions. My (2.6.33) kernel does not. Obviously I am not building this kernel the 'Debian way', but I am compiling from kernel.org source. It boots, mounts the root partition and the swap, but not the other two. When I go into maintenance mode and use 'mount -a' it tells me that the special devices UUID=1234...... do not exist. It is as though I have built a kernel which cannot see UUIDs - but what should I add?
As I said I could just go to /dev/sda1 etc. in the fstab file, but I'd like to chase this one down.

[aspnair]

UUIDs are listed in /dev/disk/by-uuid, you should show a softlink for sda1 and other devices there.

[Sephiroth]

I just had this problem. It may be a silly question, but do you compile ext4 into the kernel itself without ext2/3/etc? In other words, compile other filesystems as modules, but compile ext4 into the kernel? That's what fixed it for me.

*EDIT*

One other thing. I have my "root=UUID=123-xyz" in grub.cfg and it works fine booting my kernel without an initrd. I read in this thread that this is not supposed to be possible. Why not, and has it changed in 2.6.34?

[ShedPaul]

I have more information, but I am getting more and more confused. Don't forget in all of this the Debian kernels work fine (but with initrd of course)
I have ext4 compiled in, but not ext2 or ext3, because I don't have any ext2 or ext3 filesystems (question - do I need them even so?)
So now I changed my UUIDs in my fstab as well as my grub.cfg - no improvement so I can stop blaming that particular irritation (I will come back to this when the rest is working).
My kernel boots and then drops to the maintenance because it cannot mount /dev/sda5 and /dev/sda6. By this stage /dev/sda1 which is the root is mounted. All are ext4 partitions. Of course I tried mount -a but this doesn't work because the other partitions are not in the /dev directory. In fact the /dev directory is alarmingly empty with about 8 entries. Now we reach the limits of my knowledge. At what point should this directory be populated and how?
Don't forget this a very skinny kernel with as little as possible. I can only assume I have chopped out an essential component - but where?

[frostschutz]

it should be populated by udev

to my knowledge, udev requires tmpfs Virtual memory file system support (former shm fs), /proc filesystem, and inotify

in recent kernels there is also devtmpfs which may also be of assistance to initrd / udev

http://git.kernel.org/?p=linux/hotplug/ ... D;f=README
18 Requirements:
19 - Version 2.6.27 of the Linux kernel with sysfs, procfs, signalfd, inotify,
20 unix domain sockets, networking and hotplug enabled:
21 CONFIG_HOTPLUG=y
22 CONFIG_UEVENT_HELPER_PATH=""
23 CONFIG_NET=y
24 CONFIG_UNIX=y
25 CONFIG_SYSFS=y
26 CONFIG_SYSFS_DEPRECATED*=n
27 CONFIG_PROC_FS=y
28 CONFIG_TMPFS=y
29 CONFIG_INOTIFY_USER=y
30 CONFIG_SIGNALFD=y
31 CONFIG_TMPFS_POSIX_ACL=y (user ACLs for device nodes)
32 CONFIG_BLK_DEV_BSG=y (SCSI devices)
[...]
57
58 Setup:
59 - At bootup, the /dev directory should get the 'devtmpfs' filesystem
60 mounted. Udev will manage permissions and ownership of the kernel-created
61 device nodes, and possibly create additional symlinks. If needed, udev also
62 works on an empty 'tmpfs' filesystem, but some static device nodes like
63 /dev/null, /dev/console, /dev/kmsg are needed to be able to start udev itself.
64

[ShedPaul]

Thanks
I have udev, but I will go on the system to look for the others

[aspnair]

What I learnt is that, just compile *only* the rootfs driver to the kernel. Support your rootfs is ext4 and you have another ext3 partition, leave ext3 as module only. Also follow frostschutz as he has given nice details of udev

[ShedPaul]

Hurrah it works! Thanks for your help. I don't think I would have got there on my own. Interestingly Squeeze had not even loaded udev, I had put this on the day before yesterday. Considering I have built many kernels in the past that was a difficult journey. Somebody building their first kernel must be somewhat daunted.
Thanks again.

[Sephiroth]

So the solution was to compile in just the root FS driver and leave every other FS driver as a module? That's what fixed it for me as well.

[frostschutz]

so that basically means your kernel had issues autodetecting the right fs type... but with the other choices removed (added later as modules) the problem goes away?

there's a kernel parameter to specify the fs type of the root partition (rootfstype= or rootfs= I don't quite remember, check the kernel-parameters.txt) - however usually the auto detect should work

never used ext4 myself, so I don't have any experience in that regard

[ShedPaul]

No, the problem for me was the requirements for udev in the kernel. And some of those uptions were obscure, with not very helpful help. I originally avoided initrd because it seemed to be too difficult, now it seems it might be easier to use it.Once I had those options it worked. Things have changed quickly and I haven't kept up. This is the usual problem with a non-booting kernel.
But before you kernel gurus go away, what is the message in the kernel compile about the root device being at (22,1) - this obviously isn't disk number 22. When a kernel boot fails I get information about high numbers like these that don't exist.