Does anybody know where I should look for boot controller order in installer ? Michael -----Original Message----- From: anaconda-devel-list-request@xxxxxxxxxx [mailto:anaconda-devel-list-request@xxxxxxxxxx] Sent: Tuesday, November 19, 2002 11:09 AM To: anaconda-devel-list@xxxxxxxxxx Subject: Anaconda-devel-list digest, Vol 1 #178 - 4 msgs Send Anaconda-devel-list mailing list submissions to anaconda-devel-list@xxxxxxxxxx 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@xxxxxxxxxx You can reach the person managing the list at anaconda-devel-list-admin@xxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx> To: anaconda-devel-list@xxxxxxxxxx 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@xxxxxxxxxxxxxxxxx> To: anaconda-devel-list@xxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxx> To: anaconda-devel-list@xxxxxxxxxx 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@xxxxxxxxxx From: Tony Nugent <tony@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/anaconda-devel-list End of Anaconda-devel-list Digest
