[prev in list] [next in list] [prev in thread] [next in thread]
List: opensolaris-install-discuss
Subject: Re: [install-discuss] [osol-discuss] I want to understand 'Boot
From: "Johan Hartzenberg" <jhartzen () gmail ! com>
Date: 2008-08-10 19:19:15
Message-ID: 64e6648f0808101219w5cf04281g465865dd07c17509 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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
[Attachment #5 (text/html)]
<div dir="ltr">This interests me too. I don't have the answers, but can \
offer some of what I've learned.<br><br><div class="gmail_quote">On Sun, Aug 10, \
2008 at 5:32 PM, Uwe Dippel <span dir="ltr"><<a \
href="mailto:udippel@gmail.com">udippel@gmail.com</a>></span> wrote:<br> \
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); \
margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This is not so much a question of a \
specific problem, than one of concepts and limitations.<br>
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'.</blockquote> <div><br>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.<br> <br>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?<br><br>Off the top of my head a few reasons why a slice moved to a new system \
might not be bootable:<br> 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<br>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.<br> 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.<br> 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.<br>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.<br> 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.<br> </div><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"><br> 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'!<br> 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?</blockquote><div><br>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.<br> <br>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.<br> <br>I have moved my system from one hard \
drive to another folowing these steps:<br>zpool create -f NEWPOOL c0d0s0<br>lucreate \
-p NEWPOOL -n newBEname<br>luactivate -n newBEname<br>init 6<br><br>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.<br> \
<br>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.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid \
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> 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 </blockquote> <div><br>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.<br><br> </div> <blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;">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:<br>
/dev/dsk/c1d0s4 15G 8.5G 6.1G \
59% /<br>
/dev/dsk/c1d0s7 42G 36G 5.5G \
87% /export/home<br> 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).<br>
</blockquote><div><br>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.<br> \
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> 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.<br>
</blockquote><div><br>lucreate + luactivate does make a fully functional BE, but \
there are some dependencies left against the original BE (such as sharable file \
systems)<br><br>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.<br> <br>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.<br> <br>I've seen some people have made "flar into bootable \
CDs. This is handy for recovery, but fairly difficult, particularly for SPARC \
systems.<br></div></div><br>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.<br> <br>Cheers,<br> _hartz<br clear="all"><br>-- <br>Any \
sufficiently advanced technology is indistinguishable from magic.<br> Arthur C. \
Clarke<br><br>Afrikaanse Stap Website: <a \
href="http://www.bloukous.co.za">http://www.bloukous.co.za</a><br> <br>My blog: <a \
href="http://initialprogramload.blogspot.com">http://initialprogramload.blogspot.com</a><br>
</div>
_______________________________________________
install-discuss mailing list
install-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/install-discuss
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic