cloning LDOM fails
Hi,
I've created an initial ldom on a virtual disk device, /tank/ldom1.img, and then stopped the ldom, copied the image file to /tank/ldom2.img and then set up a second ldom to use the copy as it's root disk.
When I try to boot the second ldom I get the following error message:
{0} ok boot /virtual-devices@100/channel-devices@200/disk@0
Sun Fire(TM) T1000, No Keyboard
Copyright 2007 Sun Microsystems, Inc. All rights reserved.
OpenBoot 4.26.0.build_07, 2048 MB memory available, Serial #67284404.
Ethernet address 0:14:4f:2:ad:b4, Host ID: 8402adb4.
Boot device: /virtual-devices@100/channel-devices@200/disk@0 File and args:
The file just loaded does not appear to be executable.
{0} ok
What am I doing wrong? Is this even possible?
regards
matthew
# 1
Yes it's possible (I've done it on occasion).
Did you unbind the first domain after you stopped it ? I suspect that when you unbind the first domain you will get the same error. I think you are running into '6544963 vdisk can loose label when rebinding domain' which is fixed in OpenSolaris build 61 and will be in the next Update Release of S10.
Below is a way of getting around the problem (It's also mentioned in the LDoms Release Notes)
<PRE>
To prevent this problem, here is a script that will check if you are in the
case where the label will not be correctly validated during the next "ldm bind",
and if this is the case it will change the label and its checksum so that it
can be correctly validated.
What you have to do is to run the script on any file that has been used as
a virtual disk and for which the disk label or disk partitioning has been
changed. The script should be run right after the domain using the virtual
disk is unbound (ldm unbind) for the first time.
For example, if file <file> is used by a domain as a virtual disk and if
the Solaris system is being installed onto that virtual disk then you
should run the script after doing the first 'ldm unbind' on that domain.
Note that the script should be run before doing any 'ldm bind' otherwise you can loose the disk label.
The syntax to run the script is:./fcksum <file>
The script will first backup the existing label of the file in a file named
label.<file>.<day>_<time>. If the script has changed the label, you can
restore the original label by doing:
$ dd if=label.<file>.<day>_<time> of=<file> count=1 conv=notrunc
Here is the output you will get if your label is updated:
$ ./fcksum file
Backing up original label in label.file.070314_201917
Changing checksum
0x1fe: 0xe456 =0x6456
Changing dummy field
0x1b8: 0=0x8000
Label checksum has been updated
Otherwise if the label does not need to be updated, you will get:
bash-3.00$ ./fcksum file
Backing up original label in label.file.070314_201005
Label checksum is okay
The "fcksum" script is here:
====================== CUT HERE ===============================
#!/bin/ksh
file=$1
if [ -z "$file" ]; then
echo "usage: fcksum <file>"
echo
exit 1
fi
if [ ! -f "$file" ]; then
echo "usage: fcksum <file>"
echo
echo "<file> should be a regular file"
echo
exit 1
fi
backup=label.$file.`date +%y%m%d_%H%M%S`
echo "Backing up original label in $backup"
dd if=$file of=$backup count=1 2>/dev/null
(
cat <<EOM
*0x1fe>/s/c
*0x1b8>/s/d
##(<c&0x8000)>t
<c&0x7fff>c
<d^0x8000>d
.,<t="Changing checksum"
0x1fe,><t/w ><c
.,><t="Changing dummy field"
0x1b8,><t/w ><d
.,><t="Label checksum has been updated"
.,#><t="Label checksum is okay"
EOM
) | mdb -w $file
====================== CUT HERE ===============================
></PRE>
