I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Given that, we're going to try to do next Tuesday, November 6th starting at 10 am EST (UTC-0500). We'll be in #anaconda on irc.freenode.net
While somewhat short notice, I'd rather get this going sooner rather than later and we can then follow up the IRC discussion with more here on the mailing list (I'll summarize as well as posting the log).
Jeremy
Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Since I tend to be a fan of mailinglists over real-time chat, I'll just put my 2 cents on the table here-
1) obviously I'll be happily in the weeds working on migrating my proof of concept liveOS rebootless installer, into a proof of concept patch for anaconda that makes it a little checkbox somewhere.
2) if nobody else tackles it, I may see if I can add a file copy based installation method for livecd installs. This would be to allow the user to select that the root volume not be formatted, or perhaps allow the user to choose something other than ext3 for the root volume.
3) allowing package selection for livecd installs (with network connectivity) seems entirely doable and desirable. (just do chroot yum install/erase after the base livecd image is copied)
4) Jeremy has mentioned before that the F9 timeframe might see a refactoring and sharing of code between anaconda and livecd-creator. (they both install a system from repos to a fresh filesystem). I'd really like to see this.
I hope someone posts an url to an irc log if it's an easy thing to do.
-dmc
Given that, we're going to try to do next Tuesday, November 6th starting at 10 am EST (UTC-0500). We'll be in #anaconda on irc.freenode.net
While somewhat short notice, I'd rather get this going sooner rather than later and we can then follow up the IRC discussion with more here on the mailing list (I'll summarize as well as posting the log).
Jeremy
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
I would like to see the support of Dogtail with patches located at: https://bugzilla.redhat.com/show_bug.cgi?id=239024
Hi.
On Fri, 02 Nov 2007 14:40:11 -0400, Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Given that, we're going to try to do next Tuesday, November 6th starting at 10 am EST (UTC-0500). We'll be in #anaconda on irc.freenode.net
Since I do not know yet if I'll be available at that time:
What I'd really like to see is a list of servers to netinstall from. Having to manually enter a hostname and path is quite ugly.
I'm willing to look into implementing this myself if noone else absolutely wants to do it.
On Mon, 5 Nov 2007 16:39:17 +0100 Ralf Ertzinger fedora@camperquake.de wrote:
What I'd really like to see is a list of servers to netinstall from. Having to manually enter a hostname and path is quite ugly.
I'm willing to look into implementing this myself if noone else absolutely wants to do it.
It may require yum stuff move to stage1, but there is infrastructure for using mirrorlists to return back a list of valid mirrors (even geoip close!) to install from.
Again I think the painful part is hooking all that up in loader.
On Mon, 2007-11-05 at 10:46 -0500, Jesse Keating wrote:
On Mon, 5 Nov 2007 16:39:17 +0100 Ralf Ertzinger fedora@camperquake.de wrote:
What I'd really like to see is a list of servers to netinstall from. Having to manually enter a hostname and path is quite ugly.
I'm willing to look into implementing this myself if noone else absolutely wants to do it.
It may require yum stuff move to stage1, but there is infrastructure for using mirrorlists to return back a list of valid mirrors (even geoip close!) to install from.
Again I think the painful part is hooking all that up in loader.
No, better would be moving install repo selection _out_ of the loader in as many cases as possible. The currently named rescue CD (ie, the iso with the first stage as well as the second stage) should really be getting better visibility. And we should probably stop building things like boot.iso. If you're wanting to pxeboot, we can then (in the loader) ask you just where stage2 is, grab it into RAM and then still do "install repo source" selection in the second stage.[1]
This lets us easily handle things like mirror lists, proxies, SSL, ...
Jeremy
[1] You can then use this URL to hint a repo location to the second stage
On Mon, 05 Nov 2007 10:59:03 -0500 Jeremy Katz katzj@redhat.com wrote:
No, better would be moving install repo selection _out_ of the loader in as many cases as possible. The currently named rescue CD (ie, the iso with the first stage as well as the second stage) should really be getting better visibility. And we should probably stop building things like boot.iso. If you're wanting to pxeboot, we can then (in the loader) ask you just where stage2 is, grab it into RAM and then still do "install repo source" selection in the second stage.[1]
This lets us easily handle things like mirror lists, proxies, SSL, ...
Hey that's even better (:
On Mon, Nov 05, 2007 at 04:39:17PM +0100, Ralf Ertzinger wrote:
Hi.
On Fri, 02 Nov 2007 14:40:11 -0400, Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Given that, we're going to try to do next Tuesday, November 6th starting at 10 am EST (UTC-0500). We'll be in #anaconda on irc.freenode.net
Since I do not know yet if I'll be available at that time:
What I'd really like to see is a list of servers to netinstall from. Having to manually enter a hostname and path is quite ugly.
I'm willing to look into implementing this myself if noone else absolutely wants to do it.
Hello Ralf,
maybe put in the mirrorlist we ship as default yum.conf also as default value into the install url?
regards,
Florian La Roche
Hi.
On Mon, 5 Nov 2007 17:56:17 +0100, Florian La Roche wrote
maybe put in the mirrorlist we ship as default yum.conf also as default value into the install url?
I do not think this would work out of the box, but I was planning to use the existing mirrorlist resources to get a list of mirrors.
Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Given that, we're going to try to do next Tuesday, November 6th starting at 10 am EST (UTC-0500). We'll be in #anaconda on irc.freenode.net
I cannot attend this meeting but If the following feature is implemented,I'll happy.
- bonding support Bonding can be setup at network configuration view selecting multi ether card while anaconda installation.
How do you think this implementation?
While somewhat short notice, I'd rather get this going sooner rather than later and we can then follow up the IRC discussion with more here on the mailing list (I'll summarize as well as posting the log).
Jeremy
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Missed that one but here's some ideas if you are still taking 'em.
I created an RFE https://bugzilla.redhat.com/show_bug.cgi?id=381641
iSCSI support was added to anaconda sometime ago. That's an expensive option unavailable to some/most Linux users. I saw the patches post for the iSCSI support. I thought that the code could be adapted for ATA over Ethernet, AOE http://www.coraid.com/tech1.html. AOE has been in the kernel for sometime now. The benefit to Fedora or ES users is similar to Xen support. AOE allows a big file server to be a virtual hard drive dispenser for client PCs. PCs are great, but if drivers are made available for the OpenMoko and Maemo platforms, then Fedora could host embedded devices need for an occasional larger storage area via AOE disk files as hard drives too. The nslu2 has an example idea http://www.nslu2-linux.org/wiki/Optware/Vblade . Perhaps a PC in the stereo rack would be quieter too. There's a lj article here http://www.linuxjournal.com/article/8149
Things that may have to be considered 1.) https://bugzilla.redhat.com/show_bug.cgi?id=381541 selinux configuration may have to be adapted. 2.) aoetools and perhaps the vblade tools will have to be available for anaconda to broadcast for available AOE drives. You do not have to have the Coraid hardware with the vblade tools http://sourceforge.net/project/shownotes.php?release_id=465195&group_id=... . 3.) I believe the "Advanced storage configuration" button is where the anaconda change should be made http://fedoraproject.org/wiki/Tours/Fedora8/005_Install_Partition 4.) Some sort of init script would be required. 5.) The init script may have to have, say, /etc/sysconfig/aoe information. 6.) The /boot partition may need some adjustsments so that that the kernel can load the drivers. 7.) Perhaps boot prom considerations are needed for diskless clients using a server with files uses as disk drives via vblade tools.
RFE posted https://bugzilla.redhat.com/show_bug.cgi?id=381661
I have to use a USB keyboard during installation of F8 on PlayStation 3, PS3, hardware. However the PS3 console also supports bluetooth devices. It would be great to pair and use a keyboard and mouse during the installation of a Fedora release, if possible. Both stage one and stage two would be modified. I wonder if this would be a similar idea like using a serial console during installation. The bluetooth keyboard and mouse would be used during installation and also be the final system keyboard and mouse after installation.
Thanks for considering input into F9.
Regards, Greg
On Tue, 2007-11-13 at 22:59 -0700, Greg Morgan wrote:
Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Missed that one but here's some ideas if you are still taking 'em.
Are you willing to help implement these features?
Jeremy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jeremy Katz wrote:
On Tue, 2007-11-13 at 22:59 -0700, Greg Morgan wrote:
Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Missed that one but here's some ideas if you are still taking 'em.
Are you willing to help implement these features?
Yes.
I'll take time over the weekend to organize what is needed. For example, the are existing aoetools and vblade packages but does that mean that Red Hat maintainers would have to take over the maintenance of the packages, since they would become vital to the installer?
I should be able to come up with some of the sysconfig file layouts etc. Do I post the design here and in the RFE number or how do you want me to proceed with the information?
Regards, Greg
On Thu, 2007-11-15 at 22:13 -0700, Greg Morgan wrote:
Jeremy Katz wrote:
On Tue, 2007-11-13 at 22:59 -0700, Greg Morgan wrote:
Jeremy Katz wrote:
I'd like to try and get everyone working on anaconda who wants to see new features, etc over the next six months (the Fedora 9 timeframe) and beyond together next week on IRC for an hour or so to kind of plan things out, figure out who's doing what and timing, etc.
Missed that one but here's some ideas if you are still taking 'em.
Are you willing to help implement these features?
Yes.
Awesome! I'll be glad to help out to get the code in
I'll take time over the weekend to organize what is needed. For example, the are existing aoetools and vblade packages but does that mean that Red Hat maintainers would have to take over the maintenance of the packages, since they would become vital to the installer?
Nope, for Fedora purposes, having them maintained by any Fedora contributor is fine. We just need to make sure that the code cleanly falls out to not being present for the case where the aoetools aren't included in the spin. But that would be the case anyway.
I should be able to come up with some of the sysconfig file layouts etc. Do I post the design here and in the RFE number or how do you want me to proceed with the information?
I'd say post it here and we can just add a pointer in the bug to the thread. Trying to do design in bugzilla is just painful -- mail is far better for actually banging out design, code, etc.
Jeremy
Hello list, better late than never, here it goes: feat: Configure yum .repo file based on installation source.
Justification: After installation the only .repo files that are present are the one installed by rpm packages. They point to official Fedora servers for getting a mirror list. They are no helpful is installation is from unofficial mirror or a local one (e.g. LAN). In contrast when performing network installation with Debian, one is asked to choose a mirror and that's saved in /etc/apt/source.list This feature will save the time for configuring a .repo file after installation.
Implementation: For http and ftp installs just take the list of configured repositories and dump it into a .repo file. CDROM/DVD/hard drive install - N/A NFS -N/A or some clever way to mount the NFS share, probably automount. I would say N/A for NFS since http/ftp is the majority of installation protocols used I believe.
Q: Is there a substantial difference in handling http unified and split trees ?
Any thoughts are welcome.
Greetings, Alexander.
Alexander Todorov wrote:
Hello list, better late than never, here it goes: feat: Configure yum .repo file based on installation source.
Justification: After installation the only .repo files that are present are the one installed by rpm packages. They point to official Fedora servers for getting a mirror list. They are no helpful is installation is from unofficial mirror or a local one (e.g. LAN). In contrast when performing network installation with Debian, one is asked to choose a mirror and that's saved in /etc/apt/source.list This feature will save the time for configuring a .repo file after installation.
Implementation: For http and ftp installs just take the list of configured repositories and dump it into a .repo file. CDROM/DVD/hard drive install - N/A NFS -N/A or some clever way to mount the NFS share, probably automount. I would say N/A for NFS since http/ftp is the majority of installation protocols used I believe.
Q: Is there a substantial difference in handling http unified and split trees ?
Any thoughts are welcome.
Greetings, Alexander.
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
This would be nice if it allowed the specification of NFS based yum repositories that are used during the install (especially kickstart) and then saved these either as a replacement for or in addition to the "standard" ones. Currently all of my kickstart scripts have to use a merged local and Everything repository for build and the update after reboot as we provide all of our data via NFS! We overwrite the yum.repos.d directory with a local copy which points to rsynced structures for the release.
Howard.
On Fri, 2007-11-23 at 11:15 +0100, Alexander Todorov wrote:
better late than never, here it goes: feat: Configure yum .repo file based on installation source.
The first step of doing this is actually done in Fedora 9 where we set up the InstallMedia repo for DVD installs based on the file in the tree.
Doing it more in general is difficult, though, as some of the install repos supported by anaconda aren't really supported by yum. eg, for NFS, you have to have it mounted because yum doesn't have any way of mounting an NFS repo (and probably shouldn't. although maybe it could) and NFSISO is definitely a bit of a non-starter.
Even for FTP/HTTP there are complications, though. If you point at a repo, what happens to the other repos which are configured as "stock". If you're pointing at your local mirror, then it's kind of crummy to be downloading metadata both from your local mirror and the upstream copy. But, eg, if it's just a Fedora mirror, then you still want to have the Everything tree configured.
Q: Is there a substantial difference in handling http unified and split trees ?
HTTP split trees are (finally, at last, hooray!) dead
Jeremy
Jeremy Katz wrote:
On Fri, 2007-11-23 at 11:15 +0100, Alexander Todorov wrote:
better late than never, here it goes: feat: Configure yum .repo file based on installation source.
The first step of doing this is actually done in Fedora 9 where we set up the InstallMedia repo for DVD installs based on the file in the tree.
Doing it more in general is difficult, though, as some of the install repos supported by anaconda aren't really supported by yum. eg, for NFS, you have to have it mounted because yum doesn't have any way of mounting an NFS repo (and probably shouldn't. although maybe it could) and NFSISO is definitely a bit of a non-starter.
Hmm, do we have statistics on which installation methods are most commonly used? I believe http network installs are the most common ones. Based on such info we can decide how to proceed with the NFS case.
Even for FTP/HTTP there are complications, though. If you point at a repo, what happens to the other repos which are configured as "stock". If you're pointing at your local mirror, then it's kind of crummy to be downloading metadata both from your local mirror and the upstream copy. But, eg, if it's just a Fedora mirror, then you still want to have the Everything tree configured.
I don't see why not just have both your local mirror and the upstream one. Probably the local one contains some 3rd party packages or some modified packages, etc. The problem I see here is with yum selecting a repository to download from. How are repositories selected? Based on name/url order or other preference? I've seen a plugin that selects the fastest mirror. If we are adding local repos they should be act as a primary download source.
Greetings, Alexander.
On Mon, 2007-11-26 at 16:14 +0100, Alexander Todorov wrote:
Jeremy Katz wrote:
On Fri, 2007-11-23 at 11:15 +0100, Alexander Todorov wrote:
better late than never, here it goes: feat: Configure yum .repo file based on installation source.
The first step of doing this is actually done in Fedora 9 where we set up the InstallMedia repo for DVD installs based on the file in the tree.
Doing it more in general is difficult, though, as some of the install repos supported by anaconda aren't really supported by yum. eg, for NFS, you have to have it mounted because yum doesn't have any way of mounting an NFS repo (and probably shouldn't. although maybe it could) and NFSISO is definitely a bit of a non-starter.
Hmm, do we have statistics on which installation methods are most commonly used? I believe http network installs are the most common ones. Based on such info we can decide how to proceed with the NFS case.
Not anything close to current ones.
Even for FTP/HTTP there are complications, though. If you point at a repo, what happens to the other repos which are configured as "stock". If you're pointing at your local mirror, then it's kind of crummy to be downloading metadata both from your local mirror and the upstream copy. But, eg, if it's just a Fedora mirror, then you still want to have the Everything tree configured.
I don't see why not just have both your local mirror and the upstream one. Probably the local one contains some 3rd party packages or some modified packages, etc. The problem I see here is with yum selecting a repository to download from. How are repositories selected? Based on name/url order or other preference? I've seen a plugin that selects the fastest mirror. If we are adding local repos they should be act as a primary download source.
Plenty of local mirrors are just that ... mirrors. No changes from the upstream repo. And we can make it so that the repo we write out is preferred by setting a cost in the repo (like we already do with the DVD repo; basically, we make it "cheaper" to access the install-time repo and thus it gets preferred by yum for a given package)
Jeremy
anaconda-devel@lists.fedoraproject.org
-
Alexander Todorov -
Douglas McClendon -
Florian La Roche -
Greg Morgan -
HARA Hiroshi -
Howard Wilkinson -
Jeremy Katz -
Jesse Keating -
Ralf Ertzinger