installer maintenance issues (was: buildinstall problems with 7.3)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue Nov 19 2002 at 17:01, Danny Yee wrote:

> I'm trying to build a 7.3 install setup (largely for network installs),
> but buildinstall is creating the floppy images but not netstg1.img etc.
> It's failing with

> sed: couldn't write 71 items to {standard output}: No space left on device

> I know this means I'm trying to put too much onto the images, but I
> can't work out why...  i386/RedHat/RPMS is just a full set of updated
> 7.3 RPMS -- no customised RPMs at all -- and buildinstall used to
> work just fine on it.

On Tue Nov 19 2002 at 01:24, Michael Fratoni wrote:

> The latest kernel packages are too big, if I recall correctly.

Oh dear, I missed that one.  I tripped over it when I tried a
rebuild myself last night.  (I hadn't rebuilt the 7.3 installer
since before the update to the 2.4.18-17 kernel).  Ouch, that's a
nasty problem.

  I clearly recall when an update to rpm for rh6.2 totally broke the
  ability to create any more updated installation images.  Further
  updates needed the new version of rpm to recognise and install
  them, but it didn't work with the older installer.

Which perhaps brings up some important "maintenance" issues with the
installer.

After every redhat release follows the usual flurry of updates.
Lots.  It is the way of things.  It is a big management hassle on
already running boxes, and it is also a big problem when creating
and maintaining updated installer images.

This is a breakdown of the all updates since rh7.2:

		    sizes (Kb)		|	numbers
		 rh7.2	 rh7.3	 rh8.0	| rh7.2	rh7.3	rh8.0
athlon		 25368	 25368	 27060	|     2	    2	    2

i386		495220	216960	 86988	|   289	  116	   25
i586		 25396	 25396	 26704	|     2	    2	    2
i686		 69132   58996	 78792	|     7	    7	    5
noarch		 81900	   192	  2240	|    48	    1	    2

  subtotal:	704284	326916	221784	|   348	  128	   36
  
SRPMS		617476	274604	138468	|   136	   51	   10
  total:       1321760	601520	360252	|   484	  179	   46

  NB: This is what was current as of Sunday, it doesn't include any
  updates to previous (and now obselete) updated packages.

Ouch, now that's a lot of updates to worry about, and it gets worse
as time goes by... the (binary) updates to rh7.2 total 704Mb in 348
packages.

Redhat 7.x isn't going to disappear any time soon.

  (IMHO, rh8.0 is good in its own right, but it is definitely a
  typical x.0 release... after having a good look at it, I'm happy
  to keep using 7.x on my production boxes until 8.1 or 8.2 comes
  along).

One of the reasons many people build new installer images is to
allow them to have as many of the bugfix and security updates there
in a newly built system right from first boot (current as per when
the cdroms were burned, or when network images were prepared).

So if you are trying to keep up with things, you would be creating a
lot of different versions of installation cdroms as you went along.
Another week goes by, and your "latest version" is out of date.

Or worse... at some point along the way, the updates themselves
manage to break the installer or the ability to rebuild it.

So I'm thinking... why update the installer itself all the time?

Why not just put all the updates in one place and let the installer
handle the application of these updates?

  You could specify the location of these updates, either on another
  cdrom, hard drive, and nfs mount, or a http/ftp URL.

  The installer then checks for some sort of comps/hdlist database
  file(s) (or whatever would be appropriate) that some anaconda tool
  has created specifically for the purpose of allowing the installer
  to easily "blend" the updates into the installation.

  The updates can be all together in one directory, or laid out like
  the ftp update sites.  Any updates already in RedHat/RPMS/ are
  ignored.

  The installation then carries on as usual but substituting the
  updates packages as required.

  The packages could be dynamically substitued at install time with
  network installs, or they could be available on a local hard drive
  or even a second cdrom.

  Multiple update sources can be handled... it would need to handle
  a situation (as with rh7.2) where there may be many updates on
  more than one cdrom.

  In the case where the updates are not available until the end (eg,
  single cdrom install), then the anaconda equivalent of an rpm -Uvh
  is done at that time (using the cdrom with the updates on it).

Maintenance would then involve only having to maintain an updates
image, rather than being forced to always include them in the
installation image.

It all seems like a good plan to me.  Unless I'm missing something.


On Tue Nov 19 2002 at 17:33, Danny Yee wrote:

> Ok, so the updated kernel means things no longer fit.  Is there some
> way around this that doesn't involve reverting to an older kernels?

You might try trimming some of the packages (and/or parts thereof)
that are put into the installer.  What gets put into the images is
specified in /usr/lib/anaconda-runtime/upd-instroot, used by
mk-images{.<arch>}.  You could try modifying that - but you'll need
to be careful with what you remove, I'm sure things are pretty lean
as it is.  As long as the installer has everything it needs, you
might get away with crippling the rescue disk mode in some (minor?)
ways.

You could also try removing more of the lesser-used kernel driver
modules (or perhaps move them into the extra drivers images if there
is enough room).

but yuk, it's all turning into a bit of a hack :(

> Also, buildinstall isn't making hdstg1.img, netstg1.img, or stage2.img,
> though I wouldn't have expected there to be size limits on those.

Are these failing because of the previous failures?

> Danny.
> 
> I wrote:
> > I know this means I'm trying to put too much onto the images, but I
> > can't work out why...

Cheers
Tony





[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux