[one-users] OpenSuse 11 as guest + ro boot parameter

Ruben S. Montero rubensm at dacya.ucm.es
Mon Nov 17 03:24:08 PST 2008


Hi,
	You are totally right, OpenNebula should not put "ro". In fact there is a 
kernel_cmd attribute for the OS that can be used to pass additional arguments 
for the kernel command line. We are fixing some bugs regarding this, and we'll 
let you know when its  ready. The VM template'd be:

OS = [
  kernel   = "/vmlinuz",
  initrd   = "/initrd.img",
  root     = "sda1", 
  kernel_cmd ="ro" ]

Also, you are right for the upcoming release 1.2 we will improve the doc so VM 
template attributes are better explained (meaning, and drivers supported)

Thanks

Ruben


    

On Monday 17 November 2008 06:32:23 Marcos Dias de Assuncao wrote:
> Hi guys,
>
> I am working with Alexandre Di Costanzo, who has sent some messages
> to the list before.
>
> We are using OpenNebula with OpenSuse 11, Ubuntu 8.04 and Xen 3.2.
> Some of our hosts run OpenSuse whereas others run Ubuntu. We have
> created Ubuntu paravirtualized images and OpenSuse images to run as
> guests. We  do not have problems scheduling the Ubuntu virtual
> machines, but we have encountered some issues with OpenSuse. So, we
> thought that it would be interesting to post something about the
> problem to the list and check if other people have had the similar
> problems and get some help.
>
> When OpenNebula generates the deployment file (i.e. xen guest
> description file), it appends 'ro' to the description of the file
> system to be mounted as root. In this way, if I specify an image to
> be mapped to hda1, the deployment file will contain something like
> "root = '/dev/hda1 ro'". We believe this is to force fsck to check
> the file system at boot time. Ubuntu images are pretty ok with that,
> but our OpenSuse images do not seem very happy in mounting the file
> system as read-only during boot.
>
> We have performed some tests with some Xen guest description files
> for OpenSuse and it works only if we specify 'rw' as the boot
> parameter for 'root=' or nothing, which will assume 'rw' I guess. For
> example, one description file that works is the following:
>
>
>
> kernel      = '/boot/vmlinuz-2.6.25.18-0.2-xen'
> ramdisk     = '/boot/initrd-2.6.25.18-0.2-xen'
> #root        = '/dev/hda1'
> root        = '/dev/hda1 rw'
> name="susebox"
> memory=256
> vcpus=1
> on_poweroff="destroy"
> on_reboot="restart"
> on_crash="destroy"
> disk=[ 'tap:aio:/path/to/file/OpenSuse11.img,hda1,w']
> vif=[ 'mac=00:16:3e:01:01:06' ]
> extra = '3 console=xvc0'
>
>
>
> The configuration above works fine, but if we change (root = '/dev/
> hda1 rw') to (root = '/dev/hda1 ro'), we get OpenSuse complaining
> about file permissions and finally hangs at the initialisation of HAL
> daemon. Part of the output is  shown below:
>
>
>
> rm: cannot remove `/success': Read-only file system
>                                                                        f
> ailed
> Mounting local file systems...
> mount: according to mtab, proc is already mounted on /proc
>
> mount: according to mtab, sysfs is already mounted on /sys
>
> mount: according to mtab, debugfs is already mounted on /sys/kernel/
> debug
>
> mount: according to mtab, udev is already mounted on /dev
>
> loop: module loaded
> mount: according to mtab, devpts is already mounted on /dev/pts
>
> nothing was mounted
> failed
> mv: cannot move `/var/log/boot.msg' to `/var/log/boot.omsg': Read-
> only file system
> Creating /var/log/boot.msg
> Can't open or create /var/run/klogd.pid.
> done
> /etc/init.d/boot.klog: line 39: /var/log/boot.msg: Read-only file system
> touch: cannot touch `/var/run/utmp': Read-only file system
> chmod: changing permissions of `/var/run/utmp': Read-only file system
> chown: changing ownership of `/var/run/utmp': Read-only file system
> chown: changing ownership of `/tmp': Read-only file system
> chown: changing ownership of `/tmp/.X11-unix': Read-only file system
> chown: changing ownership of `/tmp/.ICE-unix': Read-only file system
> chown: changing ownership of `/var/tmp': Read-only file system
> chown: changing ownership of `/var/tmp/vi.recover': Read-only file
> system
> chown: changing ownership of `/var/run/uscreens': Read-only file system
> chown: changing ownership of `/var/run/screens': Read-only file system
> Setting up hostname 'opensuse'
> done
> Setting up loopback interface     lo
>      lo        IP address: 127.0.0.1/8
>                IP address: 127.0.0.2/8
>                                                                        d
> one
> Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
> Configuring serial ports...
> Configured serial ports
> done
> Activating remaining swap-devices in /etc/fstab...
> done
> Setting current sysctl status from /etc/sysctl.conf
> net.ipv4.icmp_echo_ignore_broadcasts = 1
> net.ipv4.conf.all.rp_filter = 1
> fs.inotify.max_user_watches = 65536
> net.ipv4.conf.default.promote_secondaries = 1
> net.ipv4.conf.all.promote_secondaries = 1
>                                                                        d
> one
> Enabling syn flood protection
> done
> Disabling IP forwarding
> done
>                                                                        d
> one
> System Boot Control: The system has been
> set up
> Skipped
> features:
>   boot.cycle
> System Boot Control: Running /etc/init.d/boot.local
> done
> blogd: no message logging because /var file system is not accessible
> INIT: Entering runlevel: 3
> blogd: can not open /var/run/blogd.pid: Read-only file system
> Boot logging started on /dev/xvc0(/dev/console) at Tue Nov 18
> 03:22:02 2008
> Master Resource Control: previous runlevel: N, switching to runlevel: 3
> Starting D-Bus daemonFailed to start message bus: Failed to bind
> socket "/var/run/dbus/system_bus_socket": Read-only file system
>                                                                        f
> ailed
> Starting ConsoleKit
> done
> Loading CPUFreq modules (CPUFreq not supported)
> Starting HAL daemon
>
>
> If we try to start the same OpenSuse image with an Ubuntu's kernel,
> it actually boots, but then we have other problems with some modules.
> I am just wondering if anybody has faced a similar problem?
>
> Also, just one last thing. About the NIC option in the VM template. I
> am just wondering, it might be interesting to add a description to
> the documentation saying which drivers use the SCRIPT option.
>
> Thanks for your support,
>
> Marcos
>
>
> Marcos Dias de Assuncao
> Grid Computing and Distributed Systems (GRIDS) Laboratory
> Department of Computer Science and Software Engineering
> The University of Melbourne, Australia
> Email: marcosd at csse.unimelb.edu.au
>
> -------------
> "The bankers own the earth. Take it away from them, but leave them
> the power to create money, and with the flick of the pen they will
> create enough money to buy it back again.
> However, take away from them the power to create money, and all the
> great fortunes like mine will disappear and they ought to disappear,
> for this would be a happier and better world to live in. But, if you
> wish to remain the slaves of bankers and pay the cost of your own
> slavery, let them continue to create money."
>
> Sir Josiah Stamp
> Former Director of The Bank of England
>
> _______________________________________________
> Users mailing list
> Users at lists.opennebula.org
> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org

-- 
+---------------------------------------------------------------+
 Dr. Ruben Santiago Montero
 Associate Professor
 Distributed System Architecture Group (http://dsa-research.org)

 URL:    http://dsa-research.org/doku.php?id=people:ruben
 Weblog: http://blog.dsa-research.org/?author=7
             
 GridWay, http://www.gridway.org
 OpenNEbula, http://www.opennebula.org
+---------------------------------------------------------------+




More information about the Users mailing list