This interests me too. I don't have the answers, but can offer some of what
I've learned.
On Sun, Aug 10, 2008 at 5:32 PM, Uwe Dippel <udippel at gmail.com> wrote:
> This is not so much a question of a specific problem, than one of concepts
> and limitations.
> If you look at the various posts of mine in here, I asked at different
> times on essentially the same topic: What constitutes a Boot Environment; in
> the meaning of 'how complete is it', can it be transferred?'. One of my
> questions was, why can I not transfer a full slice to another machine? The
> answers given were not fully on-topic, like 'use flash archive'.
I agree that it would not answer your question, but people sometimes try to
offer some help towards solving your problem even when they can not give you
all the answers, thus alternative methods are suggested.
In any case, you generally CAN transfer a slice. Whether that is all you
need to do to make a system bootable is another question. What is in the
slice? What file system is used on the slice?
Off the top of my head a few reasons why a slice moved to a new system might
not be bootable:
1. Entried in /etc/vfstab might not be valid on the new system - you will
need to carefully check this. In most cases, booting from a CD-rom you may
be able to edit these entries and fix them
2. If using ZFS as root file system you need to boot into failsafe mode and
mount the file system. This updates the physical device path to the disk
and after that the disk will probably be mountable.
3. Some of the boot phase information is not stored in the slice. Parts of
it is potentially in the disk boot block and/or the disk's master boot
sector. For this purpose you have to be very clear about the distinction
between a slice and an fdisk partition.
4. You should allow the system to re-create the device tree. On the first
boot you need to at least perform a reconfiguration boot.
5. Does the boot environment have any dependancies on anything on the
network, any specific hardware in the system, sound cards, graphic cards,
etc. You might think this is a simple answer, but when Sun says "You can
move the disk to another system and it will boot" it means ANYBODY with ANY
configuration can do it. Thus they will not lightly make such a promise.
6. OS versions and hardware are sometimes interlinked. A specific OS
version may not boot on older hardware, and most newer hardware require
new-ish versions of the OS to load. For you this may sound like a non-issue
when all your systems are similarly configured, but again Sun would rather
let you run the installer (eg with flar) than make a promise.
>
> I also asked about the comprehensive BE ('is it?'), when suggesting that -
> if it was comprehensive - ought to be bootable (e.g. VirtualBox). The
> answer, again, was a tad off-topic: 'boot from grub'!
> Also, with respect to liveupgrade, I do understand lucreate, as to write
> the current '/' to another slice. But I am told, you can't simply boot that.
> My question: why would that be?
I think with comprehensive you mean complete. What I understand from the man
page and my own recent experience is that lucreate does not blindly copy
everything to the target environment. You would have to dig into the LU
scripts executed at reboot time to see what exactly else is needed to make a
system bootable.
My understanding lucreate+luactivate is enough to build a bootable
environment, except for the sync-ing of a few files. These files are synced
when the new BE is booted - the start-up scripts in the new BE will go try
to find the files to sync from in the old BE and copy them over.
I have moved my system from one hard drive to another folowing these steps:
zpool create -f NEWPOOL c0d0s0
lucreate -p NEWPOOL -n newBEname
luactivate -n newBEname
init 6
In this situation, after completion, the new disk has got no dependancies on
the old disk - it can be moved to another system and booted there, but some
data are not automatically brought over by lucreate - in particular the
so-called non-critical (shareable) file systems such as /export will he used
from the source data.
So basically live-upgrade intentionally creates dependancies on the old BE
in the new BE - this is part of its design and intended way of use. LU is
not intended as a tool for "duplicating" systems for quick instalation. Sun
does include free tools for that purpose with Solaris - in particular
jumpstart and flar files.
> Then one can liveupgrade, fine, and then it is done? No, it seems:
> luactivate is needed. I'd understand, that some metadata need to be
> adjusted, like mounts and grub. is it bootable, then? No, I am told, one
> definitively needs some init 6. I still don't know why. I would like to
> understand this. I can do
When rebooting with init 6, certain additional scripts run during shut
down. One of these sets the "default" entry in the grub menu. check the
output from bootadm list-menu before rebooting.
> that with OpenBSD and Linux (of course, minus the liveupgrade), but as
> system admin I find it most suitable that partitions can be moved, and
> booted to (no need telling me slices are different, that arguments won't
> invalidate my question). Or slices, on BSD. When I look at my mount:
> /dev/dsk/c1d0s4 15G 8.5G 6.1G 59% /
> /dev/dsk/c1d0s7 42G 36G 5.5G 87% /export/home
> I have two slices that I use. Why would those not be straightforward
> mountable (like from grub menu?). If I lucreate /dev/dsk/c1d0s5, why not
> that one? I could understand if it was done on purpose, to avoid illegal
> cloning. But as of now, it seems SUN moves to FOSS. Nothing better and
> easier than allowing the creation of a BE, for whatever purpose, eventually
> backup, and then copying all data, and - voil? - , there it is, readily
> bootable. Even in a VM. After a luupgrade, no need to shut down, all the
> init 6 - hassle that tends tends to fail here and there (luckily not only
> with me), requiring arcane action; but rather just starting a VirtualBox,
> and see it coming up or not (without the /export/home).
>
Note: Solaris has been FREE for many many years (Since at least 2000) -
there is no illegal cloning or copying of the software. FOSS is more about
the software allowing freedom in terms of modifying and redistributing than
it is about software having a $ 0.00 price tag. But I don't understand the
rest of your paragraph, I think you are glossing over what is bothering you.
>
> I am asking also on the grounds, that to my understanding, a fully
> self-contained BE after lucreate or luupgrade would very much increase the
> attractiveness of OpenSolaris. It would simplify testing of an upgrade, just
> as deployment (at least on a bunch of identical hardware, like in a
> students' lab). No, please, don't tell me 'flash archive is much better'.
> That may be the case, but as of now, we have procedures in place to
> dump/restore full partitions and slices, and I am still curious why a
> Solaris slice doesn't seem to like the handling as a slice as a fully
> self-contained (boot-)entity.
>
lucreate + luactivate does make a fully functional BE, but there are some
dependencies left against the original BE (such as sharable file systems)
The flar tools makes an easily distributable "BE". You can put your flar
file on a flash drive, boot from a Solaris CD, then select the "install from
flar" option. This is available in the text-based installer. You then
point it at the flar file on the flash drive and it installs a clone.
The flar image further has got the advantage that the newly booted
environment will be "unconfigured" - it will prompt you on first start up
for a few thigns, like time zone, host name, network settings. The
assumption is that you may want to run multiple copies of that flar on the
same network.
I've seen some people have made "flar into bootable CDs. This is handy for
recovery, but fairly difficult, particularly for SPARC systems.
I hope that answers some of your questions. If not I'm sure other people in
this community knows better. I've CC'ed install-discuss.
Cheers,
_hartz
--
Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke
Afrikaanse Stap Website: http://www.bloukous.co.za
My blog: http://initialprogramload.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/install-discuss/attachments/20080810/e1a9c7ae/attachment.html>
