Can I get a beep on the screen that says click next to do the installation? Since at this point you have to wait for the dependency check to finish before you can click next for the install to run. That way I can get a 3 min. nap. :)
There are some other versions of Linux that ask you for everything and then they do the install and you don't have to sit and wait for any long steps.
On Fri, 2007-02-09 at 18:04 -0700, Jerry Williams wrote:
Can I get a beep on the screen that says click next to do the installation? Since at this point you have to wait for the dependency check to finish
Why do we even need to confirm the next step? I've had boxes sitting idle for hours at this step...
Richard.
Once upon a time, Richard Hughes hughsient@gmail.com said:
Why do we even need to confirm the next step? I've had boxes sitting idle for hours at this step...
I haven't looked at the anaconda source, but the process is package selection -> dependency checking -> ask ok to install. What if dependency checking fails for some reason? It may not be done asking questions at that stage.
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Chris Adams Sent: Friday, February 09, 2007 9:38 PM To: Development discussions related to Fedora Core Subject: Re: Wakeup alarm?
Once upon a time, Richard Hughes hughsient@gmail.com said:
Why do we even need to confirm the next step? I've had boxes sitting idle for hours at this step...
I haven't looked at the anaconda source, but the process is package selection -> dependency checking -> ask ok to install. What if dependency checking fails for some reason? It may not be done asking questions at that stage.
So if it fails another screen pops up and shows the problem and it sits for hours. How about a check box you can check to continue if no dependency problems. So package selection, check box -> dependency checking, no problems -> install
Jerry Williams
-- Chris Adams cmadams@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Friday 09 February 2007 23:37, Chris Adams wrote:
I haven't looked at the anaconda source, but the process is package selection -> dependency checking -> ask ok to install. What if dependency checking fails for some reason? It may not be done asking questions at that stage.
Also we don't know how many CDs you'll need before doing depchecking. We have to prompt you with how many you'll need so that you don't start the install and get asked for a CD you didn't download/burn.
Dnia 10-02-2007, sob o godzinie 09:10 -0500, Jesse Keating napisał(a):
We have to prompt you with how many you'll need so that you don't start the install and get asked for a CD you didn't download/burn.
No you don't. I haven't seen a multi-disk installation for a long time now. These days people either download single DVD or a "server CD". The prompt is useless when it requires just one disk (or an NFS/FTP directory).
Also, is there a way in F7 Anaconda to click "no, I don't have the fourth CD, deselect the packages and their dependencies"?
Lam
On Saturday 10 February 2007 14:35, Leszek Matok wrote:
No you don't. I haven't seen a multi-disk installation for a long time now. These days people either download single DVD or a "server CD". The prompt is useless when it requires just one disk (or an NFS/FTP directory).
Not everybody has DVD readers, and we may not have a single CD install set.
Also, is there a way in F7 Anaconda to click "no, I don't have the fourth CD, deselect the packages and their dependencies"?
You can hit cancel, go back and adjust your package selection.
On Sat, February 10, 2007 16:00, Jesse Keating wrote:
You can hit cancel, go back and adjust your package selection.
And how to you know what to deselect?
On Saturday 10 February 2007 18:05, Dimi Paun wrote:
And how to you know what to deselect?
You don't really, we don't indicate what packages are on which media. Maybe we should, but doesn't help when the package is on say media 1, but the deps of it which aren't visibly listed are on media 4.
Dnia 11-02-2007, nie o godzinie 10:14 -0500, Jesse Keating napisał(a):
You don't really, we don't indicate what packages are on which media. Maybe we should, but doesn't help when the package is on say media 1, but the deps of it which aren't visibly listed are on media 4.
That's why I said "deselect the packages and their dependencies".
That's also why I said that the "confirm CD list" step is useless - it's faster to download the complete set (or run minimal install) than to guess or somehow experimentally get to the packages you need to deselect.
Another method I've seen in an installer of some other distro is a list of media that I have. That would be one more step before package selection, which could also take an updates CD, some "extras" CD, drivers CD or any other yum repo. Then we could install anything from anywhere, provided we have the media available.
I understand adding any yum repo upon installation is not trivial (it can be inconsistent by itself, it can be conflicting with our packages and so on), but if we start from the media selection, it's a step forward. Also, that way, there's no need to ask the user to stay at the keyboard only to press "Next" after a very long depsolving, which this thread is all about.
Lam
On Sun, February 11, 2007 10:14, Jesse Keating wrote:
On Saturday 10 February 2007 18:05, Dimi Paun wrote:
And how to you know what to deselect?
You don't really, we don't indicate what packages are on which media. Maybe we should, but doesn't help when the package is on say media 1, but the deps of it which aren't visibly listed are on media 4.
Right. Which is why I think it's not fair to answer that the solution is to "go back and deselect the packages". It's just not something that people can do.
Once upon a time, Dimi Paun dimi@lattica.com said:
On Sun, February 11, 2007 10:14, Jesse Keating wrote:
On Saturday 10 February 2007 18:05, Dimi Paun wrote:
And how to you know what to deselect?
You don't really, we don't indicate what packages are on which media. Maybe we should, but doesn't help when the package is on say media 1, but the deps of it which aren't visibly listed are on media 4.
Right. Which is why I think it's not fair to answer that the solution is to "go back and deselect the packages". It's just not something that people can do.
If anaconda doesn't check which CDs will be required, users will get stuck half way through installation without a required CD. Right now, the only real solution at the CD check is to quit (before starting the actual install), but that is MUCH better than getting half way through install and aborting (probably leaving a mess).
-----Original Message----- From: fedora-devel-list-bounces@redhat.com [mailto:fedora-devel-list- bounces@redhat.com] On Behalf Of Chris Adams Sent: Sunday, February 11, 2007 11:33 AM To: Development discussions related to Fedora Core Subject: Re: Wakeup alarm?
Once upon a time, Dimi Paun dimi@lattica.com said:
On Sun, February 11, 2007 10:14, Jesse Keating wrote:
On Saturday 10 February 2007 18:05, Dimi Paun wrote:
And how to you know what to deselect?
You don't really, we don't indicate what packages are on which media.
Maybe
we should, but doesn't help when the package is on say media 1, but
the deps
of it which aren't visibly listed are on media 4.
Right. Which is why I think it's not fair to answer that the solution is to "go back and deselect the packages". It's just not something that people can do.
If anaconda doesn't check which CDs will be required, users will get stuck half way through installation without a required CD. Right now, the only real solution at the CD check is to quit (before starting the actual install), but that is MUCH better than getting half way through install and aborting (probably leaving a mess).
This is something that I have run into. It seems like the install is an all or nothing install. It seems like all of the tools like pirut and system-install-packages both need XWindows. If my install fails and I am left with just command line how do I finish getting things installed? It seems like the last thing that happens is the grub install. Seems to me that it would be better to get the base installed and working. Then if something doesn't work you still have a system that does. Is there a command line or tools that allow for something like: system-install-packages "GNOME Desktop Environment" that doesn't require a GUI?
Also when I install on a machine with Windows Grub lets me add that to my list of things I can boot from. But if I already have grub installed it doesn't seem to allow me to add it's configuration to the new one. I have been trying to be able to boot Fedora Core 5, Fedora Core 6 and Fedora 7 all on the same machine. It works, just that it requires a manual process. Can't grub or the installer see that grub is there and copy the current configuration to the new one or ask me if I want to?
I must have a flaky DVD drive, media passes the test, but some times install will fail at different places. FC5 chokes, FC6 will at least let you retry. So things are getting better.
Thanks to everyone for their help! Jerry Williams
Jerry Williams wrote:
This is something that I have run into. It seems like the install is an all or nothing install. It seems like all of the tools like pirut and system-install-packages both need XWindows. If my install fails and I am left with just command line how do I finish getting things installed? It seems like the last thing that happens is the grub install. Seems to me that it would be better to get the base installed and working. Then if something doesn't work you still have a system that does.
+1
Is there a command line or tools that allow for something like: system-install-packages "GNOME Desktop Environment" that doesn't require a GUI?
# yum groupinstall "GNOME Desktop Environment"
Paul.
On 2/11/07, Jesse Keating jkeating@redhat.com wrote:
On Friday 09 February 2007 23:37, Chris Adams wrote:
I haven't looked at the anaconda source, but the process is package selection -> dependency checking -> ask ok to install. What if dependency checking fails for some reason? It may not be done asking questions at that stage.
Also we don't know how many CDs you'll need before doing depchecking. We have to prompt you with how many you'll need so that you don't start the install and get asked for a CD you didn't download/burn.
So at by that stage of the installtion Anaconda doesn't know if it is doing a DVD install or network install or multi disk install?
-- Jesse Keating Release Engineer: Fedora
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Sunday 11 February 2007 20:40, Arthur Pemberton wrote:
So at by that stage of the installtion Anaconda doesn't know if it is doing a DVD install or network install or multi disk install?
There isn't currently a way to tell a difference between a CD and a DVD. Due to a logic flaw in how we've been composing, the same metadata from multiple CD set was used on the DVD as well. I'll be fixing this in Pungi, so that we have _some_ clue (all packages reference media1), but that won't help in the multiple DVD scenario, where the repodata is split again.
Jesse Keating jkeating@redhat.com writes:
Also we don't know how many CDs you'll need before doing depchecking. We have to prompt you with how many you'll need so that you don't start the install and get asked for a CD you didn't download/burn.
Anaconda can tell when this is not applicable, for example if it runs off of a DVD installation. Then this post-depcheck prompt is nothing but a waste of time.
Even if this prompting were applicable (for CD installs), is there data to support the intuition that the problem (not enough CDs downloaded) occurs frequently enough to justify the time waste imposed on those who do not make that mistake?
- FChE
On Monday 12 February 2007 10:32, Frank Ch. Eigler wrote:
Anaconda can tell when this is not applicable, for example if it runs off of a DVD installation. Then this post-depcheck prompt is nothing but a waste of time.
Due to a composing logic flaw in past releases, it was not possible to distinguish between CD media and DVD media. The same repodata was used. I'll be fixing that in pungi so that we can tell when we're on DVD vs CD, however since people want the monster spin of doom, we'll need to actually split across multiple DVDs so the problem is back.
Even if this prompting were applicable (for CD installs), is there data to support the intuition that the problem (not enough CDs downloaded) occurs frequently enough to justify the time waste imposed on those who do not make that mistake?
I go through this often enough. I burn one or 2 out of the 5, do some package selection, realize I have too much, go back and trim it down a bit.
I'm just stating why the check is there. Whether or not it should go away, I don't have a strong argument for either, I'm just stating why it is there now.
On Monday 12 February 2007 10:44, Jesse Keating wrote:
Due to a composing logic flaw in past releases, it was not possible to distinguish between CD media and DVD media. The same repodata was used.
Wait, this wasn't a logic flaw, this is done on purpose by design.
a better solution is to speed up the depsolving process somehow. maybe doing it with a plugin which is written in C like the metadata parser would help?
dragoran wrote:
a better solution is to speed up the depsolving process somehow. maybe doing it with a plugin which is written in C like the metadata parser would help?
The dependency resolving is done via RPM for the most part. The yum hackfest in FUDCon Boston 2007 recently was focused on generating and using the sqllite backend directly and fall back to parsing the metadata from XML only when the database content is outdated. That I heard has resulted in substantial performance boost. That along with a patch to use queries more effectively should make things better soon enough.
https://lists.dulug.duke.edu/pipermail/yum-devel/2006-December/002970.html https://lists.dulug.duke.edu/pipermail/yum-devel/2007-January/003071.html
Rahul
Rahul Sundaram wrote:
The dependency resolving is done via RPM for the most part. The yum hackfest in FUDCon Boston 2007 recently was focused on generating and using the sqllite backend directly and fall back to parsing the metadata from XML only when the database content is outdated. That I heard has resulted in substantial performance boost. That along with a patch to use queries more effectively should make things better soon enough.
https://lists.dulug.duke.edu/pipermail/yum-devel/2006-December/002970.html
https://lists.dulug.duke.edu/pipermail/yum-devel/2007-January/003071.html
ok thx for that info and the links will look at them.
Rahul
On 2/11/07, dragoran drago01@gmail.com wrote:
a better solution is to speed up the depsolving process somehow. maybe doing it with a plugin which is written in C like the metadata parser would help?
One thing that would really help, regardless of programming language (though C would be much faster), is to provide a "summary" of dependency relationships between packages on the discs.
It would be in a small, separate file. A simple binary format would make it very small for fitting into memory uncompressed (though it's not necessary). To save space, packages should be referred to by an indexing system (integer numbers) and not by name -- this could improve efficiency in other parts of the installer too, so a centralized lookup table should be there if it's not already. - The first thing it would have is a pre-computed installation order for the (very) minimal installation. For this subset of packages the installer should be doing no dep-checking, and it should be the first things installed (and on the first disc). - Packages which only rely on the minimal set are then listed in the file. The installer can now install any of these at any time without dep-solving. - The rest of the dependencies are then listed, in an installable order, for every package.
For example: The bare minimum install has the packages: A, B and C. There are also packages: D, E, F, G, H, I, J, K and L. Dependencies are as follows: A < B (this means B depends on A) A < C B < D C < D A < E A < F C < F A < G D < G F < H G < H K < H J < I E < J I < K
The above dependencies can now be "summarized" (note that all these should be sets of indexes, not package names as shown here): A,B,C (installed first and in this order -- no dep checking needed) D,E,F (can be installed at any time without dep checking) D < G D,E,F,G,J,I,K < H (note order is already worked out) E,J < I E < J E,J,I < K
The installer would go through and use a process something like this (some of this could likely be futher optimized, but keeping it simple for now).
Pseudocode: #define n (KNOWN_PACKAGES-MIN_INSTALL_PACKAGES) int wanted_packages[]; bool installing[n] = { false, false, ... }; int install_order[n]; int i = 0; for(wanted_package in wanted_packages) { /* Gets install list from summary file This should offset indexes so package 0 the first package not in min install */ int install_list[] = get_install_list(wanted_package); for(package in install_list) { if(!installing[package]) { install_order[i++] = package + MIN_INSTALL_PACKAGES; installing[package] = true; } } } min_install(); install_packages(install_order);
I don't know how different this is from what the installer already does, but I'd be interested to see how much it could be improved.
n0dalus.
-
Arthur Pemberton -
Chris Adams -
Dimi Paun -
drago01 -
Frank Ch. Eigler -
Jerry Williams -
Jesse Keating -
Leszek Matok -
n0dalus -
Paul Howarth -
Rahul Sundaram -
Richard Hughes