New Xen Instance from Stacklet Ubuntu 10.04 LTS x86-64 bad root password

Hi Guys,

I have been wrestling with getting a stacklet Xen Image of Ubuntu 10.04 LTS x86-64 working for xen instance provisioning in Cloudmin. I have been successful in changing the stacklet /etc/fstab for the root drive to /dev/sda (from /dev/xvda) (for whatever reason, there are no partitions in stacklet image) and also the .cfg so Cloudmin can create an Image. However, when I create a new instance from this new image the root password is not what was given during the creation. I have reproduced it 3 times in a row and am not sure where to go next. Any chance you might make a virtualmin xen image for Ubuntu 10.04 LTS x86-64 available?



Closed (fixed)


Could you post the output from Cloudmin during the creation process? You should see a message when it sets the root password ..

Also, by default Ubuntu doesn't allow direct SSH logins by root, so you may have to SSH in as the ubuntu user and then sudo to root.

Hi Jamie,

Attached is the entire output from the creation using the Image (which was created from a working x86_64 Ubuntu instance that was created with the actual Stacklet image).

I am attempting to log in as root via xm console without any luck.


Ok, that error about "failed to list partitions" seems to be the cause of the problem... it means that Cloudmin thinks the image file is in a different format to what it expects.

How was this image created exactly? Did you download the stacklet Ubuntu 10.04 image and then import it into Cloudmin at Cloudmin Settings -> New System Images -> Create image for Xen?

Hi Jamie,

I had played around with things so much I decided to start fresh and document everything I did. This might be overkill but it is exactly what I have done and where things are not working with the root password.

Steps to creating Xen Instance for Ubuntu x86_64
0. Download Stacklet ubuntu.10-04.x86-64.20110721.img.tar.bz2 to /mnt/share1/xen
1. tar -xvjf ubuntu.10-04.x86-64.20110721.img.tar.bz2
- StackletImageCfg.PNG
2. Rename ubuntu.10-04.x86-64.20110721.img to ubuntu.10-04.x86-64.20110721.ext3 (modify img to point to .ext3)
3. Use cloudmin New System Images->Create Xen Image
4. Use Cloudmin Create Xen Instance using Cloudmin Xen Image (earth2)
- CreateXenInstanceFromCloudminImageCfg.PNG
5. Login to xen host and use xm console to view failed boot
- XenInstanceFromCloudminImageXMConsoleFailureToBoot.PNG
6. Logout, modify .cfg for image to use sda instead of sda1 (add root /dev/sda)
- CreateXenInstanceFromCloudminImageCfg-fix.PNG
- XenInstanceFromCloudminImageDefaultFstab.PNG
- XenInstanceFromCloudminImageFixedFstab.PNG
7. xm destroy earth2 / xm create earth2.cfg
- XenInstanceFromCloudminImageXMConsoleSuccess.PNG
8. Edit /etc/fstab to use /dev/sda instead of /dev/xvda
9. Create Image of this fixed setup (Xen Instance).
- CreateCloudmindXenImageFromXenInstance.PNG
- CreateCloudmindXenImageFromXenInstance-Success.PNG
10. Create final Xen instance from last image
- CreateFinalXenInstance.PNG
- CreateFinalXenInstance-success.PNG
11. Try to use xm console titan to login via root (fails)
- FinalXenInstanceXmConsoleRootLoginFail.PNG

In step 3, for the "Image file format" field, did you select "Single partition" or "Whole disk" ?

Also, if you go to Cloudmin Settings -> New System Images and click on your image, does the "Image format" field appear and if so what value does it contain?

I have tried a few things and found that I can get the initial Instance built from the New Xen Image imported using Cloudmin to work simply by updating the .cfg file disk parameters from :

cloudmin default (I think Cloudmin sets sda1 by default since the Image setting for the source disk was set to a single partition when it was created importing the stacklet img file):

disk = ['file:/mnt/share1/xen/earth2.img,sda1,w']

Modified and works:

disk = ['file:/mnt/share1/xen/earth2.img,xvda,w']

I just want to be able to create Ubuntu 10.04 x86-64 images without modifying any disk settings.

How can I tell Cloudmin to automatically setup the Xen Instances from my Image as xvda instead of sda1?


Well I am glad we are on the same track.

Unfortunately there is no Image format field that shows (see attached)

I chose single partition since the whole disk errors as shown in the attachment.


Ok, I think I see what is going on here now - the Ubuntu image is a single filesystem, but the /etc/fstab file refers to /dev/xvda while is typically the device for a whole disk! This works, but is a very odd setup .. certainly something that wouldn't be possible on a real system.

I have a Cloudmin fix for it that will go into the next release. The work-around till then would be to modify /etc/fstab to be like :

/dev/xvda1 / ext3 defaults 0 0

and in the Xen config :

disk = ['file:/mnt/share1/xen/earth2.img,xvda,w']

assuming the VM boots OK, create a new image from it and you should be good to go.

Hi Jamie,

I tried your suggestion but unfortunately I am hitting the same roadblock with root access via xm console not recognizing the password... Even with the /etc/fstab and .cfg changes you prescribed in place, I still received the "I don't know how to handle files with mode 81a4" message (see attached).


When is the next release scheduled for? Or do you know of any plans to make a Ubuntu 10.04 amd64 image available like the other Grade A supported systems?



P.S. I would be happy to make my stacklet bz2 available for you guys for Ubuntu Lucid LTS x86-64.

Looks like the image format is still not what Cloudmin expects..

If you like, I'd be happy to login to your system myself to debug this further.

I logged in, and fixed the format for the "Stacklet-Ubuntu-1004-amd64" image from whole-disk format to single partition (which is what it really should be). Once this was done, I was able to create a VM called jamietest that appeared to get its password set just fine (but cannot be pinged for some reason, which I assume is unrelated).

Hi Jamie,

Thx for checking things out. Unfortunately, I am all too familiar with why it is not pingable. The disk of jamietest is unrecognized as shown in the attachments.

The fix to this is to modify the .cfg file disk to sda or xvda.


I think the Grub config also needs to be adjusted .. fixing that now..

Ok, it looks like the Grub config in the image had the same problem of referring to /dev/xvda instead of /dev/xvfa1. Once I fixed that, I was able to change the Xen config file back to using sda1 instead of sda, and it booted OK.

I suggest you use the jamietest VM to create a new image, and then use that to create additional VMs.

The next Cloudmin release will fix up grub.conf to avoid this issue..

You are the man Jamie!

I created a new image from jamietest and successfully created a new instance from it. It is pingable and I can login via root right after creation!!!

Thank you very much!


Automatically closed -- issue fixed for 2 weeks with no activity.