On Fri, Jun 22, 2012 at 8:34 AM, Tom H <[log in to unmask]> wrote:
> On Fri, Jun 22, 2012 at 8:19 AM, Nico Kadel-Garcia <[log in to unmask]> wrote:
>> On Thu, Jun 21, 2012 at 8:15 PM, Adam Bishop <[log in to unmask]> wrote:
>>>
>>> 1) Disable the old OS's swap partition
>>> 2) DD the install DVD to the former swap partition
>>
>> I'm going to be *really surpised* if you've got a swap space big
>> enough for a 4.7 Gig DVD image.
>
> Thought the same when I read this but the boot iso should fit in.

True. Some folks don't use swap partitions, especially in "VPS"
setups. They cost disk space and swap space can be created as files
when needed without having to reserve a partition. And network traffic
can cost money on VPS's, too.

If you're a complete weasel, you can do what I did in 2001:

    Build a stripped down base OS image on a local disk, or these days
on a local virtual image.
    Turn if off, and rsyinc it *all* to a working directory, except
for sytem mount points like "/proc" and "/sys"
    In the directory, use "chroot" to enter it and edit local settings.
        Especially modprobe.conf to load all the necessary drivers and
build a new initrd.img.
        Edit /etc/sysconfig/network-scripts to define your network
settings and avoid locking network ports to specific MAC acddresses.
    Tarball up the image.
    Transmit the *tarball*, which is *much smaller* than installation
media, to the remote server.
    Disable swap and format the swap partition.
    Put the image in the swap partition.
    Use chroot inside the swap partition to install a new boot loader with grub.
        This is the delicate and dangerous part!!!!!
    Reboot to the tarball based image.

Unfortunately, grub does not have the LILO feature of "set the default
sttings to the old option, but boot the next time only with these new
settings", so my old failure recover trick for these setups and for
kernel updates doesn't work any longer. I miss that LILO setting, it
saved my bacon a few times when new kernels had some very strange disc
ordering issues or driver issues with some of the weirder hardware.

I did this to 15,000 corporate servers in one month in 2001, servers
with heavily customized kernels and some very odd dual-boot setups for
Windows. Using the sripped tarballs instead of installation media let
me shrink the transmitted data down to 100 MBytes and install to
remote sites with 1000 msec ping times. (Someone had cut one of the
trans-atlantic cables to China, so bandwidth to some hosts was
horrible.)

And it is *MUCH*, *MUCH*, *MUCH* faster than anything that relies on
anaconda for the initial package management and installation.