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
