The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
We've put together an update image to address some of the issues which have been reported against anaconda. Depending on what kinds of problems pop up we will consider making another update at a later date.
Please report any problems with this update to bugzilla, and if the update fixes a problem you reported previously please update that bug report with the new information.
The update is available at: http://people.redhat.com/~msf/severn-test2-updates.img
Here is the README for the update: (http://people.redhat.com/~msf/severn-test2-updates.readme) ------------------------------------------------------------------------------- This is an updates image for Fedora Core Severn Test 2 which corrects problems in the anaconda installer.
To use this image use the following command line:
dd if=severn-test2-updates.img of=/dev/fd0
to write the image to a floppy disk. The contents of the disk will be destroyed.
Then boot the installation media and at the command prompt enter 'linux updates'.
At the appropriate time you will be prompted to insert the updates floppy.
For other install methods if the severn-test2-updates.img file is renamed to 'updates.img' and put in the RedHat/base/ directory of the install tree it will be used automatically w/o the need to use a floppy disk.
--------------------
Update Image Version: 1.0
Issues Addressed: -----------------
- Bugzilla #105586 - kickstart install fails with probed monitor - Bugzilla #105765 - couldn't get past text mode firewall screen if fw enabled - Bugzilla #105811 - text mode upgrade traceback - Bugzilla #105148 - In GUI install 'No firewall' option was ignored - Fixed an issue where lilo was being referenced (it is no longer shipped)
----------------- -------------------------------------------------------------------------------------------
Michael Fulbright msf@redhat.com
On Mon, 2003-09-29 at 17:34, Alan Cox wrote:
Is this a permanent decision - Grub doesnt work with earlier intel desktop boards
Please bugzilla against grub if it isn't already. It sounds like a grub bug we need to get fixed.
Its been filed since the first release we ever did including Grub.
Alan Cox wrote:
On Mon, 2003-09-29 at 17:34, Alan Cox wrote:
Is this a permanent decision - Grub doesnt work with earlier intel desktop boards
Please bugzilla against grub if it isn't already. It sounds like a grub bug we need to get fixed.
Its been filed since the first release we ever did including Grub.
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.
Also does grub do the right thing when you are using software raid?
I dont know if it has been fixed or not
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.
I've seen that reported before but never had a chance to find out. There are several reports which don't mention 3ware and grub has had some signed v unsigned problems fixed so it may be this problem is fixed now.
(It has some 64bit issues too which will begin to bite at 2Tb (4T-sectors)
Alan Cox wrote:
- Bugzilla #105148 - In GUI install 'No firewall' option was ignored
- Fixed an issue where lilo was being referenced (it is no longer shipped)
Is this a permanent decision - Grub doesnt work with earlier intel desktop boards
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
On Mon, Sep 29, 2003 at 04:57:17PM -0500, Thomas Dodd wrote:
Alan Cox wrote:
- Bugzilla #105148 - In GUI install 'No firewall' option was ignored
- Fixed an issue where lilo was being referenced (it is no longer shipped)
Is this a permanent decision - Grub doesnt work with earlier intel desktop boards
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.
and doesn't work on the rpmfind.net box either, tyan thunder 100 dual-celeron
Daniel
On Mon, 2003-09-29 at 16:07, Daniel Veillard wrote:
On Mon, Sep 29, 2003 at 04:57:17PM -0500, Thomas Dodd wrote:
Alan Cox wrote:
- Bugzilla #105148 - In GUI install 'No firewall' option was ignored
- Fixed an issue where lilo was being referenced (it is no longer shipped)
Is this a permanent decision - Grub doesnt work with earlier intel desktop boards
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.
and doesn't work on the rpmfind.net box either, tyan thunder 100 dual-celeron
I had of those, it worked on mine.
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:
Alan Cox wrote:
- Bugzilla #105148 - In GUI install 'No firewall' option was ignored
- Fixed an issue where lilo was being referenced (it is no longer shipped)
Is this a permanent decision - Grub doesnt work with earlier intel desktop boards
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
On Mon, 2003-09-29 at 19:23, Daniel Wittenberg wrote:
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.
From the grub package changelog ;)
- add patch from GRUB mailing list from Keir Fraser to add a --once flag to savedefault function so that you can have the equivalent of lilo -R functionality (use 'savedefault --default=N --once' from the grub shell)
I need to get around to adding an easier way of doing this from grubby, but that does work even if a little painful.
Cheers,
Jeremy
On Mon, 29 Sep 2003 18:23:55 -0500 Daniel Wittenberg daniel-wittenberg@starken.com wrote:
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
Yes, "savedefault" grub shell command has a "--once" option which does the same thing.
Cheers, Sean
On Mon, 2003-09-29 at 23:34, Alan Cox wrote:
- Bugzilla #105148 - In GUI install 'No firewall' option was ignored
- Fixed an issue where lilo was being referenced (it is no longer shipped)
Is this a permanent decision - Grub doesnt work with earlier intel desktop boards
This is not -- by chance -- one of the cases where using the "d" parameter to GRUB's "install" command helps? From the documentation:
[...] If the option `d' is present, the Stage 1 will always look for the actual disk STAGE2_FILE was installed on, rather than using the booting drive. [...]
I think this should read "..., rather than using the drive GRUB thinks it booted from." instead.
Whenever I had problems with GRUB, reinstalling the MBR manually from the GRUB command line (from rescue CD or GRUB floppy) helped, e.g. like this (with separate /boot on first disk, first primary partition:
root (hd0,0) install /grub/stage1 d (hd0) /grub/e2fs_stage1_5 /grub/stage2 /grub/grub.conf quit
HTH, Nils
On Monday 29 September 2003 05:34 pm, Alan Cox wrote:
- Bugzilla #105148 - In GUI install 'No firewall' option was ignored
- Fixed an issue where lilo was being referenced (it is no longer
shipped)
Is this a permanent decision - Grub doesnt work with earlier intel desktop boards
I have several machines on which LILO works fine but GRUB does not. One is an HP NetServer LS2 5/133 dual Pentium, one is a dual PPro 200 SUperMicro P6DNE, and I'd have to look at the others to see. But one of the problem machines did get fixed; I had a ASUS P3B-F with a Promise Ultra 66 that GRUB just didn't like around, oh, 7.3 or so. The 8.0 GRUB works fine on it.
Lamar Owen wrote:
I have several machines on which LILO works fine but GRUB does not. One is an HP NetServer LS2 5/133 dual Pentium, one is a dual PPro 200 SUperMicro P6DNE, and I'd have to look at the others to see. But one of the problem machines did get fixed; I had a ASUS P3B-F with a Promise Ultra 66 that GRUB just didn't like around, oh, 7.3 or so. The 8.0 GRUB works fine on it.
Sometimes a BIOS upgrade does that things run better, or worse ;-).
Lamar Owen wrote:
dual PPro 200 SUperMicro P6DNE,
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.
On Tue, 2003-09-30 at 04:21, Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
We've put together an update image to address some of the issues which have been reported against anaconda. Depending on what kinds of problems pop up we will consider making another update at a later date.
Hello,
Would it be possible to specify an update location from other medias (CD/network/HD)? Some newer laptops and PCs do not ship with floppy drives.
Thanks,
Michel
Michel Alexandre Salim said: [snip]
Hello,
Would it be possible to specify an update location from other medias (CD/network/HD)? Some newer laptops and PCs do not ship with floppy drives.
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-begin...
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."
On Tue, 2003-09-30 at 19:28, William Hooper wrote:
Michel Alexandre Salim said: [snip]
Hello,
Would it be possible to specify an update location from other medias (CD/network/HD)? Some newer laptops and PCs do not ship with floppy drives.
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-begin...
[snip] Ah yes, my mistake.
- Michel
On Tue, 30 Sep 2003, Michel Alexandre Salim wrote:
On Tue, 2003-09-30 at 04:21, Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
We've put together an update image to address some of the issues which have been reported against anaconda. Depending on what kinds of problems pop up we will consider making another update at a later date.
Hello,
Would it be possible to specify an update location from other medias (CD/network/HD)? Some newer laptops and PCs do not ship with floppy drives.
I think you forgot to read the entire announcement. Your question is answered already.
--Jeremy
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:
On Tue, 30 Sep 2003, Michel Alexandre Salim wrote:
On Tue, 2003-09-30 at 04:21, Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
We've put together an update image to address some of the issues which have been reported against anaconda. Depending on what kinds of problems pop up we will consider making another update at a later date.
Hello,
Would it be possible to specify an update location from other medias (CD/network/HD)? Some newer laptops and PCs do not ship with floppy drives.
I think you forgot to read the entire announcement. Your question is answered already.
--Jeremy
-- /---------------------------------------------------------------------\ | Jeremy Portzer jeremyp@pobox.com trilug.org/~jeremy | | GPG Fingerprint: 712D 77C7 AB2D 2130 989F E135 6F9F F7BC CC1A 7B92 | ---------------------------------------------------------------------/
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
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.
On Tue, 30 Sep 2003, Bradley D. Pierson 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.
Not sure what you're talking about exactly. The updated anaconda image is for test2; that's the only one available. The URL was given in the original message (http://www.redhat.com/archives/fedora-test-list/2003-September/msg02015.html ) as follows:
The update is available at: http://people.redhat.com/~msf/severn-test2-updates.img
Here is the README for the update: (http://people.redhat.com/~msf/severn-test2-updates.readme)
Also, the version number for Severn in the Fedora Core Test 2 release, is "0.94" -- there's no 9 at the start.
Hope this helps, Jeremy
On Sep 29 Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
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?
On Tue, 2003-09-30 at 19:18, Matt Bernstein wrote:
On Sep 29 Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
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:
do most people install off of cd?
I wish there was a way to measure that.
I might be spoiled but I've gotten used to network installs.
-sv
[snip]
do most people install off of cd?
I wish there was a way to measure that.
I might be spoiled but I've gotten used to network installs.
-sv
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 Tue, 2003-09-30 at 18:45, seth vidal wrote:
On Tue, 2003-09-30 at 19:18, Matt Bernstein wrote:
On Sep 29 Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
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:
do most people install off of cd?
I wish there was a way to measure that.
I might be spoiled but I've gotten used to network installs.
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!
I would say 90% of our installs are via the net. It is easier for us and the users to do this. We give our users the "net" floppy image and off they go. It would be good if your solution also made the network install faster too.
Connie Sieh Fermi National Accelerator Laboratory
On Tue, 30 Sep 2003, seth vidal wrote:
On Tue, 2003-09-30 at 19:18, Matt Bernstein wrote:
On Sep 29 Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
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:
do most people install off of cd?
I wish there was a way to measure that.
I might be spoiled but I've gotten used to network installs.
-sv
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
On Wed, 2003-10-01 at 14:14, Jeremy Katz wrote:
On Tue, 2003-09-30 at 20:45, seth vidal wrote:
do most people install off of cd?
Yes, unfortunately ;)
oh well.
moving right along.
/me goes back to his high bandwidth corner of the world.
-sv
On Tue, 30 Sep 2003, seth vidal wrote:
On Tue, 2003-09-30 at 19:18, Matt Bernstein wrote:
On Sep 29 Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
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:
do most people install off of cd?
I wish there was a way to measure that.
I might be spoiled but I've gotten used to network installs.
I don't think my company counts (seems like we are always going against the grain), but we do install off CDROM. Course it is the RH 9 set pared down to 1 CDROM with some custom rpms. The reason we do this over network installs is that our customized distro is for servers that we manufacture, and so making the manufacturing environment as simple as possible is very desirable. Also, we use the CDROM in a disastor recovery scenario, in that our kickstart will only blow away "core platform" partitions, and leaves application partitions intact. This allows us to re-install from the CDROM in the field without impacting application data...hopefully it would not come to that, but its a safe gaurd we put in place. The main reason I mention that is having everything contained to one or two CDROM's is quite handy for simplifying manufacturing and disaster recovery scenarios.
Cheers...james
-sv > >
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
I wish there was a way to measure that.
I might be spoiled but I've gotten used to network installs.
-sv
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
Yes same here. And in an attempt to be even lazier, is it absolutely necessary that the boot.iso image be non-compatible with every following release?* Would be nice not to have to reburn the boot.iso image with every release. Just download iso's to server, pop in existing boot CD, reboot and go. Yes I know part of the beta process is to test the latest Anaconda. Ive forgotten though with the stage 1, stage 2 boot blah blah how much of the installer is on the boot.iso image when the transistion is made to the main disk iso.
-Mark
* The error messsage is something like "Your boot media appears to not match the installation media"
On Thu, 2003-10-02 at 18:30, Mark Heslep wrote:
Yes same here. And in an attempt to be even lazier, is it absolutely necessary that the boot.iso image be non-compatible with every following release?*
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
On Tue, 30 Sep 2003, seth vidal wrote:
On Tue, 2003-09-30 at 19:18, Matt Bernstein wrote:
On Sep 29 Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
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:
do most people install off of cd?
Only if they do not have a network to install from. :-)
I wish there was a way to measure that.
+1
I might be spoiled but I've gotten used to network installs.
I cannot remember the last time I burned install cd's for my own use. ;)
I greatly prefer network installs myself. I only burn CD 1 to have a rescue CD.
Bob
Tom Diehl wrote:
On Tue, 30 Sep 2003, seth vidal wrote:
On Tue, 2003-09-30 at 19:18, Matt Bernstein wrote:
On Sep 29 Michael Fulbright wrote:
The amount of feedback we've received for the Fedora Core Severn Test 2 has been impressive. The anaconda team appreciates the time everyone has taken to test anaconda.
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:
do most people install off of cd?
Only if they do not have a network to install from. :-)
I wish there was a way to measure that.
+1
I might be spoiled but I've gotten used to network installs.
I cannot remember the last time I burned install cd's for my own use. ;)
On Tue, 2003-09-30 at 19:18, Matt Bernstein wrote:
- 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
We've discussed this some -- it's a little tricky to pull off sanely with all of the shenanigans necessary to keep bad CDs from causing tracebacks (and I can point to piles of bugs in previous releases until this is finally, I think hopefully, knock on wood, right now).
I also continue to think that the caching is going to trash things more and cause the actual package installation that's occurring + whatever %post (especially ldconfig) to be that much slower. Unfortunately, that's just a gut feeling that I can't back up until I have some spare time to do some dirt simple proof of concept benchmarking.
- mount the ext3 target volumes ext2 while installing (this could still apply in days of dir_index and ACLs)
We used to do this in the 7.2 timeframe, but the time difference on an install was negligible.
Is Bugzilla the place for these ideas?
Well, bugzilla's not great for discussion, really. If you have patches... ;) Discussion is easier to have either here or on anaconda-devel-list. Or even on IRC, though that's less good from an archival stance.
Cheers,
Jeremy
On Wed, 1 Oct 2003, Jeremy Katz wrote:
I also continue to think that the caching is going to trash things more and cause the actual package installation that's occurring + whatever %post (especially ldconfig) to be that much slower. Unfortunately, that's just a gut feeling that I can't back up until I have some spare time to do some dirt simple proof of concept benchmarking.
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.
- mount the ext3 target volumes ext2 while installing (this could still apply in days of dir_index and ACLs)
We used to do this in the 7.2 timeframe, but the time difference on an install was negligible.
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
At 03:05 -0400 Ingo Molnar 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.
Maybe "pre-cache until size > [some threshold]" ?
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.
Yes.. copy RPMs to a tmpfs volume. This would possibly depend on the target swap having been activated to prevent things going horribly wrong.
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).
I was thinking that ext3 writes couldn't return until metadata had been committed to real media, and that by aggressively write-caching ext2 might not need to. So, this is a different kind of I/O latency (one which may well be triggered by %post scripts). But if it was tried with no obvious performance gain, that is more pertinent than my guesswork!
Matt
Ingo Molnar wrote:
On Wed, 1 Oct 2003, Jeremy Katz wrote:
We used to do this in the 7.2 timeframe, but the time difference on an install was negligible.
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.
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
On Wed, 1 Oct 2003, Ingo Molnar wrote:
<snip>
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.
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
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
-- fedora-test-list mailing list fedora-test-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-test-list
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@redhat.com
Matt Bernstein 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:
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
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?
Yes. File it as RFE (request for enhancement). Only stuff that is in Bugzilla will reach all developers, on the mailing list it could easily be overseen.
Best regards, Martin Stricker