# mapping devices on boot

## idella4

I've got a few examples of booting going awry.]  These are vms booted in xen.  I hope that doesn't scare everyone off.

Once created, the booting process in vms seems to follow regular patterns.  This is a case of kernel procedures /processes not working correctly.

I submit this on the basis that it could be a regular bootup doing the same thing  In fact, I have had this happen and got around it accordingly.

This is a vm losing its way;

```

     device=eth0, addr=192.168.0.83, mask=255.255.255.0, gw=192.168.0.1,

     host=192.168.0.83, domain=, nis-domain=(none),

     bootserver=192.168.0.1, rootserver=192.168.0.1, rootpath=

Freeing unused kernel memory: 432k freed

Loading, please wait...

Begin: Loading essential drivers ... done.

Begin: Running /scripts/init-premount ... FATAL: Error inserting fan (/lib/modules/2.6.31.13-xen-domU/kernel/drivers/acpi/fan.ko): No such device

FATAL: Error inserting thermal (/lib/modules/2.6.31.13-xen-domU/kernel/drivers/acpi/thermal.ko): No such device

done.

Begin: Mounting root file system ... Begin: Running /scripts/local-top ... device-mapper: ioctl: 4.15.0-ioctl (2009-04-01) initialised: dm-devel@redhat.com

done.

Begin: Running /scripts/local-premount ... done.

mount: mounting xvda1 on /root failed: No such device

Begin: Running /scripts/local-bottom ... done.

done.

Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory

done.

mount: mounting /sys on /root/sys failed: No such file or directory

mount: mounting /proc on /root/proc failed: No such file or directory

Target filesystem doesn't have /sbin/init.

No init found. Try passing init= bootarg.

BusyBox v1.14.2 (Debian 1:1.14.2-2) built-in shell (ash)

Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off

(initramfs) ls /lib/modules/2.6.31.13-xen-domU/kernel/drivers/acpi/fan.ko

/lib/modules/2.6.31.13-xen-domU/kernel/drivers/acpi/fan.ko

(initramfs) ls /lib/modules/2.6.31.13-xen-domU/kernel/drivers/acpi/thermal.ko

/lib/modules/2.6.31.13-xen-domU/kernel/drivers/acpi/thermal.ko

(initramfs) ls /dev/xvda1

/dev/xvda1

(initramfs) ls /root

(initramfs) ls /sbin/init

ls: /sbin/init: No such file or directory

(initramfs) uname -a

Linux 192.168.0.83 2.6.31.13-xen-domU #2 SMP Mon May 17 14:34:47 WST 2010 x86_64 GNU/Linux

(initramfs) ls /lib/modules/2.6.31.13-xen-domU/                              

kernel               modules.dep          modules.softdep

modules.alias        modules.dep.bin      modules.symbols

modules.alias.bin    modules.order        modules.symbols.bin

(initramfs) mount -o remount,rw rootfs /    

(initramfs) 

```

It can be seen that it gets to mounting root and loses its way.  Each attempt to mount a device misses.

The code shows the devices are there, but it says they are not.

How does this happen?   This  

(initramfs) mount -o remount,rw rootfs /    

(initramfs

shows it can mount root after all, but I've called it rootfs which it recognises.

I think      Try passing init= bootarg   wouldn't help since it still needs to mount root to find it.

Is  it the initrd?

Vms seem to need the initrd, without it;

```

[color=olive]VFS: Cannot open root device "xvda1" or unknown-block(0,0)

Please append a correct "root=" boot option; here are the available partitions:

ca01         8388608 xvda1 driver: vbd

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Pid: 1, comm: swapper Not tainted 2.6.31.13-xen-domU #3

Call Trace:

 [<ffffffff8125bacd>] ? panic+0x78/0x138

 [<ffffffff813bbff2>] ? mount_block_root+0x24a/0x261

 [<ffffffff813bc1c0>] ? prepare_namespace+0x168/0x192

 [<ffffffff813bb577>] ? kernel_init+0x198/0x1a8

 [<ffffffff81012cea>] ? child_rip+0xa/0x20

 [<ffffffff81011ee7>] ? int_ret_from_sys_call+0x7/0x1b

 [<ffffffff8101269d>] ? retint_restore_args+0x5/0x6

 [<ffffffff81012ce0>] ? child_rip+0x0/0x20[/color]
```

 Another example

```

Password: 

Login incorrect

login: root

-bash-3.2# modprobe vga16fb

WARNING: Could not open 'kernel/drivers/video/vgastate.ko': No such file or directory

FATAL: Could not open 'kernel/drivers/video/vga16fb.ko': No such file or directory

-bash-3.2# ls /lib/modules/2.6.31.13-xen-domU/kernel/drivers/video/vgastate.ko

/lib/modules/2.6.31.13-xen-domU/kernel/drivers/video/vgastate.ko

-bash-3.2# ls /lib/modules/2.6.31.13-xen-domU/kernel/drivers/video/vga16fb.ko

/lib/modules/2.6.31.13-xen-domU/kernel/drivers/video/vga16fb.ko

-bash-3.2# 

```

Anyone explain this?  This is intricate but I think not uncommon.

----------

## Hu

It is a bit distracting having most of your post in blue.

What problem do you want help solving?  Your first code sample shows some problems with the initramfs failing to mount a filesystem off the Xen virtual hard disk node, but you also said that you "got around it accordingly."

It looks like your root problem with the initramfs is that the device node xvda1 exists, but no driver claims the associated device number, so you get ENODEV.  It does not help that your initramfs then goes on to try actions which can only succeed if mounting root failed.  It should have stopped after the first failure, to avoid cluttering the screen.  I see no evidence that the initramfs started a dynamic device manager, so the device node at /dev/xvda1 is probably a static node that was inserted into the initramfs when it was built.  Thus, the device node can exist regardless of whether a driver is registered to serve requests on that device.

Similarly, the failure to insert the kernel modules returns ENODEV, not ENOENT.  It is not immediately clear from the kernel source what would trigger ENODEV on module insertion.

The rootfs that you successfully remounted read-write is the root of the initramfs, not the root of the Xen virtual hard drive.

In the final example, what is the uname of the affected system?

----------

## idella4

Hu,

thanks, that's very good.  Looks is if you can help me pin this down.  And for both of us I shall revert to standard black

.

 When I got around it accordingly, that's perhaps a bit off the mark.  I used a gentoo kernel to run a debian lenny system

The lenny xen kernel misfired and could not boot into xen.  I used the gentoo xen kernel  In preparing it, a number of times on attempting to boot in, it reported on the screen could not find /lib/modules/2.6.31-xen-r10-AMD64/ modules.dep.

I looked and looked and re-checked, and was sure that the name of the folder was indeed  2.6.31-xen-r10-AMD64, or something close to that which I used, and there was a modules.dep file.  I suppose I didn't get around it, I just persevered compiling, and finally it found it, and booted in.

That was for a host system.

This is for a guest.  That form of resolution that I can see doesn't apply.

```

 I see no evidence that the initramfs started a dynamic device manager, so the device node at /dev/xvda1 is probably a static node that was inserted into the initramfs when it was built. Thus, the device node can exist regardless of whether a driver is registered to serve requests on that device. 

```

I follow you.  That's the essence of the problem.  Tihs .cfg

```

kernel      = '/boot/kernel-2.6.31.13-xen-amd64-domU'

ramdisk     = '/boot/initramfs.img-2.6.31.13-xen-domU'

memory      = '300'

#

#  Disk device(s).

#

root        = 'xvda1 ro console=tty0'

disk        = [

                  'file:/mnt/images/xen/images/debian/Squeeze.img,xvda1,w',

#                  'phy:sdb3,xvdb,w'        

              ]

```

This is where the static device would be created from.

```

Similarly, the failure to insert the kernel modules returns ENODEV, not ENOENT

```

looks like you have a good understanding of this.  :Smile: 

 *Quote:*   

> 
> 
> The rootfs that you successfully remounted read-write is the root of the initramfs, not the root of the Xen virtual hard drive. 
> 
> 

 

I follow.

Just to verify, this xen guest kernel is effective.  Here it is booting up a lenny.

kernel      = '/boot/kernel-2.6.31.13-xen-amd64-domU'

ramdisk     = '/boot/initramfs.img-2.6.31.13-xen-domU'

Listening on LPF/eth0/00:16:3e:59:c4:6e

Sending on   LPF/eth0/00:16:3e:59:c4:6e

Sending on   Socket/fallback

DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 4

DHCPOFFER from 192.168.0.1

DHCPREQUEST on eth0 to 255.255.255.255 port 67

DHCPACK from 192.168.0.1

bound to 192.168.0.8 -- renewal in 1760 seconds.

done.

INIT: Entering runlevel: 2

Starting enhanced syslogd: rsyslogd.

Starting OpenBSD Secure Shell server: sshd.

Starting periodic command scheduler: crond.

Debian GNU/Linux 5.0 lenny01 hvc0

lenny01 login: 

Example 2;  an addition; not surprisingly,

```

Freeing unused kernel memory: 432k freed

Loading, please wait...

Begin: Loading essential drivers ... done.

Begin: Running /scripts/init-premount ... FATAL: Error inserting fan (/lib/modules/2.6.31.13-xen-domU/kernel/drivers/acpi/fan.ko): No such device

FATAL: Error inserting thermal (/lib/modules/2.6.31.13-xen-domU/kernel/drivers/acpi/thermal.ko): No such device

done.

Mounting other filesystems:  [  OK  ]

Starting PC/SC smart card daemon (pcscd): [  OK  ]

Starting HAL daemon: [FAILED]

Starting cups: [  OK  ]

Starting xfs: [  OK  ]

Starting Avahi daemon... 

------------------------------------

Last login: Thu May 20 11:41:46 on hvc0

-bash-3.2# uname -a

Linux centos5.com 2.6.31.13-xen-domU #4 SMP Thu May 20 00:51:11 WST 2010 x86_64 x86_64 x86_64 GNU/Linux

-bash-3.2# ls /lib/modules/2.6.31.13-xen-domU/kernel/drivers/video/vgastate.ko 

/lib/modules/2.6.31.13-xen-domU/kernel/drivers/video/vgastate.ko

-bash-3.2# ls /lib/modules/2.6.31.13-xen-domU/kernel/drivers/video/vga16fb.ko 

/lib/modules/2.6.31.13-xen-domU/kernel/drivers/video/vga16fb.ko

-bash-3.2# lsmod

Module                  Size  Used by

ext3                  122192  1 

jbd                    47480  1 ext3

dm_mod                 64072  0 

thermal_sys            15168  0 

```

As an extra, what causes hald to not start?  It has a total of four modules in lsmod; strangled.

You would be thinking I used a different kernel to 'uname -a', but I'm wise to that.  I can't do much more to this vm until it gets past this.

This boot up process flaw  is not 'specific' to xen, it appears to be a flaw that occurs in a regular linux boot, so should be adjustable.

Hope for your continued help,  thanks

----------

## Hu

So the same kernel and initramfs work when booting a Debian Lenny system, but fail to boot Gentoo?  Given that the failure occurs while still in the initramfs, that would implicate a configuration error in the Xen configuration file for the Gentoo guest.

----------

## idella4

thanks Hu,

yes.  I have a few kernels now that I use for booting guests.  The gentoo kernel I made boots the host, but doesn't manage to boot guests.  Ubuntu made a 2.6.31 xen kernel for guests.  It managed to boot up guests that I installed where my gentoo kernel didn't get there.  Then I made a gentoo 64, which is not really crucial to this process, but these example I an doing in a 64 gentoo.  I just made a 64 version of the Ubuntu guest kernel.  I have a couple of versions, some not effective so for this ofcourse only the effective one is cited.

So, this kernel 2.6.31.13-xen-domU works on a guest lenny, but not on the two in the examples.  It is a  64 version of the Ubuntu kernel.  I can use the ubuntu original kernel in a 32 system to boot 32 bit guests which my 32 gentoo kernel doesn't.  The examples cited are a squeeze and a centos5.

 *Quote:*   

> 
> 
> configuration error in the Xen configuration file for the Gentoo guest
> 
> 

 

Here's the essence of the problem.  Do you know where in the guest to adjust xen configs?  

The docs don't really say much about it, just describe the boot .cfg file and say boot it up.  So are you referring the .cfg file?

This implies that the .cfg file is correct for one kernel, but not for another.

There's not much room for manouver here.  There's only root=.... console= that are commonly suggested.  That's where my knowledge is constrained.  It does appear to be missing root.  I'll work on it, but not alot to choose from.

Am open for suggestions.

----------

