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

boot controller



Does anybody know where I should look for boot controller order in installer ?

Michael

-----Original Message-----
From: anaconda-devel-list-request redhat com
[mailto:anaconda-devel-list-request redhat com]
Sent: Tuesday, November 19, 2002 11:09 AM
To: anaconda-devel-list redhat com
Subject: Anaconda-devel-list digest, Vol 1 #178 - 4 msgs


Send Anaconda-devel-list mailing list submissions to
	anaconda-devel-list redhat com

To subscribe or unsubscribe via the World Wide Web, visit
	https://listman.redhat.com/mailman/listinfo/anaconda-devel-list
or, via email, send a message with subject or body 'help' to
	anaconda-devel-list-request redhat com

You can reach the person managing the list at
	anaconda-devel-list-admin redhat com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Anaconda-devel-list digest..."


Today's Topics:

   1. buildinstall problems with 7.3 (Danny Yee)
   2. Re: buildinstall problems with 7.3 (Michael Fratoni)
   3. Re: buildinstall problems with 7.3 (Danny Yee)
   4. installer maintenance issues (was: buildinstall problems with 7.3) (Tony Nugent)

--__--__--

Message: 1
Date: Tue, 19 Nov 2002 17:01:12 +1100
From: Danny Yee <danny anatomy usyd edu au>
To: anaconda-devel-list redhat com
Subject: buildinstall problems with 7.3

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

mke2fs 1.27 (8-Mar-2002)
Wrote /tmp/makebootdisk.tree.25443 (2052k compressed, 1402k free)
cp: writing `/tmp/makebootdisk.tree.25443/vmlinuz': No space left on device
sed: Couldn't close {standard output}
sed: couldn't write 71 items to {standard output}: No space left on device
sed: Couldn't close {standard output}
sed: Couldn't close {standard output}
sed: Couldn't close {standard output}
/ftp/redhat-7.3/i386/buildinstall.tree.20455/mk-images: Failed to copy messages
from /ftp/redhat-7.3/i386/RedHat/instimage/usr/lib/anaconda-runtime/boot/ to
/tmp/makebootdisk.tree.25443.

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.

Any idea what I could be missing?

Danny.
(maintainer of the RedHat mirror for the University of Sydney)




--__--__--

Message: 2
From: Michael Fratoni <mfratoni tuxfan homeip net>
To: anaconda-devel-list redhat com
Subject: Re: buildinstall problems with 7.3
Date: Tue, 19 Nov 2002 01:24:15 -0500

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 19 November 2002 01:01 am, 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
>
> mke2fs 1.27 (8-Mar-2002)
> Wrote /tmp/makebootdisk.tree.25443 (2052k compressed, 1402k free)
> cp: writing `/tmp/makebootdisk.tree.25443/vmlinuz': No space left on
> device sed: Couldn't close {standard output}
> sed: couldn't write 71 items to {standard output}: No space left on
> device sed: Couldn't close {standard output}
> sed: Couldn't close {standard output}
> sed: Couldn't close {standard output}
> /ftp/redhat-7.3/i386/buildinstall.tree.20455/mk-images: Failed to copy
> messages from
> /ftp/redhat-7.3/i386/RedHat/instimage/usr/lib/anaconda-runtime/boot/ to
> /tmp/makebootdisk.tree.25443.

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

- -- 
- -Michael

pgp key:  http://www.tuxfan.homeip.net:8080/gpgkey.txt
Red Hat Linux 7.{2,3}|8.0 in 8M of RAM: http://www.rule-project.org/
- --
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE92dkPn/07WoAb/SsRAgF9AJ42hllnS/qdvTn91lmJEhz3KqO04wCfWULg
SvzXALVOv4EaG8+GJ4aas1k=
=WSrw
-----END PGP SIGNATURE-----




--__--__--

Message: 3
Date: Tue, 19 Nov 2002 17:33:37 +1100
From: Danny Yee <danny anatomy usyd edu au>
To: anaconda-devel-list redhat com
Subject: Re: buildinstall problems with 7.3

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?

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.

Danny.

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




--__--__--

Message: 4
To: anaconda-devel-list redhat com
From: Tony Nugent <tony linuxworks com au>
Organization: Linux Works for network
Subject: installer maintenance issues (was: buildinstall problems with 7.3)
Date: Wed, 20 Nov 2002 02:22:16 +1000

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





--__--__--

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list redhat com
https://listman.redhat.com/mailman/listinfo/anaconda-devel-list


End of Anaconda-devel-list Digest





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