[one-users] Failed booting Xen 4.1 DomUs with OpenNebula 3.8.3

Ruben S. Montero rsmontero at opennebula.org
Mon May 6 04:06:08 PDT 2013


OK

Glad to known you managed to solve the problems. Some thoughts:

1.- install gems is not included as the deb package should handle the
dependencies (by installing the package form of the gem). We are adding to
the documentation a description of how to install the software from a
package to better explain this.

2.- There may be some missing gems and dependencies in the 3.8.3 packages.
These should be fixed in the next release though.

3.- The stderr of the drivers are shown in the logs, so any  runtime error
(like a missing gem) should be in the vm.log file. I think that your
problem was fixed by the upgrade process but it was not related to any
missing gem....

Thanks for reporting back

Ruben





On Mon, May 6, 2013 at 10:53 AM, Sam Ho <sammhho at gmail.com> wrote:

> Hi Ruben,
>
> Thank you very much for your reply, apparently I got my problem solved.
> I suspect it was due to incomplete installation of the GEMs.
>
> After installing the official .deb packages, the guide instructed user to
> do "/usr/share/one/install_gems".
> However, the script was not there (why no .deb do this?) and there's no
> "/usr/share/one" directory, so I just skipped the step... thinking that if
> the GEMs are needed I would see something about them in error logs...
>
> When I try uninstalling the 3.8.3 packages and install OpenNebula by
> apt-get,
> the installation process prompted me for installing some GEM scripts,
> and in turn leaded me into installing several other dependencies.
> After that I have a running OpenNebula 3.2.1.
> Then I uninstalled it, installed 3.8.3 .debs, and ran the install_gems
> script from the source-code tarball, and now its up running perfectly.
>
> So, it'd be good if the "/usr/share/one" directory and the stuffs inside
> got installed by the .debs.
> Also if there's any hint in the error logs about missing ruby scripts it
> would have saved me lots of time,
> though that's my own fault.
>
> Cheers,
> Sam
>
>
> On 3 May 2013 22:58, Ruben S. Montero <rsmontero at opennebula.org> wrote:
>
>> Hi
>>
>> Can you send the deployment.0 file generated by opennebula, and the one
>> that you are using for 'xm create' to succeed ?
>>
>> Cheers
>>
>> Ruben
>>
>>
>> On Fri, May 3, 2013 at 11:12 AM, Sam Ho <sammhho at gmail.com> wrote:
>>
>>> Hi there,
>>>
>>> Could someone please shed some light ? I'm stuck with this for more than
>>> a week now.
>>> Suggestions on how I go about debugging is good enough.
>>>
>>> Have OpenNebula 3.8.3 installed using the official .deb, on a Ubuntu
>>> 12.04.2 LTS as Xen Dom0.
>>> Trying to boot into several DomUs created with xen-tools
>>> 'xen-create-image', on the same machine.
>>> DomUs are Ubuntu Lucid and Centos-5.
>>> I can boot into these DomUs using 'xm create' through Pygrub or kernel,
>>> and they run perfectly fine.
>>> But when I do 'onevm create' or 'onetemplate instantiate', they either
>>> won't boot (for pygrub cases) or stop at the initramfs shell (for kernel
>>> boot cases).
>>>
>>> For the kernel boot case, 'onevm list' show the DomU running, but when I
>>> do 'xm console' into it it says:
>>>
>>> [    0.725043] registered taskstats version 1
>>> *[    0.725051] XENBUS: Device with no driver: device/vbd/51714*
>>> *[    0.725053] XENBUS: Device with no driver: device/vbd/51713*
>>> *[    0.725056] XENBUS: Device with no driver: device/vif/0*
>>> *[    0.725058] XENBUS: Device with no driver: device/console/0*
>>> [    0.725068]   Magic number: 1:252:3141
>>> [    0.725076] /build/buildd/linux-2.6.32/drivers/rtc/hctosys.c: unable
>>> to open rtc device (rtc0)
>>> [    0.725081] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
>>> [    0.725083] EDD information not available.
>>> [    0.731969] Freeing initrd memory: 22736k freed
>>> [    0.735010] Freeing unused kernel memory: 808k freed
>>> [    0.735151] Write protecting the kernel read-only data: 7840k
>>> Loading, please wait...
>>> Begin: Loading essential drivers... ...
>>> Done.
>>> [    0.757035] udev: starting version 151
>>> Begin: Running /scripts/init-premount ...
>>> Done.
>>> Begin: Mounting root file system... ...
>>> Begin: Running /scripts/local-top ...
>>> Done.
>>> [    0.839045] blkfront: xvda2: barriers enabled
>>> [    0.849632] blkfront: xvda1: barriers enabled
>>> *Begin: Running /scripts/local-premount ...*
>>> *Done.*
>>> *[   30.834922] end_request: I/O error, dev xvda2, sector 2*
>>> *[   30.834955] EXT3-fs: unable to read superblock*
>>> *[   30.841804] end_request: I/O error, dev xvda2, sector 2*
>>> *[   30.841832] EXT2-fs: unable to read superblock*
>>> *[   30.849824] end_request: I/O error, dev xvda2, sector 2*
>>> *[   30.849855] EXT4-fs (xvda2): unable to read superblock*
>>> *mount: mounting /dev/xvda2 on /root failed: Invalid argument*
>>> 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.13.3 (Ubuntu 1:1.13.3-1ubuntu11) built-in shell (ash)
>>> Enter 'help' for a list of built-in commands.
>>>
>>> (initramfs)
>>>
>>>
>>> I read from somewhere that the XENBUS lines could be fine,
>>> so what's the problem about *unable to read superblock*?
>>>
>>> Here is the onetemplate, kernels were copied from inside the DomU to the
>>> /boot in Dom0,:
>>>
>>> NAME   = vm02
>>> CPU    = 1
>>> MEMORY = 512
>>>
>>> #OS = [ bootloader = /usr/lib/xen-default/bin/pygrub,
>>> OS = [ kernel = /boot/vmlinuz-2.6.32-46-server,
>>>        initrd = /boot/initrd.img-2.6.32-46-server,
>>>        root = "xvda2",
>>>        KERNEL_CMD = "ro" ]
>>>
>>> DISK = [ IMAGE_ID = 3 ]
>>>
>>> DISK = [ type = swap,
>>>          size = 512,
>>>          target = "xvda1",
>>>          readonly = "no" ]
>>>
>>> NIC = [ IP="147.8.183.150", MAC="08:00:27:C8:EB:ED", bridge=xenbr0 ]
>>> RAW = [ type="xen", data="on_crash='restart'" ]
>>>
>>>
>>> And the disk image was imported with:
>>>
>>> NAME    = "vm02_img"
>>> PATH    = /home/xen/domains/vm02/disk.img
>>> TYPE    = OS
>>> DEV_PREFIX = "xdv"
>>> TARGET  = "xvda2"
>>> DRIVER  = file:
>>>
>>>
>>> I compared the xend.log messages for successful boot by 'xm create' with
>>> failed boot by 'onevm create', doesn't seem to have much difference...
>>>
>>> For the Pygrub boot case, there seem to be no way to pass '*root=/dev/xvda2
>>> ro*' to Pygrub from OpenNebula?
>>> In xend.log it says:
>>>
>>> [2013-05-03 01:10:38 20461] DEBUG (XendBootloader:113) Launching
>>> bootloader as ['/usr/lib/xen-default/bin/pygrub',
>>> '--output=/var/run/xend/boot/xenbl.15718', '-q',
>>> '/var/lib/one//datastores/0/17/disk.0'].
>>>
>>>
>>> And eventually it returns:
>>>
>>> [2013-05-03 01:10:38 15927] ERROR (XendBootloader:214) Boot loader
>>> didn't return any data!
>>> [2013-05-03 01:10:38 15927] ERROR (XendDomainInfo:488) VM start failed
>>> Traceback (most recent call last):
>>>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
>>> line 474, in start
>>>     XendTask.log_progress(31, 60, self._initDomain)
>>>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendTask.py", line
>>> 209, in log_progress
>>>     retval = func(*args, **kwds)
>>>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
>>> line 2838, in _initDomain
>>>     self._configureBootloader()
>>>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendDomainInfo.py",
>>> line 3285, in _configureBootloader
>>>     bootloader_args, kernel, ramdisk, args)
>>>   File "/usr/lib/xen-4.1/bin/../lib/python/xen/xend/XendBootloader.py",
>>> line 215, in bootloader
>>>     raise VmError, msg
>>> VmError: Boot loader didn't return any data!
>>>
>>>
>>> Where in a successful boot with 'xm create' it is:
>>>
>>> [2013-05-03 01:13:01 20522] DEBUG (XendBootloader:113) Launching
>>> bootloader as ['/usr/lib/xen-default/bin/pygrub', *'--args=root=/dev/xvda2
>>> ro '*, '--output=/var/run/xend/boot/xenbl.9704', '-q',
>>> '/home/xen/domains/vm02/disk.img'].
>>>
>>>
>>> Any suggestions on how I can debug these?
>>> Sorry for writing such a long post...
>>>
>>> Best regards,
>>> Sam Ho
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opennebula.org
>>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
>>>
>>>
>>
>>
>> --
>> Ruben S. Montero, PhD
>> Project co-Lead and Chief Architect
>> OpenNebula - The Open Source Solution for Data Center Virtualization
>> www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
>>
>
>


-- 
Ruben S. Montero, PhD
Project co-Lead and Chief Architect
OpenNebula - The Open Source Solution for Data Center Virtualization
www.OpenNebula.org | rsmontero at opennebula.org | @OpenNebula
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opennebula.org/pipermail/users-opennebula.org/attachments/20130506/aacd8f1d/attachment-0002.htm>


More information about the Users mailing list