Is this a permanent decision - Grub doesnt work with earlier intel desktop boards

Alan Cox wrote: It doesn't work on my FIC SS7 board either. I forget the number, but it's the one w/ 2MB cache. This was filed in bugzilla somewhere for the first RHL that used grub. -Thomas

Its been filed since the first release we ever did including Grub.

Is there a new option in grub equiv to lilo -R ? That's what keeps me from using grub, especially when doing remote kernel upgrades. Dan On Mon, 2003-09-29 at 16:57, Thomas Dodd wrote:

On Mon, 29 Sep 2003 18:23:55 -0500 Daniel Wittenberg <daniel-wittenberg(a)starken.com&gt; wrote: Yes, "savedefault" grub shell command has a "--once" option which does the same thing. Cheers, Sean

Alan Cox wrote: Also does grub do the right thing when you are using software raid? In the past grub didn't install on both drives boot sectors. In addition grub installs fail on really large (1.6T) 3ware raid arrays under RHL-9. I can't really test it as I can't reinstall my main file server. -- Once you have their hardware. Never give it back. (The First Rule of Hardware Acquisition) Sam Flory <sflory(a)rackable.com&gt;

Michel Alexandre Salim said: [snip] Anaconda will read the image file when doing network updates (and probably HD): http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/install-guide/s1-be... All one URL. "Additionally, if a file called updates.img exists in the directory from which you install, then it will be used for installation program updates. Refer to the file install-methods.txt in the anaconda RPM package for detailed information on the various ways to install Red Hat Linux, as well as how to apply the installation program updates." -- William Hooper

Hi All, Sorry for a newbie question. But, I only have a CD burner with my iBook (running OS X). How can I add the updates.img to the ISO consisting of the redhat/base directory? I do not have floppy drive neither. Best Regards, Andy On Tuesday, September 30, 2003, at 08:59 PM, Jeremy Portzer wrote:

Lamar Owen wrote: Sometimes a BIOS upgrade does that things run better, or worse ;-). -- SCO before, Smoking Crack Often now.

On Tue, 2003-09-30 at 04:13, Michel Alexandre Salim wrote: Where are the images for the test 2 version 9.0.94 of severn? I hove looked, but I only see 9.0.93 available. -- Bradley D. Pierson <bpierson(a)charter.net&gt;

On Sep 29 Michael Fulbright wrote: Not strictly related, but I've been thinking for a while now that most people do CD installs and watch the CD LED flash, then the HDD LED. This alternating is a bottleneck which I guess can be reduced by either or both of: 1. introduce extra threads to pre-cache the next files from install media (may be a help over the network too) while current RPM is installing 2. mount the ext3 target volumes ext2 while installing (this could still apply in days of dir_index and ACLs) Is Bugzilla the place for these ideas?

[snip] FWIW, My modus operandi for betas is this: 1) Fetch the ISOs from somewhere. With my net link this is pretty quick. 2) Burn the CDs. 3) Back up interesting stuff in my home dirs. 4) Install fresh RHL from CDs. I usually install all pkgs, call me silly. 5) Restore my home dirs. 6) Register with RHN and use up2date for distro patches. At this point I'm very close to the vanilla distro so I have minimal maintenance overhead and max likelihood that everything works together. 7) Fetch source or RPMs or patches for stuff I'm particularly interested in that isn't part of the distro, such as ARM cross-compile toolchain for my Zaurus, and if it's broken, work it till it does what I want. 8) File bugs when I find 'em (including one of them just fixed in the anaconda update pushed out yesterday). 9) Rinse and repeat when the next release is available. I would think that many relative newbies fiddling with the beta play this way. Mark.

On Wed, 1 Oct 2003, Jeremy Katz wrote: The biggest rpm we have currently is 40 MB, and the average package size is 1.4 MB. More than half of the total rpm size is in rpms that are smaller than 10 MB. With a 128 MB recommended RAM size this should be problem-free from a caching point of view. Maybe a special rule could be added, to not pre-cache RPMs with a size larger than RAM_size/4. also, if the caching is done by copying the next rpm to HD while the rpm -i of the previous one is running then even if trashing happens, it will happen on the HD level, not on the CDROM level - and it's the CDROM that is the fundamental bottleneck of installs. it's not the HD that is keeping up things - it's the non-overlap of CDROM and HD IO that hurts. We use the CDROM, then we use the HD to install the rpm, then we use the CDROM again, etc. - instead of using them in parallel and cutting latencies into half. ext2/ext3 only speeds up the HD access (by a very small amount). Also, ext2/ext3 mostly differs in CPU overhead not IO overhead - and the install-to-hd process is mostly limited by IO latencies (disk seeks). Ingo

On Tue, 2003-09-30 at 18:45, seth vidal wrote: Yup, you're spoiled. ;) SO was I. I love NI! However, when I go into environments to teach classes and need to install a few machines, and they have a 10MB half-duplex network ... I start breaking out the CDs! -- Bill Anderson RHCE #807302597505773 bill(a)noreboots.com

Ingo Molnar wrote: I wouldn't expect much gain if the CD is the slave device and the HD the Master on 1 IDE channel. I know lot's of systems setup like that. My normal system has to HDs with software raid, both masters, So the CD has to be a slave device. Both HDs are masters to improve their performance, it sucked when they were on the same channel. Fetching the next RPM while installing one would likely help for network installs. For local installs, HD or CD, should probably check the devices to see if they are a master/slave pair (hda+hdb, hdc+hdd, etc). Not sure how to find the underlying devices for a raid device though. -Thomas

I did some quick profiling with oprofile of an anaconda install and the vast majority of the total install time is spent waiting in the idle loop in the kernel. However I was doing an NFS install, which is pretty much reading the RPM over the network and exploding it to disk. The bytes/sec we were exploding RPMs in anaconda was about 50% of what you get if you just 'rpm2cpio | cpio -dimv ' the same RPMs to the drive (I tried this as a test). Its something we want to revisit when we have time. To be honest you're only reinstalling once ever 6-12 months and then using up2date to keep the system current, so it hasn't been a high priority to reduce the install time by 30% as compared to clearing out as many bugs and adding features which will make anaconda most useful. I'll be happy the day all the complaints about anaconda are just performance related. Michael Fulbright msf(a)redhat.com

On Tue, 2003-09-30 at 20:45, seth vidal wrote: Yes, unfortunately ;) Jeremy

Lamar Owen wrote: This board works well with grub with a BIOS flash to the latest version. I performed this BIOS upgrade to run the PII 333Mhz OD procs, and grub has no problems. -- Kind Regards, Michael Shuler :: michael(a)unixtx.com UNIX Administration Solutions :: http://unixtx.com

On Wed, 1 Oct 2003, Ingo Molnar wrote: <snip> Not that it would be impossible to do, but any sort of approach that interleaves cdrom and hd i/o is going to have to take into account switchinig of cdroms. Also, and correct me if a I am wrong but all the rpm's are installed as one transaction using librpm. Basically, a transaction of all the rpms that you need is built, and then ran. Anaconda passes to librpm a callback such that anaconda can report status, and switch cdroms for RPM (sick but its true (-;). In order to interleave the cdrom access (which is mainly for reading rpms) I think you would somehow have to drill something into rpm to allow for this, as its ultimately the one reading from the cdrom, and then installing to the system. If you followed the pattern of what is done for the cdrom change, you would have to add another callentry point that would get called before the rpm is opened for reading, that would pass pass filehandle back to rpm (this is what is done to allow for cdrom changing). This is of course convoluted and unless it was somehow made optional such that it only occured in the anaconda environment (i.e. anaconda turned this "feature" on) then it would break everything using librpm to install packages. The other approach would be to add threading to rpm. Now I know Jeff Johnson has been looking into doing that in order to do parallel installs of packages, but I don't think he was thinking of having a seperate thread to read an rpm, and another to output it to the disk (simplified I know). Anyway, all I am really trying to express that the road to what you are wanting to do would ultimately produce convolutions that will either make rpm or anaconda or both harder to support for very limited gains. Probably, Jeff's work toward's parallel installs will actually give you some of what you want as the psm threads (package state machine) would likely most of the time be interleaving (though not on purpose) cdrom and disk i/o. This path that Jeff is taking has its own set of gotchas mainly centered around the fact that it means that scriplets that modify things on the system need to employ some sort of locking mechansim to make sure no two scriptlets touch the same file at the same time. This though is not a problem for rpm to solve as scriptlets are opaque (as they should be) but for designers of rpms to solve. Well I have probably said to much and not enouugh, but I hope this sheds at least some light. Cheers...james

On Thu, 2003-10-02 at 18:30, Mark Heslep wrote: Yes, it is completely 100% necessary. It contains the kernel and some of the modules are on the boot CD and some are contained on the second stage. You can't load modules compiled for one kernel on another and actually expect things to work (and without the second stage modules, you don't have useful things like ext3) Not to mention changes within the loader which require corresponding second stage changes. Jeremy

I greatly prefer network installs myself. I only burn CD 1 to have a rescue CD. Bob Tom Diehl wrote: -- Bob Cochran Greenbelt, Maryland, USA http://greenbeltcomputer.biz/