Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] ISO spell installation method (Was: [Private mail]Cauldron Team Email Meeting)

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Eric Sandall <eric AT sandall.us>
  • To: sm-discuss AT lists.ibiblio.org
  • Subject: Re: [SM-Discuss] ISO spell installation method (Was: [Private mail]Cauldron Team Email Meeting)
  • Date: Fri, 03 Jun 2005 14:05:38 -0700

Quoting Karsten Behrmann <BearPerson AT gmx.net>:
Hi everyone!
We're doing some thinking on the ISO team about where we should go and
be with the ISOs by 1.0.
As I'm doing the installer, I've done some thinking on how the installer
should install the spells. We're looking at several requirements:
1. Ease to maintain (fix and update)
2. Keep ISO size down
3. It should work

Yes.

Okay, let's summarize... we have several possibilities:
1. regular un-tar: (from cache tarballs)
PRO:
- standard method, might be the easiest to get going nicely with little
effort (so that we can concentrate on other, important stuff)
- been done before, so should work
CONTRA:
- un-elegant, inflexible and hard to maintain if coded badly

I believe the current ISOs are using this method.

2. regular un-tar using busybox
PRO:
- almost as easy as 1.
- smaller ISO
CONTRA:
- one more spell to specially configure for ISO use

And many less spells to actually install and worry about, so that more
than balance out, IMO.

- not all users may be familiar with the reduced capabilities (->rescue CD)

We could document the reduced features (which I can't recall ATM).

- still as inelegant

If we're to stay with method #1 for a while I'd prefer it to be moved to
method #2, if possible.

3. un-tar but copy everything already in the ISO system from there
(e.g. cp /bin/bash /mnt/root/bin/bash instead of untarring it)
PRO:
- standard method with some modification (pass through install log,
if it exists on the ISO, copy, then extract tarball)
- high reduction of ISO size
- might even be faster (not such a large data volume to unbzip2)
CONTRA:
- added code overhead (though should be condenseable to not many lines)
- rescueing a system using an ISO using tarball becomes a little harder,
we'll definitely need to provide a script to do it
- generating the cache tarballs gets a tad harder

I'd rather not use this method at all. It sounds more error prone than
any of the other methods for not much gain, IMO.

4. use the full sorcery suite to install_root resurrect cleanly
PRO:
- nice, standardized method
- uses code I don't have to write and maintain ;-)
- automatically takes advantage of POST_RESURRECT scripts
CONTRA:
- needs more programs on the ISO (cast needs make)
- reduced flexibility (e.g. we can't keep it from casting a dependency)

You'd never want it to /not/ install a dependency (unless it was
optional, but then just don't build it with that option).

- still a little bit non-intended use... resurrect is meant to restore,
not to install

Basically the same idea, IIRC.

5. make the ISO a full build system and INSTALL_ROOT
PRO:
- Really source-based
- ISO becomes more of a rescue disk when it can compile by itself
- extremely elegant

Yes. :)

CONTRA:
- Will probably be a hell of a lot of work getting it to run

I believe the 20040414 ISO was close to this setup, but I haven't looked
in a while.

- Even bigger ISO (though having net stuff on might enable us to download
the sources on install

Couldn't rely on that as some NIC adapters would need the source to able
to install.

- Very time-consuming install

Why would it be any more time consuming? The only part that would take
longer is building the ISO and downloading it, AFAIK.

- Also not quite flexible

How is it less flexible than any of the other options? It sounds more
flexible, to me, since then we'd have the full Sorcery suite capable of
doing what we desire: compile and install packages.

Okay, so much for a small overview of what I'm considering.
Now for what I'm thinking of implementing.

Currently, my main focus is to get a maintainable installer out ASAP.
This definitely rules out 5., which would require a good bunch of testing.

I would myself just go for 1., because it seems to me as the way that will
be quickest to just get to work, so that we can get on to make a nice
rest of the installer.
I know some people want me to do 4., but I'm not entirely comfortable that
it might not harbor some hidden ton of work. Also, I'd rather not have more
automatisms than I plan to. Also, even this method will still need
workarounds in the code (e.g. openssh key generation).

I thought the work you'd been doing was already down the path to method
#4? I'd say try for method #2 with the hopes of reaching method #4
before 1.0, but not required. Method #5 is more than I'd want in our
main ISOs, but perhaps later on we can have variations of ISOs, but
focusing on the "base" as outlined above.

If we eventually want to crank the ISO size down, I'd be more comfortable
with 3. than with 2., simply because
- I think 3. gives more of a gain
- I'd rather not get used to the reduced capabilities of the busybox tools
- It does not really seem so hard to
while read file ;do
if [ -e $file ] ;then cp --parents -f $file ${TARGET}
done <$install_log

It also neuters the ability to boot up the ISO and just restore a
tarball. AFAIK busybox is not very limiting for what a rescue CD is
meant to have (since it's main purpose is as a rescue tool). It can
even take care of some of the networking requirements and many of the
tools (make?, tar, gzip, bzip2, coreutils, etc.).

But I'd first just use the quick-and-dirty method 1.
I will try to code so that it can be easily ripped out and replaced by any
of the given methods, but I just want this baby out and running before I
start running through changes that might take a while.

That's the main priority (getting fixed ISOs out), I believe. :)

Of course, when there is sufficient opinion that I should do a different
method from the start, I'll bow to PL/TL/reason/the majority and work that
way.

Thanks for the summary. :)

-sandalle

--
Eric Sandall | Source Mage GNU/Linux Developer
eric at sandall.us PGP: 0xA8EFDD61 | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @
WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.





Archive powered by MHonArc 2.6.24.

Top of Page