Ah ha!
There is a big difference between "reboot" and "init 6" (or
shutdown ...) on Solaris. When you "reboot" you essentially
unceremoniously kill all running processes and start over. If you take
the machine down nicely (init 5 / init 6), it runs all the "init
scripts" (now known as svcs) stop scripts, to supposedly come down
gracefully. This is especially important for databases, etc. When it
runs the milestone/xvm stop script, it removes the hypervisor, but
when it boots back up and runs the "start" script, it puts it back.
Finally I understand why it was one way in GRUB and another way booted.
I am going to venture a guess that that entire process needs to be re-
thought. I don't think it can be part of the milestone method, unless
the method can somehow check to see if its being disabled or just
stopped? (not a greenline expert)
Tommy
On Nov 5, 2009, at 2:50 AM, Gary Pennington wrote:
On Thu, Nov 05, 2009 at 02:10:57AM -0700, Tommy McNeely wrote:
I didn't set these. milestone/xvm was modifying my menu.lst every
time
I shut down and booted. I am not sure where the heck it came up with
those options. They are right, but the ttya-mode and ttyb-mode are
defaults, so they don't need specified, and as you pointed out,
spaces
are bad. The other thing I noticed missing with the $ZFSBOOTFS stuff.
(which was why it didn't boot)
milestone/xvm is also probably why every time I rebooted the memory
for my dom0 was cut in half. faulty logic there, it works awesome
when
you first enable it, but it has "start" and "stop" methods so they
run
every time the dom0 is booted, which was a lot cause I wanted my dang
console and I kept fighting for it.
Hi Tommy,
I'm sorry that you've had such a torrid time with milestone/xvm. I
think
your issues have been mainly caused by previously undetected problems
in bootadm which are/being fixed as follows:
Fixed in 127:
6890353 bootadm hypervisor enabling/disabling commands have issues
Awaiting integration approval into 128:
6896046 bootadm -m enable_hypervisor should modify current entry
It's not clear however whether or not there is still an unresolved bug
actually in the milestone/xvm service itself. The logic you describe
which attempts to calculate a sensible default value for dom0_mem will
only run if the suppplied dom0_mem parameter has a value of 0. If the
value is 0, then a default is calculated and svccfg is invoked to
update the service dom0_mem property so that it now has a sensible
default value. Thus, future invocations will not need to calculate a
default.
I think the problem is caused because the later bootadm invocation
fails. The service exits with SMF_EXIT_ERR_FATAL and this means that
the milestone sevice is in maintenance mode and so the new value
of the dom0_mem property is not propagated from the SMF data store
into
the running instance. It's possible on reboot that this may cause the
problem you describe.
Summary: I know that when bootadm is completely fixed, this won't be a
problem. I'm fairly sure that it's not a problem in 127, although
there
are other problems with bootadm which won't be fixed until 128.
Gary
I also found out, although I don't know why, once I removed
milestone/
xvm from the picture that the "order" of the XEN console variable
(console=com1,vga or console=vga,com1) will affect whether Solaris
can
use the serial console as well. You have to use console=vga,com1 on
the "kernel$ ...xen.gz" line.
I am not sure what else, but for sure I think milestone/xvm is to be
avoided in nv_126. I guess tomorrow in my copious free time, I will
try to figure out whether some of this has been fixed in 127+.
Tommy
On Nov 5, 2009, at 1:45 AM, Vikram Hegde wrote:
Hi,
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title os-nv_126-xen
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/os-nv_126
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B console=ttya, ttya-
mode='9600,8,n,1,-', ttyb-mode='9600,8,n,1,-'
module$ /platform/i86pc/$ISADIR/boot_archive
#---------------------END BOOTADM--------------------
The problem isn't that the properties ttya-mode aren't supported by
the kernel, the problem is the white space.
For the -B option you can have multiple options only if there is no
white space between them i.e.
-B prop1=value1,prop2=value2,... (or you can have multiple -B with 1
property each)
The whitespace bwetween the properties is causing GRUB to barf. If
the syntax were correct but the properties
were not supported by the kernel, it wouldn't cause any problems.
GRUB blindly passes properties
that are in the right syntax (either -B X=1,Y=2 or -B X=1 -B Y=2)
and the kernel will blindly
stick them in the device tree. It is upto some subsystem (or
possibly even a driver) to
read the property from the device tree. So there is no such thing as
an unsupported property.
Vikram
Tommy McNeely wrote:
On a whim, I ISO booted to OpenSolaris 10.02 125... imported the
rpool and look what menu.lst looks like:
r...@opensolaris:~# cat /rpool/boot/grub/menu.lst
#splashimage /boot/grub/splash.xpm.gz
#background 215ECA
timeout 30
default 2
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title OpenSolaris 2009.06
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/opensolaris
#splashimage /boot/solaris.xpm
#foreground d25f00
#background 115d93
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS -B
console=ttya
module$ /platform/i86pc/$ISADIR/boot_archive
#---------------------END BOOTADM--------------------
#splashimage /boot/solaris.xpm
#foreground d25f00
#background 115d93
title os-nv_126
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/os-nv_126
#splashimage /boot/solaris.xpm
#foreground d25f00
#background 115d93
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B $ZFS-BOOTFS -B
console=ttya
module$ /platform/i86pc/$ISADIR/boot_archive
#============ End of LIBBE entry =============
#---------- ADDED BY BOOTADM - DO NOT EDIT ----------
title os-nv_126-xen
findroot (pool_rpool,0,a)
bootfs rpool/ROOT/os-nv_126
kernel$ /platform/i86pc/kernel/$ISADIR/unix -B console=ttya, ttya-
mode='9600,8,n,1,-', ttyb-mode='9600,8,n,1,-'
module$ /platform/i86pc/$ISADIR/boot_archive
#---------------------END BOOTADM--------------------
r...@opensolaris:~#
I *see* said the blind man, I think I will disable milestone/xvm
and do it manually for now :)
_______________________________________________
xen-discuss mailing list
xen-discuss@opensolaris.org
--
Gary Pennington
Solaris Core OS
Sun Microsystems
gary.penning...@sun.com
_______________________________________________
xen-discuss mailing list
xen-discuss@opensolaris.org
