I think everyone's familiar with the mess that is prompting for the method in loader and fetching the stage2 image. It's too late to do anything for F9 besides patch the bugs, but it's time to start thinking about what to do for F10. So, let's start thinking about it.
The way I see it, the loader currently does the following things regarding setting up the method:
- Support the following installation sources: http/ftp, dvd/cd, nfs, nfsiso, hdiso. It'd also be nice to support regular hd installs. - If stage2= is given, use that as the stage2 image. - If there's a CD in the drive and there's a stage2 image on it, use that. stage2= overrides this. - Support configuration from UI, cmdline, and kickstart. - Configure and bring up the network if required for a method. - DVD/CD should prompt for media check. - Each method implies certain locations for updates.img, product.img, etc. that are checked for automatically.
Those are the current features, best I can see. Are there any of these features we want to do away with? Does anything no longer make sense?
Now for the more controversial stuff. Here's what I would like to see happen in this area for F10. All these things are open for discussion, so jump right in.
- There shouldn't be any differences between booting off the network and booting off media. - loader should be moving to just doing what is required to fetch and mount the stage2 image. This can perhaps include inferring an installation repo based on the location of the stage2 image, but the
Problem: If the user booted off a CD and we don't have any method configuration screen, the implied updates.img and product.img checks will never work. - We shouldn't be checking if the inferred repo is valid in any way, perhaps except that we can at least mount it (if the method requires that). This requires making the repo editor in stage2 more useful. It also separates the loader from the payload it's installing more. In particular, any remaining .discinfo checks ought to die. - We shouldn't leave the repo mounted at the end of loader.
Problem: RHupdates/ will no longer work. Problem: This means both loader and stage2 will have to have some code for mounting installation sources. This probably isn't such a big problem because stage2 will already require it for error handling. - Part of the last one... we should copy the stage2 image out of its initial location. My reasoning for this is still that it makes error handling easier when the repo has trouble. This requires making the repo editor more useful too.
Problem: This increases the memory requirements, which no one likes.
Your thoughts? Once we at least have some concept of what should be going on, I can get started on working on a code design - hopefully one that removes a lot more than it adds.
- Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Chris Lumens wrote: | I think everyone's familiar with the mess that is prompting for the | method in loader and fetching the stage2 image. It's too late to do | anything for F9 besides patch the bugs, but it's time to start thinking | about what to do for F10. So, let's start thinking about it. | | The way I see it, the loader currently does the following things | regarding setting up the method: | | - Support the following installation sources: http/ftp, dvd/cd, nfs, | nfsiso, hdiso. It'd also be nice to support regular hd installs. | - If stage2= is given, use that as the stage2 image. | - If there's a CD in the drive and there's a stage2 image on it, use | that. stage2= overrides this. | - Support configuration from UI, cmdline, and kickstart. | - Configure and bring up the network if required for a method. | - DVD/CD should prompt for media check. | - Each method implies certain locations for updates.img, product.img, | etc. that are checked for automatically. | | Those are the current features, best I can see. Are there any of these | features we want to do away with? Does anything no longer make sense? | | Now for the more controversial stuff. Here's what I would like to see | happen in this area for F10. All these things are open for discussion, | so jump right in. | | - There shouldn't be any differences between booting off the network and | booting off media. | - loader should be moving to just doing what is required to fetch and | mount the stage2 image. This can perhaps include inferring an | installation repo based on the location of the stage2 image, but the | | Problem: If the user booted off a CD and we don't have any method | configuration screen, the implied updates.img and product.img checks | will never work.
Another problem I can see right now: boot off CD/boot.iso and perform a network install. Useful in cases where: no PXE available, ISOs not mirrored - only packages
The stage2= needs a repo= cousin (or ks.cfg) so we can use any compatible stage2 with any compatible repos.
Thanks, Alexander.
Another problem I can see right now: boot off CD/boot.iso and perform a network install. Useful in cases where: no PXE available, ISOs not mirrored - only packages
You can do this now by adding 'askmethod' to the cmdline parameters.
The stage2= needs a repo= cousin (or ks.cfg) so we can use any compatible stage2 with any compatible repos.
I think Jeremy's talked about this a little in the past but I don't remember what decision was reached. Also we haven't even begun to consider the implications of stage2= vs. method= for kickstart. Right now there's just the url/cdrom/nfs/whatever command to give the method. Perhaps that should be converted into a way to specify the stage2 image and the repo command should be used to specify the installation source?
- Chris
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
Chris Lumens wrote: |> Another problem I can see right now: |> boot off CD/boot.iso and perform a network install. Useful in cases where: |> no PXE available, ISOs not mirrored - only packages | | You can do this now by adding 'askmethod' to the cmdline parameters. | |> The stage2= needs a repo= cousin (or ks.cfg) so we can use any compatible stage2 |> with any compatible repos. | | I think Jeremy's talked about this a little in the past but I don't | remember what decision was reached. Also we haven't even begun to | consider the implications of stage2= vs. method= for kickstart. Right | now there's just the url/cdrom/nfs/whatever command to give the method.
| Perhaps that should be converted into a way to specify the stage2 image | and the repo command should be used to specify the installation source? |
Sounds perfect to me. stage2 + repo.
- - Alexander.
Chris Lumens wrote:
- Support the following installation sources: http/ftp, dvd/cd, nfs, nfsiso, hdiso. It'd also be nice to support regular hd installs.
It doesn't? I'm sure I did one or two, back before hdiso was invented. RHL 7.x.
- Support the following installation sources: http/ftp, dvd/cd, nfs, nfsiso, hdiso. It'd also be nice to support regular hd installs.
It doesn't? I'm sure I did one or two, back before hdiso was invented. RHL 7.x.
It may have in the past. It hasn't as long as I've been working on anaconda, which admittedly has only been three years now.
- Chris
On Wed, 2008-04-23 at 11:18 -0400, Chris Lumens wrote:
- Support the following installation sources: http/ftp, dvd/cd, nfs, nfsiso, hdiso. It'd also be nice to support regular hd installs.
It doesn't? I'm sure I did one or two, back before hdiso was invented. RHL 7.x.
It may have in the past. It hasn't as long as I've been working on anaconda, which admittedly has only been three years now.
We did long ago, but removed the support due to an extreme number of cases where people would only mirror the things they "thought" they needed and then end up in a bad place. If we go back to supporting it, we need to add some significant checking to ensure that the packages are there in advance
Jeremy
It may have in the past. It hasn't as long as I've been working on anaconda, which admittedly has only been three years now.
We did long ago, but removed the support due to an extreme number of cases where people would only mirror the things they "thought" they needed and then end up in a bad place. If we go back to supporting it, we need to add some significant checking to ensure that the packages are there in advance
Ugh, okay. So then we're in the situation where the repo metadata refers to (potentially) tons of packages that don't exist. You know, if the stage2 also contained createrepo we could just rebuild the metadata on the hard drive partition and.... wait, no, bad idea.
Realistically we could be in the same position with NFS installs as well. However I bet a lot more people would do HD installs than NFS installs so we are probably setting ourselves up for real problems here if we re-enable this.
I'm not attached to the idea. It just seems like we've already got all the code in place to do it.
- Chris
Chris Lumens wrote:
It may have in the past. It hasn't as long as I've been working on anaconda, which admittedly has only been three years now.
We did long ago, but removed the support due to an extreme number of cases where people would only mirror the things they "thought" they needed and then end up in a bad place. If we go back to supporting it, we need to add some significant checking to ensure that the packages are there in advance
Ugh, okay. So then we're in the situation where the repo metadata refers to (potentially) tons of packages that don't exist. You know, if the stage2 also contained createrepo we could just rebuild the metadata on the hard drive partition and.... wait, no, bad idea.
Realistically we could be in the same position with NFS installs as well. However I bet a lot more people would do HD installs than NFS
Why do you think that? The most likely way to "install from HD" I think is to stick a USB drive in and install from that. The simplest way to get an install onto a USB disk, for most people, is to copy a DVD or set of CD ISO images to it.
I've never found the idea of plugging an ATA disk into an IDE connector attractive, and of the too many computers this geek has around (a quick census suggests 13 Pentium IV or better), only two could do an HD install from a different drive without plugging an extra drive in some place.
The most common combination for a single-disk multiboot setup would include Windows, I suspect.
I think in all cases, a bunch of ISO images is easier than a mirrored or constructed (from ISOs) repo.
For derived distros, the unrolled install repo is easier, but then this geek would be using http.
installs so we are probably setting ourselves up for real problems here if we re-enable this.
I'm not attached to the idea. It just seems like we've already got all the code in place to do it.
The previous implementation predates the use of yum in anaconda.
If not a createrepo, is a "checkrepo" option possible? Advice might be "If you haven't checked this repo before, you should now."
Chris Lumens wrote:
Part of the last one... we should copy the stage2 image out of its initial location. My reasoning for this is still that it makes error handling easier when the repo has trouble. This requires making the repo editor more useful too.
Problem: This increases the memory requirements, which no one likes.
Small is good, but which specific memory requirements are we talking about?
If execution-time address space, then "ldd anaconda-runtime/loader/loader" shows linux-gate.so.1 => (0x00110000) libnewt.so.0.52 => /usr/lib/libnewt.so.0.52 (0x00c6c000) libslang.so.2 => /usr/lib/libslang.so.2 (0x00cbb000) libz.so.1 => /lib/libz.so.1 (0x00ca5000) libpopt.so.0 => /lib/libpopt.so.0 (0x00a83000) libdhcp-1.99.so.1 => /usr/lib/libdhcp-1.99.so.1 (0x00de3000) libnl.so.1 => /usr/lib/libnl.so.1 (0x0016d000) libdhcp4client-4.0.so.0 => /usr/lib/libdhcp4client-4.0.so.0 (0x001be000) libdhcp6client-1.0.so.2 => /usr/lib/libdhcp6client-1.0.so.2 (0x00db1000) libdevmapper.so.1.02 => /lib/libdevmapper.so.1.02 (0x009c2000) libselinux.so.1 => /lib/libselinux.so.1 (0x00c87000) libsepol.so.1 => /lib/libsepol.so.1 (0x00986000) libresolv.so.2 => /lib/libresolv.so.2 (0x00a4b000) libm.so.6 => /lib/libm.so.6 (0x00c3a000) libc.so.6 => /lib/libc.so.6 (0x00acf000) libdl.so.2 => /lib/libdl.so.2 (0x00c65000) /lib/ld-linux.so.2 (0x00aaf000) which suggests that several of those libraries might be used with explicit dlopen()/dlclose() for various phases. There is also a style which uses a chain of execve() to handle various phases, or even "code overlays" where the .text begins with a new main() from a new file, but the .data+.bss+.stack remains the same. If swap space is available, then a series of processes connected via pipes can reduce the minimum RAM required.
If media storage space, then anaconda-runtime/loader/loader does not use compression of the executable itself. "upx --lzma" reduces it from 237904 -> 84556 bytes, which is a ratio of 0.36.
Is stage2.img accessed dynamically as a compressed filesystem that is not memory resident? Is all of it uncompressed at once before initial access?
John Reiser wrote:
Chris Lumens wrote:
Part of the last one... we should copy the stage2 image out of its initial location. My reasoning for this is still that it makes error handling easier when the repo has trouble. This requires making the repo editor more useful too.
Problem: This increases the memory requirements, which no one likes.
Small is good, but which specific memory requirements are we talking about?
I was thinking ramdisk. If one boots off CD or a hdd or a USB disk, there's something approaching a real disk (at least) for stage2. If you want the ability to remove the boot medium, then that has to be stored somewhere else.
The target disk would be nice, but that's not (reliably) available until partitioning and filesystem layout is done.
Part of the last one... we should copy the stage2 image out of its initial location. My reasoning for this is still that it makes error handling easier when the repo has trouble. This requires making the repo editor more useful too.
Problem: This increases the memory requirements, which no one likes.
Small is good, but which specific memory requirements are we talking about?
I was thinking ramdisk. If one boots off CD or a hdd or a USB disk, there's something approaching a real disk (at least) for stage2. If you want the ability to remove the boot medium, then that has to be stored somewhere else.
The target disk would be nice, but that's not (reliably) available until partitioning and filesystem layout is done.
Yes, exactly. In the URL installation case, we download the stage2.img and toss it into /tmp, which is a ramdisk. We only have to do this if they're booting off the network, as the CD has stage2 on it. It'd be a lot simpler to just always put the stage2.img into /tmp but that increases the memory usage for everyone. Right now we're only increasing the memory requirements for people who are booting off the network and using URL installs.
The memory usage of stage2 is something around 100 MB. We move this to the target filesystem as soon as it's available. That now happens to be before package selection and dependency solving, which is where we really run into memory troubles.
- Chris
Chris Lumens wrote:
Now for the more controversial stuff. Here's what I would like to see happen in this area for F10. All these things are open for discussion, so jump right in.
As a user, I'd like to see automatic installations easier. Here are some ideas I have. 1. Look at local media (floppy, usb, ??) for a ks file. If one is found, use it. By way of reference to another authority, this is what Windows does.
2. Request, and use if supplied, information from DHCP. Vendor Options are specified - http://www.iana.org/assignments/bootp-dhcp-parameters see tag 43 - as available for vendors (Red Hat, Fedora, Debian) to request and obtain information from a DHCP server. Anaconda already sets the option vendor-class-identifier and I use that to provide a special range of IP addresses for installation: class "anaconda" { match if substring (option vendor-class-identifier, 0, 8) = "anaconda"; option vendor-class-identifier "anaconda"; }
and pool { allow members of "anaconda"; deny members of "pxeclients"; default-lease-time 900; filename "http://Fedora.demo.lan/5/i386/os/Fedora/"; max-lease-time 1800; range 192.168.9.170 192.168.9.179; option log-servers 192.168.9.4; }
This illustrates how ISC DHCP 3 may be configured to provide information to Anaconda.
A sane value for filename might be the install URL, or the ks file. Use of other information such as log-servers, time-offset and ntp-servers would be beneficial (the filesystem would have correct timestamps that really reflect the time of the install).
Implementation of one or both of these would mean that users could do automatic installs with standard media, without having to key potentially long and fairly meaningless strings of data such as the URL to an install server.
Problem: If the user booted off a CD and we don't have any method configuration screen, the implied updates.img and product.img checks will never work.
In the case of a ks install, this info could be in the ks file. If DHCP were used, the DHCP server could be configured to provide the information.
- Look at local media (floppy, usb, ??) for a ks file. If one is found,
use it. By way of reference to another authority, this is what Windows does.
I don't really like the idea of making kickstart file use quite this automatic. We've already got ks= that's easy to toss into PXE boot arguments and so forth. I suppose we could do some work on making it so that ks=floppy automatically probes for a floppy drive, etc. though.
A sane value for filename might be the install URL, or the ks file. Use of other information such as log-servers, time-offset and ntp-servers would be beneficial (the filesystem would have correct timestamps that really reflect the time of the install).
Implementation of one or both of these would mean that users could do automatic installs with standard media, without having to key potentially long and fairly meaningless strings of data such as the URL to an install server.
I'm all for making these sorts of things more automatic, however. Would you believe me if I said we are already at least partially using values out of DHCP for the kickstart file location:
http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=loader2/nfsinstall....
There's probably a lot more we can do there, though. I don't think this area has seen much activity at all lately.
As for using the other DHCP values like for ntp-servers, I'll have to defer to David for how easy that might be. I'm not really familiar with the DHCP side of things.
- Chris
Chris Lumens wrote:
- Look at local media (floppy, usb, ??) for a ks file. If one is found,
use it. By way of reference to another authority, this is what Windows does.
I don't really like the idea of making kickstart file use quite this
Why not? Let's examine your objections.
automatic. We've already got ks= that's easy to toss into PXE boot arguments and so forth. I suppose we could do some work on making it so that ks=floppy automatically probes for a floppy drive, etc. though.
My preference is 1. Insert standard CD/DVD 2. Power up. 3. Select (from BIOS) "Boot from CD. 4. Walk away.
A sane value for filename might be the install URL, or the ks file. Use of other information such as log-servers, time-offset and ntp-servers would be beneficial (the filesystem would have correct timestamps that really reflect the time of the install).
Implementation of one or both of these would mean that users could do automatic installs with standard media, without having to key potentially long and fairly meaningless strings of data such as the URL to an install server.
I'm all for making these sorts of things more automatic, however. Would you believe me if I said we are already at least partially using values out of DHCP for the kickstart file location:
http://git.fedorahosted.org/git/?p=anaconda.git;a=blob;f=loader2/nfsinstall....
Doubledutch to me. Where is it documented? Is thatjust for nfs? Does it work for http (my usual install method)?
There's probably a lot more we can do there, though. I don't think this area has seen much activity at all lately.
As for using the other DHCP values like for ntp-servers, I'll have to defer to David for how easy that might be. I'm not really familiar with the DHCP side of things.
DHCP is used to configure (sub)network-wide information. The source of time is one, log servers is another. It makes sense to honour the system administrator's mandate.
If I say to use "192.168.9.4" as the time source then I expect ntp clients to use that, not time.apple.com, time.redhat.com or pool.ntp.org. Those might be (and are, on my systems) blocked by firewalls. (I also don't expect to have to manually select to use the DHCP-supplied value later, that's craezee).
You'd be familiar with IP address, netmask, gateway. There's heaps more stuff can be specified, including Vendor's inventions. If you have a look at the latest etherboot, you will see it includes PXE software now, and that it can accept an URL as file name and do http to get the file.
On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
- There shouldn't be any differences between booting off the network
and booting off media.
loader should be moving to just doing what is required to fetch and mount the stage2 image. This can perhaps include inferring an installation repo based on the location of the stage2 image, but the
Problem: If the user booted off a CD and we don't have any method configuration screen, the implied updates.img and product.img checks will never work.
Caveat: Thinking out loud ... insanity likely.
That's an interesting idea. What about having two sets of media (iso's), one that contains stage#2 and packages, and another that's just used to get you to the "Method selection screen"?
This sounds familiar (aka boot.iso). The difference here being we would never prompt you if you booted from DVD or disc1. Would this make things simpler?
Thanks, James
On Wed, 2008-04-23 at 16:51 +0000, James Laska wrote:
That's an interesting idea. What about having two sets of media (iso's), one that contains stage#2 and packages, and another that's just used to get you to the "Method selection screen"?
This sounds familiar (aka boot.iso). The difference here being we would never prompt you if you booted from DVD or disc1. Would this make things simpler?
Unless you pass 'askmethod', we never prompt you for a method when booting from DVD or disc1.
That's an interesting idea. What about having two sets of media (iso's), one that contains stage#2 and packages, and another that's just used to get you to the "Method selection screen"?
This sounds familiar (aka boot.iso). The difference here being we would never prompt you if you booted from DVD or disc1. Would this make things simpler?
Unless you pass 'askmethod', we never prompt you for a method when booting from DVD or disc1.
And booting from the full DVD or disc1 and adding askmethod is just weird, man. I wish we could stop supporting so many unusual things.
- Chris
Chris Lumens wrote:
That's an interesting idea. What about having two sets of media (iso's), one that contains stage#2 and packages, and another that's just used to get you to the "Method selection screen"?
This sounds familiar (aka boot.iso). The difference here being we would never prompt you if you booted from DVD or disc1. Would this make things simpler?
Unless you pass 'askmethod', we never prompt you for a method when booting from DVD or disc1.
And booting from the full DVD or disc1 and adding askmethod is just weird, man.
Why? Can't you pull updated packages during install?
And booting from the full DVD or disc1 and adding askmethod is just weird, man.
Why? Can't you pull updated packages during install?
Yes, I suppose you could do that. However, you're going to end up getting all the packages from whatever source you entered for askmethod, not just the updated ones. Not sure if that's what you intended to do or not.
- Chris
Chris Lumens wrote:
And booting from the full DVD or disc1 and adding askmethod is just weird, man.
Why? Can't you pull updated packages during install?
Yes, I suppose you could do that. However, you're going to end up getting all the packages from whatever source you entered for askmethod, not just the updated ones. Not sure if that's what you intended to do or not.
At least one of us two is confused.
Whatever is specified for askmethod, one should have the option to install only the latest of each package. Preferably, one would be able to specify (at least) two sources of packages, the base which has a version of each and every official package, a source of the latest packages (this might be a local mirror, and it might be a controlled - for local QA purposes - mirror).
In kickstart terms, I can imagine a succession of repo statements identifying where repos should be found; all would, by definition, be enabled and ideally all would be configured so after installation.
repo url= [proxy=] and/or, to get a tarball suitable for /etc/yum.repos.d repo list=
In interactive installs, users would have a table. To save typing, blank entries in the host field would imply "ditto."
Packages could come from any number of sources, including non-standard repos and their respective updates.
On Wed, 2008-04-23 at 16:51 +0000, James Laska wrote:
On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
- There shouldn't be any differences between booting off the network
and booting off media.
loader should be moving to just doing what is required to fetch and mount the stage2 image. This can perhaps include inferring an installation repo based on the location of the stage2 image, but the
Problem: If the user booted off a CD and we don't have any method configuration screen, the implied updates.img and product.img checks will never work.
Caveat: Thinking out loud ... insanity likely.
That's an interesting idea. What about having two sets of media (iso's), one that contains stage#2 and packages, and another that's just used to get you to the "Method selection screen"?
This sounds familiar (aka boot.iso). The difference here being we would never prompt you if you booted from DVD or disc1. Would this make things simpler?
This sounds pretty much exactly like what we have now... :)
Jeremy
On Wed, 2008-04-23 at 21:45 -0400, Jeremy Katz wrote:
This sounds familiar (aka boot.iso). The difference here being we
would
never prompt you if you booted from DVD or disc1. Would this make things simpler?
This sounds pretty much exactly like what we have now... :)
Yeah ... I'm still struggling on how/if it's different to be honest :)
Howabout ...
If we boot from media that contains the installation source, we should use it (no questions asked).
If we boot from media that doesn't contain a stage2 || installation_source, we prompt the user or honor cmdline arguments.
Which I guess means the only change from current behavior might be dropping support for the cmdline option "askmethod" entirely and having that decision be based on the presence of an ondisk stage2.img?
Thanks, James
James Laska wrote:
On Wed, 2008-04-23 at 21:45 -0400, Jeremy Katz wrote:
This sounds familiar (aka boot.iso). The difference here being we
would
never prompt you if you booted from DVD or disc1. Would this make things simpler?
This sounds pretty much exactly like what we have now... :)
Yeah ... I'm still struggling on how/if it's different to be honest :)
Howabout ...
If we boot from media that contains the installation source, we should use it (no questions asked).
Did I miss something? I thought an objective was to have, say, an RHEL 5.0 boot disk that could install 5.1 or 5.2.
If one can boot a CD and request a different stage2 that's possible.
On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
We shouldn't leave the repo mounted at the end of loader.
Problem: RHupdates/ will no longer work.
How frequently do folks use RHupdates these days? If recent memory serves, I've been using nothing but updates.img's for all http, ftp, and nfs installs.
Thanks, James
On Wed, 23 Apr 2008, James Laska wrote:
On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
We shouldn't leave the repo mounted at the end of loader.
Problem: RHupdates/ will no longer work.
How frequently do folks use RHupdates these days? If recent memory serves, I've been using nothing but updates.img's for all http, ftp, and nfs installs.
I use it on occasion when debugging something in anaconda. It's a bit faster than spinning an updates.img.
Jeff
On Wed, 2008-04-23 at 14:12 -0500, Jeff Bastian wrote:
On Wed, 23 Apr 2008, James Laska wrote:
On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
We shouldn't leave the repo mounted at the end of loader.
Problem: RHupdates/ will no longer work.
How frequently do folks use RHupdates these days? If recent memory serves, I've been using nothing but updates.img's for all http, ftp, and nfs installs.
I use it on occasion when debugging something in anaconda. It's a bit faster than spinning an updates.img.
I said that for a while, but now that we can have updates.img being a cgz, I'm less convinced. find $foo |cpio -H newc -o |gzip -9 > updates.cgz is pretty straightforward and no more difficult really. The problem with the filesystem images was always having to be root
Jeremy
On Wed, 2008-04-23 at 21:44 -0400, Jeremy Katz wrote:
I said that for a while, but now that we can have updates.img being a cgz, I'm less convinced. find $foo |cpio -H newc -o |gzip -9 > updates.cgz is pretty straightforward and no more difficult really. The problem with the filesystem images was always having to be root
OOoh, http://fedoraproject.org/wiki/Anaconda/Updates should be updated with that method. I've been doing the sudo mount, copy, umount dance for a bit now and it's tedious.
On Wed, 2008-04-23 at 22:21 -0400, Jesse Keating wrote:
On Wed, 2008-04-23 at 21:44 -0400, Jeremy Katz wrote:
I said that for a while, but now that we can have updates.img being a cgz, I'm less convinced. find $foo |cpio -H newc -o |gzip -9 > updates.cgz is pretty straightforward and no more difficult really. The problem with the filesystem images was always having to be root
OOoh, http://fedoraproject.org/wiki/Anaconda/Updates should be updated with that method. I've been doing the sudo mount, copy, umount dance for a bit now and it's tedious.
It's a wiki... :-P
Jeremy
On Wed, Apr 23, 2008 at 09:44:41PM -0400, Jeremy Katz wrote:
On Wed, 2008-04-23 at 14:12 -0500, Jeff Bastian wrote:
On Wed, 23 Apr 2008, James Laska wrote:
On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
We shouldn't leave the repo mounted at the end of loader.
Problem: RHupdates/ will no longer work.
How frequently do folks use RHupdates these days? If recent memory serves, I've been using nothing but updates.img's for all http, ftp, and nfs installs.
I use it on occasion when debugging something in anaconda. It's a bit faster than spinning an updates.img.
I said that for a while, but now that we can have updates.img being a cgz, I'm less convinced. find $foo |cpio -H newc -o |gzip -9 > updates.cgz is pretty straightforward and no more difficult really. The problem with the filesystem images was always having to be root
cramfs works as well. Any user can run mkcramfs.
Elliot
We shouldn't leave the repo mounted at the end of loader.
Problem: RHupdates/ will no longer work.
How frequently do folks use RHupdates these days? If recent memory serves, I've been using nothing but updates.img's for all http, ftp, and nfs installs.
I'll be honest, it's typically the easiest thing for me to do so I use it quite often. On the other hand, making an updates.img and tossing it on a website is really simple too.
I think we could make RHupdates work in a world where nothing is mounted at the end of loader, but only if we are all convinced we should keep this feature. It wouldn't take much to convince me. I think updates= is a really flexible option that's not tied to a single installation method, and I like that.
- Chris
On Thu, 2008-04-24 at 05:20 -0400, Chris Lumens wrote:
We shouldn't leave the repo mounted at the end of loader.
Problem: RHupdates/ will no longer work.
How frequently do folks use RHupdates these days? If recent memory serves, I've been using nothing but updates.img's for all http, ftp, and nfs installs.
I'll be honest, it's typically the easiest thing for me to do so I use it quite often. On the other hand, making an updates.img and tossing it on a website is really simple too.
I think we could make RHupdates work in a world where nothing is mounted at the end of loader, but only if we are all convinced we should keep this feature. It wouldn't take much to convince me. I think updates= is a really flexible option that's not tied to a single installation method, and I like that.
Yeah, good points. At the risk turning into a "my favorite method is ..." discussion, the updates.img's lend themselves well as a "package" for collecting a set of one or more fixes and distributing them to consumers. Additionally, write access to the installation source isn't always available (mirrors, netapps etc...).
If you're looking to reduce code paths, you have one vote for dropping RHupdates and relying solely on updates= and os.path.isfile("images/updates.img").
Thanks, James
- Chris
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Thu, 2008-04-24 at 05:20 -0400, Chris Lumens wrote:
We shouldn't leave the repo mounted at the end of loader.
Problem: RHupdates/ will no longer work.
How frequently do folks use RHupdates these days? If recent memory serves, I've been using nothing but updates.img's for all http, ftp, and nfs installs.
I'll be honest, it's typically the easiest thing for me to do so I use it quite often. On the other hand, making an updates.img and tossing it on a website is really simple too.
I think we could make RHupdates work in a world where nothing is mounted at the end of loader, but only if we are all convinced we should keep this feature. It wouldn't take much to convince me. I think updates= is a really flexible option that's not tied to a single installation method, and I like that.
RHupdates is from the days before updates= and our flexibility there. The more I think about it, the more I think that its time is past
Jeremy
I think we could make RHupdates work in a world where nothing is mounted at the end of loader, but only if we are all convinced we should keep this feature. It wouldn't take much to convince me. I think updates= is a really flexible option that's not tied to a single installation method, and I like that.
RHupdates is from the days before updates= and our flexibility there. The more I think about it, the more I think that its time is past
Agreed, we can use the more flexible method for all cases. I'll write this down on my list of things to do on rewrite.
- Chris
On Wed, 2008-04-23 at 10:32 -0400, Chris Lumens wrote:
- There shouldn't be any differences between booting off the network and booting off media.
- loader should be moving to just doing what is required to fetch and mount the stage2 image. This can perhaps include inferring an installation repo based on the location of the stage2 image, but the
I wouldn't so much say that the loader would infer the installation repo location. But that information on where stage2 came from is available to stage2 and then we can do munging in stage2 to suggest a repo based on that. Or upon a mirrorlist or the like.
Problem: If the user booted off a CD and we don't have any method configuration screen, the implied updates.img and product.img checks will never work.
The implied updates.img should map to the stage2 location more than the repo I think. product.img needs some more thought, though
- We shouldn't be checking if the inferred repo is valid in any way, perhaps except that we can at least mount it (if the method requires that). This requires making the repo editor in stage2 more useful. It also separates the loader from the payload it's installing more. In particular, any remaining .discinfo checks ought to die.
- We shouldn't leave the repo mounted at the end of loader.
Sounds reasonable.
Problem: RHupdates/ will no longer work.
We could just copy the contents of RHupdates to /tmp/updates just like we do with an updates.img
Problem: This means both loader and stage2 will have to have some code for mounting installation sources. This probably isn't such a big problem because stage2 will already require it for error handling.
Arguably, we could just not mount the install source at all from the loader and just have it always done in stage2
Part of the last one... we should copy the stage2 image out of its initial location. My reasoning for this is still that it makes error handling easier when the repo has trouble. This requires making the repo editor more useful too.
Problem: This increases the memory requirements, which no one likes.
If we have things disconnected, there's no reason we can't have the same thing mounted more than once. So we could have the source for stage2 mounted at /mnt/stage2 (as you've already started down the path of) and then we should be able to failover with repo problems.
Jeremy
- loader should be moving to just doing what is required to fetch and mount the stage2 image. This can perhaps include inferring an installation repo based on the location of the stage2 image, but the
I wouldn't so much say that the loader would infer the installation repo location. But that information on where stage2 came from is available to stage2 and then we can do munging in stage2 to suggest a repo based on that. Or upon a mirrorlist or the like.
I like this even better because it involves moving stuff out of loader. We already have the information about where stage2 came from thanks to the -m <whatever> argument to anaconda. Doesn't seem like there's a whole lot to do here.
I might still like to pre-populate the URL box in loader with the mirrorlist, but I haven't thought about how to do that without hardcoding values.
Problem: If the user booted off a CD and we don't have any method configuration screen, the implied updates.img and product.img checks will never work.
The implied updates.img should map to the stage2 location more than the repo I think. product.img needs some more thought, though
updates.img: Sounds good. Anything that decouples loader from the installation payload sounds good to me at this point.
product.img: What prohibits us from doing the same as with the updates.img? The two are arguably really about the same thing - making modifications to the stage2 image. The product.img just modifies the available installclasses. That's still modifying anaconda's source files if you think about it.
Problem: RHupdates/ will no longer work.
We could just copy the contents of RHupdates to /tmp/updates just like we do with an updates.img
That should work.
Problem: This means both loader and stage2 will have to have some code for mounting installation sources. This probably isn't such a big problem because stage2 will already require it for error handling.
Arguably, we could just not mount the install source at all from the loader and just have it always done in stage2
If the stage2 is on NFS or HDISO, we'll still have to have the code to handle those in the loader. That's what I was referring to. On the other hand if you're proposing the stage2.img cannot be on either of those methods...
Problem: This increases the memory requirements, which no one likes.
If we have things disconnected, there's no reason we can't have the same thing mounted more than once. So we could have the source for stage2 mounted at /mnt/stage2 (as you've already started down the path of) and then we should be able to failover with repo problems.
Hm yes, that probably would work though it has the potential to be a little tricky. Worth looking into, certainly.
- Chris
On Thu, 2008-04-24 at 06:14 -0400, Chris Lumens wrote:
- loader should be moving to just doing what is required to fetch and mount the stage2 image. This can perhaps include inferring an installation repo based on the location of the stage2 image, but the
I wouldn't so much say that the loader would infer the installation repo location. But that information on where stage2 came from is available to stage2 and then we can do munging in stage2 to suggest a repo based on that. Or upon a mirrorlist or the like.
I like this even better because it involves moving stuff out of loader. We already have the information about where stage2 came from thanks to the -m <whatever> argument to anaconda. Doesn't seem like there's a whole lot to do here.
Yep
I might still like to pre-populate the URL box in loader with the mirrorlist, but I haven't thought about how to do that without hardcoding values.
Isn't the hope, though, that the only time[1] you get a prompt in the loader is if you pxe boot (and thus don't have stage2 available). If stage2 is available, we don't need to prompt about repos until we're in the second stage at which point the mirrorlist stuff becomes a lot easier
Problem: If the user booted off a CD and we don't have any method configuration screen, the implied updates.img and product.img checks will never work.
The implied updates.img should map to the stage2 location more than the repo I think. product.img needs some more thought, though
updates.img: Sounds good. Anything that decouples loader from the installation payload sounds good to me at this point.
product.img: What prohibits us from doing the same as with the updates.img? The two are arguably really about the same thing - making modifications to the stage2 image. The product.img just modifies the available installclasses. That's still modifying anaconda's source files if you think about it.
Yes, but logically, a product.img is more related to your packages than to your installer. Maybe this is just the sign that we need to blow up install classes like I've been threatening to do for years.
Jeremy
Jeremy Katz wrote:
I might still like to pre-populate the URL box in loader with the mirrorlist, but I haven't thought about how to do that without hardcoding values.
Isn't the hope, though, that the only time[1] you get a prompt in the loader is if you pxe boot (and thus don't have stage2 available). If stage2 is available, we don't need to prompt about repos until we're in the second stage at which point the mirrorlist stuff becomes a lot easier
I think that, with the cooperation of the user's network admin in configuring the dhcp server, the prompt can be avoided.
Read the description of VENDOR ENCAPSULATED OPTIONS in dhcp-options(5). I'm looking at the version supplied in RHEL4/WBEL4.
Vendors (eg Red Hat, Fedora, Debian etc) can specify their own options. In dhcpd.conf it might go: option space anaconda; option anaconda.stage2 1 = text; option anaconda.ks 2 = text;
..
class "anaconda" { match if substring (option vendor-class-identifier, 0, 8) = "anaconda"; option vendor-class-identifier "anaconda"; option anaconda.ks "http://fantom.example.com/cgi-bin/ks"; option.anaconda.stage2 "ftp.redhat.com/example/stage2.img"; }
Note, RH should urge _strongly_ that, in using anaconda for their own derived distros, they should specify a different vendor-class-identifier.
anaconda already sets vendor-class-identifier appropriately. It only needs to request, and use, some more information when configuring the network.
I might still like to pre-populate the URL box in loader with the mirrorlist, but I haven't thought about how to do that without hardcoding values.
Isn't the hope, though, that the only time[1] you get a prompt in the loader is if you pxe boot (and thus don't have stage2 available). If stage2 is available, we don't need to prompt about repos until we're in the second stage at which point the mirrorlist stuff becomes a lot easier
True. I don't think about this very often probably because we do so many NFS installs here where we boot from PXE. So really, we're not testing the common case and I end up thinking about something that's really less common and more complicated.
Bad.
Indicidentally, what happened to footnote 1?
product.img: What prohibits us from doing the same as with the updates.img? The two are arguably really about the same thing - making modifications to the stage2 image. The product.img just modifies the available installclasses. That's still modifying anaconda's source files if you think about it.
Yes, but logically, a product.img is more related to your packages than to your installer. Maybe this is just the sign that we need to blow up install classes like I've been threatening to do for years.
Well I can certainly just remove the code to download them and then you'll have no choices besides fixing product.img or hoping no one ever asks for it back.
- Chris
product.img: What prohibits us from doing the same as with the updates.img? The two are arguably really about the same thing -
making
modifications to the stage2 image. The product.img just modifies the available installclasses. That's still modifying anaconda's source files if you think about it.
Yes, but logically, a product.img is more related to your packages than to your installer. Maybe this is just the sign that we need to blow up install classes like I've been threatening to do for years.
Well I can certainly just remove the code to download them and then you'll have no choices besides fixing product.img or hoping no one ever asks for it back.
product.img's are quite useful for creating custom spins w/o needing to run a full buildinstall. In our case, we automatically generate them to provide custom .buildstamp, installclass, and pixmap files.
-Kay
On Thu, May 01, 2008 at 05:12:42PM -0700, Kay Williams wrote:
product.img: What prohibits us from doing the same as with the updates.img? The two are arguably really about the same thing -
making
modifications to the stage2 image. The product.img just modifies the available installclasses. That's still modifying anaconda's source files if you think about it.
Yes, but logically, a product.img is more related to your packages than to your installer. Maybe this is just the sign that we need to blow up install classes like I've been threatening to do for years.
Well I can certainly just remove the code to download them and then you'll have no choices besides fixing product.img or hoping no one ever asks for it back.
product.img's are quite useful for creating custom spins w/o needing to run a full buildinstall. In our case, we automatically generate them to provide custom .buildstamp, installclass, and pixmap files.
We do something similar by generating a product.img from a package, anaconda-custom, which allows customers to customize most any part of anaconda that they would like. By default we use this to generate a custom set of pixmaps and a .buildstamp.
Elliot
On Thu, 2008-05-01 at 21:29 -0400, Elliot Peele wrote:
On Thu, May 01, 2008 at 05:12:42PM -0700, Kay Williams wrote:
product.img: What prohibits us from doing the same as with the updates.img? The two are arguably really about the same thing -
making
modifications to the stage2 image. The product.img just modifies the available installclasses. That's still modifying anaconda's source files if you think about it.
Yes, but logically, a product.img is more related to your packages than to your installer. Maybe this is just the sign that we need to blow up install classes like I've been threatening to do for years.
Well I can certainly just remove the code to download them and then you'll have no choices besides fixing product.img or hoping no one ever asks for it back.
product.img's are quite useful for creating custom spins w/o needing to run a full buildinstall. In our case, we automatically generate them to provide custom .buildstamp, installclass, and pixmap files.
We do something similar by generating a product.img from a package, anaconda-custom, which allows customers to customize most any part of anaconda that they would like. By default we use this to generate a custom set of pixmaps and a .buildstamp.
The big question (in my mind) is if product.img continues to be the best mechanism for doing things like this. The sorts of things that get set with a product.img are things that are largely tied to the set of packages being installed. As we move the repo selection to be _after_ all of those things taking effect, I'm not as sure that product.img still makes sense.
Jeremy
Jeremy Katz (katzj@redhat.com) said:
The big question (in my mind) is if product.img continues to be the best mechanism for doing things like this. The sorts of things that get set with a product.img are things that are largely tied to the set of packages being installed. As we move the repo selection to be _after_ all of those things taking effect, I'm not as sure that product.img still makes sense.
Where else will you put them? In the repo?
Bill
On Thu, 2008-05-01 at 22:00 -0400, Bill Nottingham wrote:
Jeremy Katz (katzj@redhat.com) said:
The big question (in my mind) is if product.img continues to be the best mechanism for doing things like this. The sorts of things that get set with a product.img are things that are largely tied to the set of packages being installed. As we move the repo selection to be _after_ all of those things taking effect, I'm not as sure that product.img still makes sense.
Where else will you put them? In the repo?
That doesn't help things unless we move repo selection earlier. Which we don't really want to do. I'm not sure really what the answer is right now, but I think it does require looking at a) what's being changed b) the conditions under which those things want to be changed
so that we can try to actually come up with a reasonable path to handling them. Which may just be falling back to a product.img like we do today and having it on boot.iso/cd1
Jeremy
On Thu, May 01, 2008 at 09:43:22PM -0400, Jeremy Katz wrote:
On Thu, 2008-05-01 at 21:29 -0400, Elliot Peele wrote:
On Thu, May 01, 2008 at 05:12:42PM -0700, Kay Williams wrote:
product.img: What prohibits us from doing the same as with the updates.img? The two are arguably really about the same thing -
making
modifications to the stage2 image. The product.img just modifies the available installclasses. That's still modifying anaconda's source files if you think about it.
Yes, but logically, a product.img is more related to your packages than to your installer. Maybe this is just the sign that we need to blow up install classes like I've been threatening to do for years.
Well I can certainly just remove the code to download them and then you'll have no choices besides fixing product.img or hoping no one ever asks for it back.
product.img's are quite useful for creating custom spins w/o needing to run a full buildinstall. In our case, we automatically generate them to provide custom .buildstamp, installclass, and pixmap files.
We do something similar by generating a product.img from a package, anaconda-custom, which allows customers to customize most any part of anaconda that they would like. By default we use this to generate a custom set of pixmaps and a .buildstamp.
The big question (in my mind) is if product.img continues to be the best mechanism for doing things like this. The sorts of things that get set with a product.img are things that are largely tied to the set of packages being installed. As we move the repo selection to be _after_ all of those things taking effect, I'm not as sure that product.img still makes sense.
Most of the customizations that I have seen are more than just changing package selection. They tend to be things like adding extra install steps for configuring customer applications. In fact most of our customers don't use package selection at all since they control what gets installed through conary groups.
Elliot
On Thu, 2008-05-01 at 22:24 -0400, Elliot Peele wrote:
On Thu, May 01, 2008 at 09:43:22PM -0400, Jeremy Katz wrote:
On Thu, 2008-05-01 at 21:29 -0400, Elliot Peele wrote:
On Thu, May 01, 2008 at 05:12:42PM -0700, Kay Williams wrote:
> product.img: What prohibits us from doing the same as with the > updates.img? The two are arguably really about the same thing -
making
> modifications to the stage2 image. The product.img just modifies the > available installclasses. That's still modifying anaconda's source > files if you think about it.
Yes, but logically, a product.img is more related to your packages than to your installer. Maybe this is just the sign that we need to blow up install classes like I've been threatening to do for years.
Well I can certainly just remove the code to download them and then you'll have no choices besides fixing product.img or hoping no one ever asks for it back.
product.img's are quite useful for creating custom spins w/o needing to run a full buildinstall. In our case, we automatically generate them to provide custom .buildstamp, installclass, and pixmap files.
We do something similar by generating a product.img from a package, anaconda-custom, which allows customers to customize most any part of anaconda that they would like. By default we use this to generate a custom set of pixmaps and a .buildstamp.
The big question (in my mind) is if product.img continues to be the best mechanism for doing things like this. The sorts of things that get set with a product.img are things that are largely tied to the set of packages being installed. As we move the repo selection to be _after_ all of those things taking effect, I'm not as sure that product.img still makes sense.
Most of the customizations that I have seen are more than just changing package selection. They tend to be things like adding extra install steps for configuring customer applications. In fact most of our customers don't use package selection at all since they control what gets installed through conary groups.
Right, but those applications don't exist in a generic repository -- the exist in a very specific one. Hence, the changes are geared towards "the set of stuff that I'm installing" more than "the installer I used to do the install"
Jeremy
On Thu, 2008-05-01 at 22:24 -0400, Elliot Peele wrote:
On Thu, May 01, 2008 at 09:43:22PM -0400, Jeremy Katz wrote:
On Thu, 2008-05-01 at 21:29 -0400, Elliot Peele wrote:
On Thu, May 01, 2008 at 05:12:42PM -0700, Kay Williams wrote:
> product.img: What prohibits us from doing the same as with the > updates.img? The two are arguably really about the same thing -
making
> modifications to the stage2 image. The product.img just modifies the > available installclasses. That's still modifying anaconda's source > files if you think about it.
Yes, but logically, a product.img is more related to your packages than to your installer. Maybe this is just the sign that we need to blow up install classes like I've been threatening to do for years.
Well I can certainly just remove the code to download them and then you'll have no choices besides fixing product.img or hoping no one ever asks for it back.
product.img's are quite useful for creating custom spins w/o needing to run a full buildinstall. In our case, we automatically generate them to provide custom .buildstamp, installclass, and pixmap files.
We do something similar by generating a product.img from a package, anaconda-custom, which allows customers to customize most any part of anaconda that they would like. By default we use this to generate a custom set of pixmaps and a .buildstamp.
The big question (in my mind) is if product.img continues to be the best mechanism for doing things like this. The sorts of things that get set with a product.img are things that are largely tied to the set of packages being installed. As we move the repo selection to be _after_ all of those things taking effect, I'm not as sure that product.img still makes sense.
Most of the customizations that I have seen are more than just changing package selection. They tend to be things like adding extra install steps for configuring customer applications. In fact most of our customers don't use package selection at all since they control what gets installed through conary groups.
Greetings Elliot,
This might not work for your particular use case, but thought it worth tossing out there. Would firstboot plugins make sense for some of the local customizations you're looking for?
NOTE: I'm coming at this from a reducing test paths perspective
Thanks, James
On Fri, May 02, 2008 at 07:59:43AM -0400, James Laska wrote:
On Thu, 2008-05-01 at 22:24 -0400, Elliot Peele wrote:
On Thu, May 01, 2008 at 09:43:22PM -0400, Jeremy Katz wrote:
On Thu, 2008-05-01 at 21:29 -0400, Elliot Peele wrote:
On Thu, May 01, 2008 at 05:12:42PM -0700, Kay Williams wrote:
> > product.img: What prohibits us from doing the same as with the > > updates.img? The two are arguably really about the same thing -
making
> > modifications to the stage2 image. The product.img just modifies the > > available installclasses. That's still modifying anaconda's source > > files if you think about it. > > Yes, but logically, a product.img is more related to your packages than > to your installer. Maybe this is just the sign that we need to blow up > install classes like I've been threatening to do for years.
Well I can certainly just remove the code to download them and then you'll have no choices besides fixing product.img or hoping no one ever asks for it back.
product.img's are quite useful for creating custom spins w/o needing to run a full buildinstall. In our case, we automatically generate them to provide custom .buildstamp, installclass, and pixmap files.
We do something similar by generating a product.img from a package, anaconda-custom, which allows customers to customize most any part of anaconda that they would like. By default we use this to generate a custom set of pixmaps and a .buildstamp.
The big question (in my mind) is if product.img continues to be the best mechanism for doing things like this. The sorts of things that get set with a product.img are things that are largely tied to the set of packages being installed. As we move the repo selection to be _after_ all of those things taking effect, I'm not as sure that product.img still makes sense.
Most of the customizations that I have seen are more than just changing package selection. They tend to be things like adding extra install steps for configuring customer applications. In fact most of our customers don't use package selection at all since they control what gets installed through conary groups.
Greetings Elliot,
This might not work for your particular use case, but thought it worth tossing out there. Would firstboot plugins make sense for some of the local customizations you're looking for?
NOTE: I'm coming at this from a reducing test paths perspective
firstboot doesn't really work for us for a few reasons.
* We don't include firstboot due to its dependency on selinux * This is intended for software appliances where we want minimal user interaction post install. * We do have our own sort of configuration wizard[1] for customers to write plugins for, but now all of them choose to go down that path for appliance customizations.
Elliot
[1] http://wiki.rpath.com/wiki/rPath_Appliance_Platform_Agent
Elliot Peele wrote: <much needed snipping>
Greetings Elliot,
This might not work for your particular use case, but thought it worth tossing out there. Would firstboot plugins make sense for some of the local customizations you're looking for?
NOTE: I'm coming at this from a reducing test paths perspective
firstboot doesn't really work for us for a few reasons.
- We don't include firstboot due to its dependency on selinux
- This is intended for software appliances where we want minimal user interaction post install.
I was using the idea of firstboot before Red Hat introduced it; all you need is to put some scripts in place (~root if you wish) and then run them, either from /etc/rc.local or from /etc/init.d with the usual symlinks. I used to put them in place from %post, but there's nothing preventing them from being packaged if that's your preference.
Chris Lumens wrote:
I think everyone's familiar with the mess that is prompting for the method in loader and fetching the stage2 image. It's too late to do anything for F9 besides patch the bugs, but it's time to start thinking about what to do for F10. So, let's start thinking about it.
The way I see it, the loader currently does the following things regarding setting up the method:
- Support the following installation sources: http/ftp, dvd/cd, nfs, nfsiso, hdiso. It'd also be nice to support regular hd installs.
Think I have that one worked out worked out...
- If stage2= is given, use that as the stage2 image.
- If there's a CD in the drive and there's a stage2 image on it, use that. stage2= overrides this.
That is do-able..
- Support configuration from UI, cmdline, and kickstart.
- Configure and bring up the network if required for a method.
Or if ks= or updates= are passed and need the network...
- DVD/CD should prompt for media check.
- Each method implies certain locations for updates.img, product.img, etc. that are checked for automatically.
Noted.. as in ~/images /tmp /RHupdates? Did I forget any?
Those are the current features, best I can see. Are there any of these features we want to do away with? Does anything no longer make sense?
Take away features? Your asking for trouble here... ;-)
Now for the more controversial stuff. Here's what I would like to see happen in this area for F10. All these things are open for discussion, so jump right in.
There shouldn't be any differences between booting off the network and booting off media.
loader should be moving to just doing what is required to fetch and mount the stage2 image. This can perhaps include inferring an installation repo based on the location of the stage2 image, but the
Problem: If the user booted off a CD and we don't have any method configuration screen, the implied updates.img and product.img checks will never work.
Yea, would be looking to the cd for the updates. A screen that asks if you want to check for updates? If yes, enable the the network and check the fedora mirrors for the updates.img and product.img that may exist in ~url/images. The check could entail the main repo or maybe the updates repo. If updates repo, if chosen by fedora as the spot for their home, then enable that repo for the rest of the install would be a nice touch, install and update at first install.
- We shouldn't be checking if the inferred repo is valid in any way, perhaps except that we can at least mount it (if the method requires that). This requires making the repo editor in stage2 more useful. It also separates the loader from the payload it's installing more. In particular, any remaining .discinfo checks ought to die.
That is a PITA IMHO, yes please...
- We shouldn't leave the repo mounted at the end of loader.
Can you expand on why that is needed?
Problem: RHupdates/ will no longer work.
Think that still might work, that gets copied to /tmp early in the loader when validating /mnt/source.
Problem: This means both loader and stage2 will have to have some code for mounting installation sources. This probably isn't such a big problem because stage2 will already require it for error handling.
Part of the last one... we should copy the stage2 image out of its initial location. My reasoning for this is still that it makes error handling easier when the repo has trouble. This requires making the repo editor more useful too.
Problem: This increases the memory requirements,
That one kills low resource machines. I'm not in favor of that.
Your thoughts? Once we at least have some concept of what should be going on, I can get started on working on a code design - hopefully one that removes a lot more than it adds.
There is the "findAnacondaCD" call in loader.c that will try to mount the "anaconda iso". It is one of the first things loader does, that would be the best place to do /mnt/stage2 across all installs when the boot.iso is found. Check first /mnt/source with requirepkgs=true, if met, use that. Then if that fails, try mount at /mnt/stage2 with requirepkgs=false. Guess you'd need to check for stage2= flag first before the above test. Does that make sense?
Then in the future(not right now), with the early mount of stage2, you could make tty2 available much earlier than it is now.
Yes, there would an issue when checking for the hdiso, nfsiso installs with this idea, when testing for the iso, the test uses the same loop device as what would be already in use for stage2. That could be fixed with an unmount before the test or change the test loop device (wow, that is a bunch easier now that I think of it). What would be a safe loop device to use? I could dig, but someone should know.
I think for a cd/dvd the current code would be fine.
I've been playing around with that, got some of the code done. I'll re-sync with the current git and see what I might come up with.
Need some feedback, and I'll post some "rough work" patches to get some more feedback. Sorry, I won't have any time till Friday to throw at this.
Jerry
- Support the following installation sources: http/ftp, dvd/cd, nfs, nfsiso, hdiso. It'd also be nice to support regular hd installs.
Think I have that one worked out worked out...
...assuming we even want to do it. See Jeremy's mail later in this thread.
- Each method implies certain locations for updates.img, product.img, etc. that are checked for automatically.
Noted.. as in ~/images /tmp /RHupdates? Did I forget any?
As far as I can tell, these are the options:
- RHupdates for NFS installs only - the images/ subdirectory for URL installs, CDs, ISO images, etc. - the same directory as the ISO images themselves for HDISO and NFSISO - on a floppy if 'updates' is given for all methods - via updates= for all methods
Also I think (but I'm not sure) that you can have both an updates image or RHupdates in the tree, and then provide additional updates via updates=. Horrifying.
Take away features? Your asking for trouble here... ;-)
Oh I knew that the day I started working on anaconda. Anyway I think that if we're going to talk about what we should do with loader/stage2, we might as well leave everything open to discussion. If there's some really bizarre feature that makes everything else difficult, perhaps we should investigate removing it.
Yea, would be looking to the cd for the updates. A screen that asks if you want to check for updates? If yes, enable the the network and check the fedora mirrors for the updates.img and product.img that may exist in ~url/images. The check could entail the main repo or maybe the updates repo. If updates repo, if chosen by fedora as the spot for their home, then enable that repo for the rest of the install would be a nice touch, install and update at first install.
I think we're mixing up our terms here. When you say "updates repo", are you referring to the repository of packages made available after a release is made? If so, that's a totally different discussion that I think is also worth having, but we should move to another thread.
On the other hand if you mean an updates.img that patches possible bugs in anaconda (which is what I've been referring to throughout this mail - sorry for any confusion) then I don't like the idea of asking the user if they want to check. I'd rather we continue to do what we're doing - have the user provide a cmdline argument in addition to us automatically looking in a few locations.
Will Woods also likes the idea of making available a well-known URL that anaconda could automatically check (like http://www.fedoraupdates.org/<arch>/<release>/updates.img, for instance). I don't think I would do this automatically either, but maybe use the 'updates' or add 'updates=auto' to trigger that behavior.
I can see there's going to be a lot of talking about updates images. Since we are absolutely going to be preserving this behavior in our loader rework, perhaps it's worth moving all that off into a new thread anyway.
- We shouldn't be checking if the inferred repo is valid in any way, perhaps except that we can at least mount it (if the method requires that). This requires making the repo editor in stage2 more useful. It also separates the loader from the payload it's installing more. In particular, any remaining .discinfo checks ought to die.
That is a PITA IMHO, yes please...
Good. I don't think this is going to be one of the controversial points then.
- We shouldn't leave the repo mounted at the end of loader.
Can you expand on why that is needed?
Sure. Our plan for loader is this: "Right now, the loader downloads the stage2 image and sets up the installation repo. Instead, loader should only grab the stage2 image and save the repo setup for later."
Why would we want to do this? Well, moving stuff out of loader has its benefits. First it's easier for us to program, test, and debug if the code is in python. Second, it's possible for us to provide updates images to fix bugs in this area if we move it to python. That's not currently possible since it's in the loader. Third, because it's easier to program and test, we can come up with interesting new features quicker.
Problem: RHupdates/ will no longer work.
Think that still might work, that gets copied to /tmp early in the loader when validating /mnt/source.
Yep, I think we have a handle on this one.
Problem: This increases the memory requirements,
That one kills low resource machines. I'm not in favor of that.
I think Jeremy has a good handle on this one too.
Then in the future(not right now), with the early mount of stage2, you could make tty2 available much earlier than it is now.
I'm not sure how much earlier we can do it, but I'm all for investigating.
Only somewhat relatedly, I'm going to be investigating adding a hook for running gdbserver during the loader. The idea here is that if you provide a second initrd with gdbserver in it, loader will detect that and run it in case of emergency. Then we have better debugging capabilities without adding lots of code that everyone ends up running. You know, since you mentioned debugging and all...
Yes, there would an issue when checking for the hdiso, nfsiso installs with this idea, when testing for the iso, the test uses the same loop device as what would be already in use for stage2. That could be fixed with an unmount before the test or change the test loop device (wow, that is a bunch easier now that I think of it). What would be a safe loop device to use? I could dig, but someone should know.
I think for a cd/dvd the current code would be fine.
I've been playing around with that, got some of the code done. I'll re-sync with the current git and see what I might come up with.
Need some feedback, and I'll post some "rough work" patches to get some more feedback. Sorry, I won't have any time till Friday to throw at this.
Other people may differ with me here, but I would really rather just destroy all the code we've got in *install.c and start over. I think it's really quite a mess and starting with blank files might yield better results. I guess we wouldn't totally wipe out the contents. I'm sure there's some good stuff in there. But you get my point.
If that's the approach we want to take, perhaps a better use of your time would be to start thinking about how you would design the code instead of trying to beat the existing stuff into shape. You certainly seem motivated to work on this area, so I'd hate for you to do a lot of work only to make it no longer apply by starting from scratch.
Opinions?
- Chris
Chris Lumens wrote:
- Support the following installation sources: http/ftp, dvd/cd, nfs, nfsiso, hdiso. It'd also be nice to support regular hd installs.
Think I have that one worked out worked out...
...assuming we even want to do it. See Jeremy's mail later in this thread.
I'll just keep it for myself then, but sure makes testing easier, remount rw and I can copy the log/dumps somewhere.
- Each method implies certain locations for updates.img, product.img, etc. that are checked for automatically.
Noted.. as in ~/images /tmp /RHupdates? Did I forget any?
As far as I can tell, these are the options:
- RHupdates for NFS installs only
- the images/ subdirectory for URL installs, CDs, ISO images, etc.
- the same directory as the ISO images themselves for HDISO and NFSISO
- on a floppy if 'updates' is given for all methods
- via updates= for all methods
Also I think (but I'm not sure) that you can have both an updates image or RHupdates in the tree, and then provide additional updates via updates=. Horrifying.
I like /RHupdates, I used that with the livecd install from anaconda hack from while ago, for the same reason I like the straight HD non-iso option, ease of testing.
Take away features? Your asking for trouble here... ;-)
Oh I knew that the day I started working on anaconda. Anyway I think that if we're going to talk about what we should do with loader/stage2, we might as well leave everything open to discussion. If there's some really bizarre feature that makes everything else difficult, perhaps we should investigate removing it.
Yea, would be looking to the cd for the updates. A screen that asks if you want to check for updates? If yes, enable the the network and check the fedora mirrors for the updates.img and product.img that may exist in ~url/images. The check could entail the main repo or maybe the updates repo. If updates repo, if chosen by fedora as the spot for their home, then enable that repo for the rest of the install would be a nice touch, install and update at first install.
I think we're mixing up our terms here. When you say "updates repo", are you referring to the repository of packages made available after a release is made? If so, that's a totally different discussion that I think is also worth having, but we should move to another thread.
Sorry, run on thought.. both...
On the other hand if you mean an updates.img that patches possible bugs in anaconda (which is what I've been referring to throughout this mail - sorry for any confusion) then I don't like the idea of asking the user if they want to check. I'd rather we continue to do what we're doing - have the user provide a cmdline argument in addition to us automatically looking in a few locations.
Will Woods also likes the idea of making available a well-known URL that anaconda could automatically check (like http://www.fedoraupdates.org/<arch>/<release>/updates.img, for instance). I don't think I would do this automatically either, but maybe use the 'updates' or add 'updates=auto' to trigger that behavior.
Yes, for sure, updates=auto, setup the fetch from a URL. That leads to the question, where should this image live? I'm in favor of having updates.img live in the updates repo. Then that same trigger could be used to enable the update.repo later in the install.
I can see there's going to be a lot of talking about updates images. Since we are absolutely going to be preserving this behavior in our loader rework, perhaps it's worth moving all that off into a new thread anyway.
I'm suggesting the use of the updates repo for the URL, as that is the one that would be sync'd by advanced users, to keep things updated in their home mirrors. Once I download the original tree for a release, I don't try to re-sync that one, the content shouldn't change, that is what updates repo is for. A new thread would be the best, I'll leave any more talk for that one.
- We shouldn't be checking if the inferred repo is valid in any way, perhaps except that we can at least mount it (if the method requires that). This requires making the repo editor in stage2 more useful. It also separates the loader from the payload it's installing more. In particular, any remaining .discinfo checks ought to die.
That is a PITA IMHO, yes please...
Good. I don't think this is going to be one of the controversial points then.
- We shouldn't leave the repo mounted at the end of loader.
Can you expand on why that is needed?
Sure. Our plan for loader is this: "Right now, the loader downloads the stage2 image and sets up the installation repo. Instead, loader should only grab the stage2 image and save the repo setup for later."
Why would we want to do this? Well, moving stuff out of loader has its benefits. First it's easier for us to program, test, and debug if the code is in python. Second, it's possible for us to provide updates images to fix bugs in this area if we move it to python. That's not currently possible since it's in the loader. Third, because it's easier to program and test, we can come up with interesting new features quicker.
OK, should I be thinking that stage2= will be the replacement for method= for stage1? I'm getting that feeling, just want to be sure.
Problem: RHupdates/ will no longer work.
Think that still might work, that gets copied to /tmp early in the loader when validating /mnt/source.
Yep, I think we have a handle on this one.
Problem: This increases the memory requirements,
That one kills low resource machines. I'm not in favor of that.
I think Jeremy has a good handle on this one too.
Then in the future(not right now), with the early mount of stage2, you could make tty2 available much earlier than it is now.
I'm not sure how much earlier we can do it, but I'm all for investigating.
Right after the mount of stage2 would be nice, bash is now there.
Only somewhat relatedly, I'm going to be investigating adding a hook for running gdbserver during the loader. The idea here is that if you provide a second initrd with gdbserver in it, loader will detect that and run it in case of emergency. Then we have better debugging capabilities without adding lots of code that everyone ends up running. You know, since you mentioned debugging and all...
Sounds interesting, how would you go about the second initrd.img? Just in general, a pointer to a wiki page would be enough for me.
Yes, there would an issue when checking for the hdiso, nfsiso installs with this idea, when testing for the iso, the test uses the same loop device as what would be already in use for stage2. That could be fixed with an unmount before the test or change the test loop device (wow, that is a bunch easier now that I think of it). What would be a safe loop device to use? I could dig, but someone should know.
I think for a cd/dvd the current code would be fine.
I've been playing around with that, got some of the code done. I'll re-sync with the current git and see what I might come up with.
Need some feedback, and I'll post some "rough work" patches to get some more feedback. Sorry, I won't have any time till Friday to throw at this.
Other people may differ with me here, but I would really rather just destroy all the code we've got in *install.c and start over. I think it's really quite a mess and starting with blank files might yield better results. I guess we wouldn't totally wipe out the contents. I'm sure there's some good stuff in there. But you get my point.
I'm getting the feeling that if it's not an iso type of install, then support for the that which maybe used for a custom tree on a hard drive or via nfs is unwanted. I understand that from a support point of view, just that limits outsiders(me) from playing around with the install tree. Having to do a re-make of an iso for something like testing changes to comps.xml makes me a bit ill. Could just be a "use at your own risk / unsupported" option with the patches welcome warning... Guess I'll just use net based installs to test my custom repos then.
If that's the approach we want to take, perhaps a better use of your time would be to start thinking about how you would design the code instead of trying to beat the existing stuff into shape. You certainly seem motivated to work on this area, so I'd hate for you to do a lot of work only to make it no longer apply by starting from scratch.
Opinions?
- Chris
I suppose I'll have to get used to using just the updates.img, that does have support for using of a custom comps.xml file for the anaconda repo? That, and the repo editor would make a great tool. Sorry, I have not kept up with that part of the code, or can the repo editor make use of a custom comps.xml file? I toggle some of the default/options, or does that fall under unsupported?
Jerry
On Thu, 2008-04-24 at 21:26 -0500, Jerry Vonau wrote:
Chris Lumens wrote:
Will Woods also likes the idea of making available a well-known URL that anaconda could automatically check (like http://www.fedoraupdates.org/<arch>/<release>/updates.img, for instance). I don't think I would do this automatically either, but maybe use the 'updates' or add 'updates=auto' to trigger that behavior.
Yes, for sure, updates=auto, setup the fetch from a URL. That leads to the question, where should this image live? I'm in favor of having updates.img live in the updates repo. Then that same trigger could be used to enable the update.repo later in the install.
Except the updates repos are only for stable releases, so if we use that we need a *different* location for rawhide updates.img. And then we need a way for anaconda to know if it's the final, stable release or if it's rawhide.
Probably easier to just have a single host, like: http://fedoraupdates.org/ And have a defined search path for the updates.img, like: /by-release/$release/$arch/updates.img /by-release/$release/updates.img
But... The problem with using $release is that we fudge the release numbers a lot. Right now, rawhide thinks it's release 9. When the Unity guys do a respin of F9, *that* will also think it's release 9, even though they've presumably included fixes for the things we needed the updates.img for in the first place.
Furthermore, that doesn't help if Rawhide needs an updates.img for a couple of days while we get something fixed.
So maybe the better thing would be to have a CGI script that took a couple arguments, like:
http://fedoraupdates.org/anaconda-auto?ts=$timestamp&arch=$arch
And the CGI can do a lookup to figure out if that tree needs an updates.img.
Of course, that means we need a simple map/database to do the lookup in.. and probably a nice web frontend to add new images and modify the database.. but this is probably one of those things that's implementable in 30 lines with TurboGears or something.
-w
Will Woods wrote:
Except the updates repos are only for stable releases, so if we use that we need a *different* location for rawhide updates.img. And then we need a way for anaconda to know if it's the final, stable release or if it's rawhide.
Is there an objection to burning that bit if info into the isolinux/syslinux/pxelinux/grub menu when the install tree/iso images are generated?
But then one would need to _build_ a production-quality Anaconda rpm for building the production-quality distro, so maybe a (documented!) --define on rpmbuild?
I can see there's going to be a lot of talking about updates images. Since we are absolutely going to be preserving this behavior in our loader rework, perhaps it's worth moving all that off into a new thread anyway.
I'm suggesting the use of the updates repo for the URL, as that is the one that would be sync'd by advanced users, to keep things updated in their home mirrors. Once I download the original tree for a release, I don't try to re-sync that one, the content shouldn't change, that is what updates repo is for. A new thread would be the best, I'll leave any more talk for that one.
The updates repo isn't guaranteed to contain the entire package set, though. It's just going to have packages that have published updates since the final release. So we can't really use the updates repo for the URL.
What I'd really like to do is have a checkbox in the repo selection UI (tasksel.glade in case you're curious) that enables the updates AND check that box by default. I know we've threatened this in the past.
OK, should I be thinking that stage2= will be the replacement for method= for stage1? I'm getting that feeling, just want to be sure.
Yes, though not really a complete replacement. The final goal is that stage2= points to just the stage2.img file, while method= points to just the package repository. Perhaps at that point we rename it to repo= to avoid confusion? Don't know quite what to do here yet.
Only somewhat relatedly, I'm going to be investigating adding a hook for running gdbserver during the loader. The idea here is that if you provide a second initrd with gdbserver in it, loader will detect that and run it in case of emergency. Then we have better debugging capabilities without adding lots of code that everyone ends up running. You know, since you mentioned debugging and all...
Sounds interesting, how would you go about the second initrd.img? Just in general, a pointer to a wiki page would be enough for me.
If you PXE boot, you can specify multiple initrd lines and they'll all get combined together to work. I'd just make a second initrd containing gdbserver and add a new target for booting with it.
For other booting methods, I don't know right now. I'm sure we can figure something out for CDs and the like.
I'm getting the feeling that if it's not an iso type of install, then support for the that which maybe used for a custom tree on a hard drive or via nfs is unwanted. I understand that from a support point of view, just that limits outsiders(me) from playing around with the install tree. Having to do a re-make of an iso for something like testing changes to comps.xml makes me a bit ill. Could just be a "use at your own risk / unsupported" option with the patches welcome warning... Guess I'll just use net based installs to test my custom repos then.
Hm, no, it's not my intention to remove all the support for customizing ISO image installs. I do want to keep around the implicit updates.img locations so you don't have to rebuild images, as I agree that's a total pain. We just need to think up good ways to support these customizations without creating a giant mess.
I suppose I'll have to get used to using just the updates.img, that does have support for using of a custom comps.xml file for the anaconda repo? That, and the repo editor would make a great tool. Sorry, I have not kept up with that part of the code, or can the repo editor make use of a custom comps.xml file? I toggle some of the default/options, or does that fall under unsupported?
Yeah, probably best to get used to using updates.img.
You're looking to have a new comps.xml file in the updates.img that overrides the one in the installation repo? I don't think we support that in RHupdates or updates.img right now. Anyone else want to take a stab at answering this part?
As for the modified repo editor... I'll be posting my UI mock up for that later today I think. I want to make sure the list stays lively, after all.
- Chris
On Wed, 2008-04-30 at 09:53 -0400, Chris Lumens wrote:
I can see there's going to be a lot of talking about updates images. Since we are absolutely going to be preserving this behavior in our loader rework, perhaps it's worth moving all that off into a new thread anyway.
I'm suggesting the use of the updates repo for the URL, as that is the one that would be sync'd by advanced users, to keep things updated in their home mirrors. Once I download the original tree for a release, I don't try to re-sync that one, the content shouldn't change, that is what updates repo is for. A new thread would be the best, I'll leave any more talk for that one.
The updates repo isn't guaranteed to contain the entire package set, though. It's just going to have packages that have published updates since the final release. So we can't really use the updates repo for the URL.
What I'd really like to do is have a checkbox in the repo selection UI (tasksel.glade in case you're curious) that enables the updates AND check that box by default. I know we've threatened this in the past.
The big outstanding thing that needs solving for this is how do we sanely do this for media installs without requiring six billion cd changes? Or, I guess we could just punt and not show it if you're installing from a multi-disc repo
Jeremy
Jeremy Katz wrote:
The big outstanding thing that needs solving for this is how do we sanely do this for media installs without requiring six billion cd changes? Or, I guess we could just punt and not show it if you're installing from a multi-disc repo
For how much longer is CD support required? Recent computers have (at least) a DVD drive, DVD drives are cheap, and while some might complain, there are other good reasons to replace CD drives with DVD.
The machines under my care where this would be a problem are all networked, so PXE and boot.iso both are feasible. As is an install from USB disk, another cheap option.
On Thu, 2008-05-01 at 07:00 +0800, John Summerfield wrote:
Jeremy Katz wrote:
The big outstanding thing that needs solving for this is how do we sanely do this for media installs without requiring six billion cd changes? Or, I guess we could just punt and not show it if you're installing from a multi-disc repo
For how much longer is CD support required? Recent computers have (at least) a DVD drive, DVD drives are cheap, and while some might complain, there are other good reasons to replace CD drives with DVD.
There are (sadly) still a lot of people who clamor for CDs. And we'll be to multiple DVDs before long anyway... :-/
Jeremy
Chris Lumens wrote:
If you PXE boot, you can specify multiple initrd lines and they'll all get combined together to work. I'd just make a second initrd containing gdbserver and add a new target for booting with it.
For other booting methods, I don't know right now. I'm sure we can figure something out for CDs and the like.
grub supports multiple module lines, are those useful?
Hm, no, it's not my intention to remove all the support for customizing ISO image installs. I do want to keep around the implicit updates.img locations so you don't have to rebuild images, as I agree that's a total pain. We just need to think up good ways to support these customizations without creating a giant mess.
Does updates.img provide a way to sneak a kickstart file in? Is updates.img sought automatically? or does one need to add the the kernel options?
For other booting methods, I don't know right now. I'm sure we can figure something out for CDs and the like.
grub supports multiple module lines, are those useful?
Unknown. We'd have to investigate.
Hm, no, it's not my intention to remove all the support for customizing ISO image installs. I do want to keep around the implicit updates.img locations so you don't have to rebuild images, as I agree that's a total pain. We just need to think up good ways to support these customizations without creating a giant mess.
Does updates.img provide a way to sneak a kickstart file in? Is updates.img sought automatically? or does one need to add the the kernel options?
No, you can't put a kickstart file in an updates.img and have it work. But then, you couldn't do that with RHupdates/ either could you?
Each method has its own special locations where an updates.img can be placed and anaconda will automatically grab it. For instance, on an HDISO or NFSISO installation, an updates.img in the same directory with the ISO images will get picked up and used.
Besides that no, you have to add updates[=<url>] for anaconda to pick one up.
- Chris
Chris Lumens wrote:
I can see there's going to be a lot of talking about updates images. Since we are absolutely going to be preserving this behavior in our loader rework, perhaps it's worth moving all that off into a new thread anyway.
I'm suggesting the use of the updates repo for the URL, as that is the one that would be sync'd by advanced users, to keep things updated in their home mirrors. Once I download the original tree for a release, I don't try to re-sync that one, the content shouldn't change, that is what updates repo is for. A new thread would be the best, I'll leave any more talk for that one.
The updates repo isn't guaranteed to contain the entire package set, though. It's just going to have packages that have published updates since the final release. So we can't really use the updates repo for the URL.
This would be just a default place to look for the availability of the latest, just one file, updates.img, if booted with "updates=auto", updates=/path would work as now, which is what rawhide could use. The updates.img is just a patch to what is on the boot.iso, it wouldn't need the whole (any?) rpm set, the users' choice of method/media would still be retained/used. How does/would fedora infrastructure deal with having the primary repo updated? I recall the 586 issue that just passed, a revised stage2 could not be (or didn't get) deployed, you had to wait for a "respin", with no revised boot.iso being released at all. I thought that was the idea behind the updates repo, the latest code for that release is in one area.
What I'd really like to do is have a checkbox in the repo selection UI (tasksel.glade in case you're curious) that enables the updates AND check that box by default. I know we've threatened this in the past.
I like that, would be the same as passing repo=updates=path as a repo in a kickstart file, updates without rebooting.
OK, should I be thinking that stage2= will be the replacement for method= for stage1? I'm getting that feeling, just want to be sure.
Yes, though not really a complete replacement. The final goal is that stage2= points to just the stage2.img file, while method= points to just the package repository. Perhaps at that point we rename it to repo= to avoid confusion? Don't know quite what to do here yet.
/wish list Maybe stage2.img and related boot.iso could just be moved to the updates repo all together. The boot.iso could then be updated, containing the latest changes that lead to the need for a updates.img in the first place, as required. Now you really have disconnected the location of stage2 from the primary repo. wish list/
Back to what is required now in loader, The boot.iso is mounted for stage2, if present, else look for an iso-image to use for stage2 for nfsiso, hd(iso), or tree-path for nfs. That just leaves net installs, where what you're really being asked is for the location of stage2 and not the location of a repo in stage1. Anaconda should then discard the net install's method-path, but not method, that is passed from loader when building its own repo list with data supplied from a kickstart file and/or the repo editor.
Does that sum up what maybe required here? Think all the *install.c files could become just one install.c file here. Is that what I should work towards?
Only somewhat relatedly, I'm going to be investigating adding a hook for running gdbserver during the loader. The idea here is that if you provide a second initrd with gdbserver in it, loader will detect that and run it in case of emergency. Then we have better debugging capabilities without adding lots of code that everyone ends up running. You know, since you mentioned debugging and all...
Sounds interesting, how would you go about the second initrd.img? Just in general, a pointer to a wiki page would be enough for me.
If you PXE boot, you can specify multiple initrd lines and they'll all get combined together to work. I'd just make a second initrd containing gdbserver and add a new target for booting with it.
For other booting methods, I don't know right now. I'm sure we can figure something out for CDs and the like.
Something new to play with in time.
I'm getting the feeling that if it's not an iso type of install, then support for the that which maybe used for a custom tree on a hard drive or via nfs is unwanted. I understand that from a support point of view, just that limits outsiders(me) from playing around with the install tree. Having to do a re-make of an iso for something like testing changes to comps.xml makes me a bit ill. Could just be a "use at your own risk / unsupported" option with the patches welcome warning... Guess I'll just use net based installs to test my custom repos then.
Hm, no, it's not my intention to remove all the support for customizing ISO image installs. I do want to keep around the implicit updates.img locations so you don't have to rebuild images, as I agree that's a total pain. We just need to think up good ways to support these customizations without creating a giant mess.
I know you don't want to kill off the iso installs, you want to kill off the NON-iso installs. If you keep thinking that the primary repo/mirror should have the updates.img, it becomes harder to kill off non-iso nfs/hd installs. My thinking would be if I could copy the content of my dvd somewhere for nfs/hd and add the newest updates.img, it should just work, and be supported. You have provided the complete tree, the same as if your were to setup a net install, IMHO.
I suppose I'll have to get used to using just the updates.img, that does have support for using of a custom comps.xml file for the anaconda repo? That, and the repo editor would make a great tool. Sorry, I have not kept up with that part of the code, or can the repo editor make use of a custom comps.xml file? I toggle some of the default/options, or does that fall under unsupported?
Yeah, probably best to get used to using updates.img.
You're looking to have a new comps.xml file in the updates.img that overrides the one in the installation repo? I don't think we support that in RHupdates or updates.img right now. Anyone else want to take a stab at answering this part?
Yes that is what I had in mind, override the one in the installation repo. For your own use it is just so easy to edit the comps.xml file, then run createrepo, for a custom non-iso nfs install source without having to jump thought the "respin" hoops. But it looks like non-net, non-iso sources are going away, sad, IMHO.
As for the modified repo editor... I'll be posting my UI mock up for that later today I think. I want to make sure the list stays lively, after all.
- Chris
Have not had a chance to look yet.
Just my 2 cents,
Jerry
Jerry Vonau wrote:
Chris Lumens wrote:
Yes, though not really a complete replacement. The final goal is that stage2= points to just the stage2.img file, while method= points to just the package repository. Perhaps at that point we rename it to repo= to avoid confusion? Don't know quite what to do here yet.
/wish list Maybe stage2.img and related boot.iso could just be moved to the updates repo all together. The boot.iso could then be updated, containing the latest changes that lead to the need for a updates.img in the first place, as required. Now you really have disconnected the location of stage2 from the primary repo. wish list/
Back to what is required now in loader, The boot.iso is mounted for stage2, if present, else look for an iso-image to use for stage2 for nfsiso, hd(iso), or tree-path for nfs. That just leaves net installs, where what you're really being asked is for the location of stage2 and not the location of a repo in stage1. Anaconda should then discard the net install's method-path, but not method, that is passed from loader when building its own repo list with data supplied from a kickstart file and/or the repo editor.
Does that sum up what maybe required here? Think all the *install.c files could become just one install.c file here. Is that what I should work towards?
I was thinking of something like setmethodfromcmdline but for stage2. attached is a rough patch and log from such an install. To do: port cdinstall to return stg2url for stage2.
I think is would help with preupgrade and rescue modes, being able to point stage2 to any available hard drive partition.
Just an idea,
Jerry
diff -u anaconda-11.4.0.82.orig/loader2/hdinstall.c anaconda-11.4.0.82/loader2/hdinstall.c --- anaconda-11.4.0.82.orig/loader2/hdinstall.c 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/hdinstall.c 2008-05-11 20:19:57.000000000 -0500 @@ -154,9 +154,9 @@ }
/* given a partition device and directory, tries to mount hd install image */ -static char * setupIsoImages(char * device, char * dirName, char * location) { +char * setupIsoImages(char * device, char * dirName, char * location) { int rc; - char *url = NULL, *dirspec, *updpath; + char *dirspec, *updpath, *url = NULL; char *path; char *typetry[] = {"ext3", "ext2", "vfat", NULL}; char **type; @@ -186,39 +187,29 @@ }
if (path) { - logMessage(INFO, "Path to valid iso is %s", path); + logMessage(INFO, "Path to stage2 is %s", path);
rc = asprintf(&updpath, "%s/updates.img", dirspec); logMessage(INFO, "Looking for updates for HD in %s", updpath); copyUpdatesImg(updpath);
free(updpath); - free(dirspec);
if (FL_STAGE2(flags)) { - if (!copyFile(path, "/tmp/stage2.img")) { - rc = mountStage2("/tmp/stage2.img", dirName); - umount("/mnt/isodir"); - free(path); - - if (rc) { - umountLoopback("/mnt/runtime", "/dev/loop0"); - flags &= ~LOADER_FLAGS_STAGE2; - goto err; - } else { - rc = asprintf(&url, "hd:%s:%s:/%s", - device, - *type, dirName ? dirName : "."); - return url; - } - } - else { - free(path); + /* rc = asprintf(&stg2url, "hd:%s:%s:/%s", + * device, + * *type, dirName ? dirName : "."); + */ + rc = mountStage2(path, dirspec); + free(path); + free(dirspec); + return NULL; + } else { umount("/mnt/isodir"); flags &= ~LOADER_FLAGS_STAGE2; - goto err; + /* goto err; + * free(path);*/ } - }
rc = mountLoopback(path, "/mnt/source", "/dev/loop1"); if (!rc) { @@ -284,6 +275,13 @@ char *selpart; char *kspartition, *ksdirectory;
+ /* handle stage2 data first if available */ + if (loaderData->stage2 == METHOD_HD && loaderData->stage2Data) { + kspartition = ((struct hdstage2Data *)loaderData->stage2Data)->partition; + ksdirectory = ((struct hdstage2Data *)loaderData->stage2Data)->directory; + logMessage(INFO, "HD Stage2 partition is %s, dir is %s", kspartition, ksdirectory); + } + /* handle kickstart data first if available */ if (loaderData->method == METHOD_HD && loaderData->methodData) { kspartition = ((struct hdInstallData *)loaderData->methodData)->partition;
diff -u anaconda-11.4.0.82.orig/loader2/hdinstall.h anaconda-11.4.0.82/loader2/hdinstall.h --- anaconda-11.4.0.82.orig/loader2/hdinstall.h 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/hdinstall.h 2008-05-11 19:21:25.000000000 -0500 @@ -27,7 +27,7 @@ char * directory; };
- +char * setupIsoImages(char * device, char * dirName, char * location); void setKickstartHD(struct loaderData_s * loaderData, int argc, char ** argv); char * mountHardDrive(struct installMethod * method,
--- anaconda-11.4.0.82.orig/loader2/loader.c 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/loader.c 2008-05-14 19:10:40.000000000 -0500 @@ -872,7 +872,7 @@ setMethodFromCmdline(argv[i] + 7, loaderData); else if (!strncasecmp(argv[i], "stage2=", 7)) { flags |= LOADER_FLAGS_STAGE2; - setMethodFromCmdline(argv[i] + 7, loaderData); + setStg2FromCmdline(argv[i] + 7, loaderData); } else if (!strncasecmp(argv[i], "hostname=", 9)) loaderData->hostname = strdup(argv[i] + 9); @@ -1016,6 +1016,7 @@ enum { STEP_LANG, STEP_KBD, STEP_METHOD, STEP_DRIVER, STEP_DRIVERDISK, STEP_NETWORK, STEP_IFACE, STEP_IP, STEP_URL, STEP_DONE } step; + char * stg2url = NULL; char * url = NULL; char * ret = NULL; int dir = 1; @@ -1049,21 +1050,35 @@ flags |= LOADER_FLAGS_ASKMETHOD; }
+ /* handle stage2 data first if available */ + if (loaderData->stage2 == METHOD_HD && loaderData->stage2Data) { + char * stg2part; + char * stg2dir; + stg2url = ((struct hdstage2Data *)loaderData->stage2Data)->stg2loc; + stg2part = ((struct hdstage2Data *)loaderData->stage2Data)->partition; + stg2dir = ((struct hdstage2Data *)loaderData->stage2Data)->directory; + logMessage(INFO, "LOADER Stage2 partition is %s, dir is %s", stg2part, stg2dir); + if (stg2url) + logMessage(INFO, "LOADER URL_STAGE2 - stg2url is %s", stg2url); +/* return stg2url; +*/ /* check to see if we have a CD. If we have one, then * we can fast-path the CD and not make people answer questions in * text mode. */ if (!FL_ASKMETHOD(flags) && !FL_KICKSTART(flags)) { - url = findAnacondaCD(location, !FL_RESCUE(flags)); + stg2url = findAnacondaCD(location, !FL_RESCUE(flags)); /* if we found a CD and we're not in rescue or vnc mode return */ /* so we can short circuit straight to stage 2 from CD */ - if (url && (!FL_RESCUE(flags) && !hasGraphicalOverride())) - return url; + if (stg2url && (!FL_RESCUE(flags) && !hasGraphicalOverride())) + return stg2url; else { rhcdfnd = 1; methodNum = 0; } }
+ } + if (!FL_CMDLINE(flags)) startNewt();
@@ -1124,9 +1139,9 @@ * * Alternately, if we're in a VNC install based from CD we * can skip this step because we already found the CD */ - if (url) { + if (stg2url) { if (FL_RESCUE(flags)) { - return url; + return stg2url; } else if (rhcdfnd) { step = STEP_NETWORK; dir = 1; @@ -1374,8 +1389,8 @@ /* we get this case when we're doing a VNC install from CD */ /* and we didnt short circuit earlier because we had to */ /* prompt for network info for vnc to work */ - if (url && rhcdfnd) - return url; + if (stg2url && rhcdfnd) + return stg2url;
url = installMethods[validMethods[methodNum]].mountImage( installMethods + validMethods[methodNum], @@ -1736,7 +1751,7 @@ if (FL_TELNETD(flags)) startTelnetd(&loaderData);
- url = doLoaderMain("/mnt/source", &loaderData, modInfo); + url = doLoaderMain("/mnt/stage2", &loaderData, modInfo);
if (!FL_TESTING(flags)) { int ret;
diff -u anaconda-11.4.0.82.orig/loader2/loader.h anaconda-11.4.0.82/loader2/loader.h --- anaconda-11.4.0.82.orig/loader2/loader.h 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/loader.h 2008-05-13 18:20:26.000000000 -0500 @@ -129,10 +129,12 @@ int ipv6info_set; char * ksFile; int method; + int stage2; char * ddsrc; void * methodData; char * logLevel; char * updatessrc; + void * stage2Data; char * dogtailurl;
pid_t fw_loader_pid;
diff -u anaconda-11.4.0.82.orig/loader2/method.c anaconda-11.4.0.82/loader2/method.c --- anaconda-11.4.0.82.orig/loader2/method.c 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/method.c 2008-05-11 17:51:32.000000000 -0500 @@ -625,6 +624,34 @@ return rc; }
+void setStg2FromCmdline(char * arg, struct loaderData_s * ld) { + char * c, * dup; + + dup = strdup(arg); + c = dup; + /* : will let us delimit real information on the method */ + if ((c = strtok(c, ":"))) { + c = strtok(NULL, ":"); + +#if !defined(__s390__) && !defined(__s390x__) + if (!strncmp(arg, "cdrom:", 6)) { + ld->stage2 = METHOD_CDROM; +#endif + } else if (!strncmp(arg, "harddrive:", 10) || + !strncmp(arg, "hd:", 3)) { + ld->stage2 = METHOD_HD; + ld->stage2Data = calloc(sizeof(struct hdstage2Data *), 1); + ((struct hdstage2Data *)ld->stage2Data)->stg2loc = strdup(arg); + ((struct hdstage2Data *)ld->stage2Data)->partition = strdup(c); + if ((c = strtok(NULL, ":"))) { + ((struct hdstage2Data *)ld->stage2Data)->directory = strdup(c); + } + } + } + free(dup); +} + +
diff -u anaconda-11.4.0.82.orig/loader2/method.h anaconda-11.4.0.82/loader2/method.h --- anaconda-11.4.0.82.orig/loader2/method.h 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/method.h 2008-05-13 19:03:58.000000000 -0500 @@ -40,6 +40,14 @@ char * location, struct loaderData_s * loaderData); };
+struct hdstage2Data { + char * partition; + char * directory; + char * stg2loc; +}; + + + int umountLoopback(char * mntpoint, char * device); int mountLoopback(char * fsystem, char * mntpoint, char * device);
@@ -58,5 +66,6 @@ void copyProductImg(char * path);
void setMethodFromCmdline(char * arg, struct loaderData_s * ld); +void setStg2FromCmdline(char * arg, struct loaderData_s * ld);
#endif
diff -u anaconda-11.4.0.82.orig/loader2/urlinstall.c anaconda-11.4.0.82/loader2/urlinstall.c --- anaconda-11.4.0.82.orig/loader2/urlinstall.c 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/urlinstall.c 2008-05-11 20:29:00.000000000 -0500 @@ -31,7 +31,6 @@ #include <unistd.h>
#include "../isys/iface.h" - #include "copy.h" #include "kickstart.h" #include "loader.h" @@ -45,6 +44,7 @@ #include "cdinstall.h" #include "urls.h" #include "windows.h" +#include "hdinstall.h"
/* boot flags */ extern uint64_t flags; @@ -107,16 +107,19 @@
/* We assume that if stage2= was given, it's pointing at a stage2 image * file. Trim the filename off the end, and that's the directory where - * updates.img and friends must live. + * updates.img and friends must live.JV BUT hacks off /os in url path */ if (FL_STAGE2(flags)) { /* Has to have a / in it somewhere, since it has to be a path name. */ if (!strrchr(ui->prefix, '/')) return 1; + else path = strndup(ui->prefix, strrchr(ui->prefix, '/') - ui->prefix);
- if (!path) + if (path) + logMessage(INFO, "stage2 path is %s", path); + else return 1; } else @@ -161,27 +164,30 @@ } else { stage2img = "stage2.img"; } - rc = asprintf(&buf, "%s/%s", path, stage2img); rc = asprintf(&tmp, "/tmp/%s", stage2img); rc = loadSingleUrlImage(ui, buf, tmp, "/mnt/runtime", "/dev/loop0", 0); free(buf); - } - else { + } else { /* We already covered the case of ui->prefix not having a / in it * at the beginning, so don't worry about it here. */ - rc = asprintf(&tmp, "/tmp/%s", strrchr(ui->prefix, '/')); - rc = loadSingleUrlImage(ui, ui->prefix, tmp, "/mnt/runtime", - "/dev/loop0", 0); - } +/* rc = asprintf(&tmp, "/tmp/%s", strrchr(ui->prefix, '/')); + * rc = loadSingleUrlImage(ui, ui->prefix, tmp, "/mnt/runtime", + * "/dev/loop0", 0); +*/ + stage2img = "stage2.img"; + rc = asprintf(&buf, "%s/%s", path, stage2img); + rc = mountStage2(buf, path); + free(buf); + }
free(tmp); free(path);
if (rc) { - if (rc != 2) + if (rc != 0) newtWinMessage(_("Error"), _("OK"), _("Unable to retrieve the install image.")); return 1; @@ -209,6 +215,7 @@ struct iurlinfo ui; char needsSecondary = ' '; char * cdurl = NULL; + char * stg2url = NULL;
enum { URL_STAGE_MAIN, URL_STAGE_SECOND, URL_STAGE_FETCH, URL_STAGE_DONE } stage = URL_STAGE_MAIN; @@ -218,6 +225,24 @@ while (stage != URL_STAGE_DONE) { switch(stage) { case URL_STAGE_MAIN: + + /* handle stage2 data first if available */ + if (loaderData->stage2 == METHOD_HD && loaderData->stage2Data) { + char * stg2part; + char * stg2dir; + stg2part = ((struct hdstage2Data*)loaderData->stage2Data)->partition; + stg2dir = ((struct hdstage2Data *)loaderData->stage2Data)->directory; + logMessage(INFO, "URL Stage2 partition is %s, dir is %s", stg2part, stg2dir); + + /*if exist, duplicate */ + if (stg2part) + stg2part = strdup(stg2part); + if (stg2dir) + stg2dir = strdup(stg2dir); + logMessage(INFO, "URL setupIso for Stage2"); + setupIsoImages(stg2part, stg2dir, location); + } + if (loaderData->method == METHOD_URL && loaderData->methodData) { url = ((struct urlInstallData *)loaderData->methodData)->url; logMessage(INFO, "URL_STAGE_MAIN - url is %s", url); @@ -266,10 +292,10 @@ * one over the network. However, passing stage2= overrides * this check. */ - if (!FL_STAGE2(flags)) + if (!FL_STAGE2(flags)){ cdurl = findAnacondaCD(location, 0);
- if (cdurl) { + if (cdurl) { logMessage(INFO, "Detected stage 2 image on CD"); winStatus(50, 3, _("Media Detected"), _("Local installation media detected..."), 0); @@ -277,21 +303,22 @@ newtPopWindow();
stage = URL_STAGE_DONE; - } else { + } else { /* need to find stage 2 on remote site */ if (loadUrlImages(&ui)) { stage = URL_STAGE_MAIN; if (loaderData->method >= 0) { loaderData->method = -1; } - - flags &= ~LOADER_FLAGS_STAGE2; - } else { - stage = URL_STAGE_DONE; - } - } + } + } + } else { + /* JV */ + stg2url = ((struct hdstage2Data*)loaderData->stage2Data)->stg2loc; + logMessage(INFO, "URL URL_STAGE2 - stg2url is %s", stg2url); + stage = URL_STAGE_DONE; + } break; - case URL_STAGE_DONE: break; }
OK, should I be thinking that stage2= will be the replacement for method= for stage1? I'm getting that feeling, just want to be sure.
Yes, though not really a complete replacement. The final goal is that stage2= points to just the stage2.img file, while method= points to just the package repository. Perhaps at that point we rename it to repo= to avoid confusion? Don't know quite what to do here yet.
/wish list Maybe stage2.img and related boot.iso could just be moved to the updates repo all together. The boot.iso could then be updated, containing the latest changes that lead to the need for a updates.img in the first place, as required. Now you really have disconnected the location of stage2 from the primary repo. wish list/
Back to what is required now in loader, The boot.iso is mounted for stage2, if present, else look for an iso-image to use for stage2 for nfsiso, hd(iso), or tree-path for nfs. That just leaves net installs, where what you're really being asked is for the location of stage2 and not the location of a repo in stage1. Anaconda should then discard the net install's method-path, but not method, that is passed from loader when building its own repo list with data supplied from a kickstart file and/or the repo editor.
Does that sum up what maybe required here? Think all the *install.c files could become just one install.c file here. Is that what I should work towards?
I was thinking of something like setmethodfromcmdline but for stage2. attached is a rough patch as proof of concept. Mounts stage2 at the given path, then returns the url for the method string.
03:37:07 INFO : mounted loopback device /mnt/runtime on /dev/loop0 as /mnt/isodir//images/stage2.img 03:37:07 INFO : URL_STAGE_MAIN - url is http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os 03:37:07 DEBUG : url address download.fedora.redhat.com 03:37:07 DEBUG : url prefix /pub/fedora/linux/development/i386/os 03:37:07 INFO : URL URL_STAGE2 - stg2url hd:sdb1:/images/stage2.img 03:37:07 INFO : got url http://download.fedora.redhat.com/pub/fedora/linux/development/i386/os 03:37:08 INFO : Loading SELinux policy
I have the whole log saved if your interested. To do: port cdinstall to return stg2url for stage2.
I think is would help with preupgrade and rescue modes, being able to point stage2 to any available hard drive partition.
Just an idea,
Jerry
diff -u anaconda-11.4.0.82.orig/loader2/hdinstall.c anaconda-11.4.0.82/loader2/hdinstall.c --- anaconda-11.4.0.82.orig/loader2/hdinstall.c 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/hdinstall.c 2008-05-11 20:19:57.000000000 -0500 @@ -154,9 +154,9 @@ }
/* given a partition device and directory, tries to mount hd install image */ -static char * setupIsoImages(char * device, char * dirName, char * location) { +char * setupIsoImages(char * device, char * dirName, char * location) { int rc; - char *url = NULL, *dirspec, *updpath; + char *dirspec, *updpath, *url = NULL; char *path; char *typetry[] = {"ext3", "ext2", "vfat", NULL}; char **type; @@ -186,39 +187,29 @@ }
if (path) { - logMessage(INFO, "Path to valid iso is %s", path); + logMessage(INFO, "Path to stage2 is %s", path);
rc = asprintf(&updpath, "%s/updates.img", dirspec); logMessage(INFO, "Looking for updates for HD in %s", updpath); copyUpdatesImg(updpath);
free(updpath); - free(dirspec);
if (FL_STAGE2(flags)) { - if (!copyFile(path, "/tmp/stage2.img")) { - rc = mountStage2("/tmp/stage2.img", dirName); - umount("/mnt/isodir"); - free(path); - - if (rc) { - umountLoopback("/mnt/runtime", "/dev/loop0"); - flags &= ~LOADER_FLAGS_STAGE2; - goto err; - } else { - rc = asprintf(&url, "hd:%s:%s:/%s", - device, - *type, dirName ? dirName : "."); - return url; - } - } - else { - free(path); + /* rc = asprintf(&stg2url, "hd:%s:%s:/%s", + * device, + * *type, dirName ? dirName : "."); + */ + rc = mountStage2(path, dirspec); + free(path); + free(dirspec); + return NULL; + } else { umount("/mnt/isodir"); flags &= ~LOADER_FLAGS_STAGE2; - goto err; + /* goto err; + * free(path);*/ } - }
rc = mountLoopback(path, "/mnt/source", "/dev/loop1"); if (!rc) { @@ -284,6 +275,13 @@ char *selpart; char *kspartition, *ksdirectory;
+ /* handle stage2 data first if available */ + if (loaderData->stage2 == METHOD_HD && loaderData->stage2Data) { + kspartition = ((struct hdstage2Data *)loaderData->stage2Data)->partition; + ksdirectory = ((struct hdstage2Data *)loaderData->stage2Data)->directory; + logMessage(INFO, "HD Stage2 partition is %s, dir is %s", kspartition, ksdirectory); + } + /* handle kickstart data first if available */ if (loaderData->method == METHOD_HD && loaderData->methodData) { kspartition = ((struct hdInstallData *)loaderData->methodData)->partition;
diff -u anaconda-11.4.0.82.orig/loader2/hdinstall.h anaconda-11.4.0.82/loader2/hdinstall.h --- anaconda-11.4.0.82.orig/loader2/hdinstall.h 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/hdinstall.h 2008-05-11 19:21:25.000000000 -0500 @@ -27,7 +27,7 @@ char * directory; };
- +char * setupIsoImages(char * device, char * dirName, char * location); void setKickstartHD(struct loaderData_s * loaderData, int argc, char ** argv); char * mountHardDrive(struct installMethod * method,
--- anaconda-11.4.0.82.orig/loader2/loader.c 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/loader.c 2008-05-14 19:10:40.000000000 -0500 @@ -872,7 +872,7 @@ setMethodFromCmdline(argv[i] + 7, loaderData); else if (!strncasecmp(argv[i], "stage2=", 7)) { flags |= LOADER_FLAGS_STAGE2; - setMethodFromCmdline(argv[i] + 7, loaderData); + setStg2FromCmdline(argv[i] + 7, loaderData); } else if (!strncasecmp(argv[i], "hostname=", 9)) loaderData->hostname = strdup(argv[i] + 9); @@ -1016,6 +1016,7 @@ enum { STEP_LANG, STEP_KBD, STEP_METHOD, STEP_DRIVER, STEP_DRIVERDISK, STEP_NETWORK, STEP_IFACE, STEP_IP, STEP_URL, STEP_DONE } step; + char * stg2url = NULL; char * url = NULL; char * ret = NULL; int dir = 1; @@ -1049,21 +1050,35 @@ flags |= LOADER_FLAGS_ASKMETHOD; }
+ /* handle stage2 data first if available */ + if (loaderData->stage2 == METHOD_HD && loaderData->stage2Data) { + char * stg2part; + char * stg2dir; + stg2url = ((struct hdstage2Data *)loaderData->stage2Data)->stg2loc; + stg2part = ((struct hdstage2Data *)loaderData->stage2Data)->partition; + stg2dir = ((struct hdstage2Data *)loaderData->stage2Data)->directory; + logMessage(INFO, "LOADER Stage2 partition is %s, dir is %s", stg2part, stg2dir); + if (stg2url) + logMessage(INFO, "LOADER URL_STAGE2 - stg2url is %s", stg2url); +/* return stg2url; +*/ /* check to see if we have a CD. If we have one, then * we can fast-path the CD and not make people answer questions in * text mode. */ if (!FL_ASKMETHOD(flags) && !FL_KICKSTART(flags)) { - url = findAnacondaCD(location, !FL_RESCUE(flags)); + stg2url = findAnacondaCD(location, !FL_RESCUE(flags)); /* if we found a CD and we're not in rescue or vnc mode return */ /* so we can short circuit straight to stage 2 from CD */ - if (url && (!FL_RESCUE(flags) && !hasGraphicalOverride())) - return url; + if (stg2url && (!FL_RESCUE(flags) && !hasGraphicalOverride())) + return stg2url; else { rhcdfnd = 1; methodNum = 0; } }
+ } + if (!FL_CMDLINE(flags)) startNewt();
@@ -1124,9 +1139,9 @@ * * Alternately, if we're in a VNC install based from CD we * can skip this step because we already found the CD */ - if (url) { + if (stg2url) { if (FL_RESCUE(flags)) { - return url; + return stg2url; } else if (rhcdfnd) { step = STEP_NETWORK; dir = 1; @@ -1374,8 +1389,8 @@ /* we get this case when we're doing a VNC install from CD */ /* and we didnt short circuit earlier because we had to */ /* prompt for network info for vnc to work */ - if (url && rhcdfnd) - return url; + if (stg2url && rhcdfnd) + return stg2url;
url = installMethods[validMethods[methodNum]].mountImage( installMethods + validMethods[methodNum], @@ -1736,7 +1751,7 @@ if (FL_TELNETD(flags)) startTelnetd(&loaderData);
- url = doLoaderMain("/mnt/source", &loaderData, modInfo); + url = doLoaderMain("/mnt/stage2", &loaderData, modInfo);
if (!FL_TESTING(flags)) { int ret;
diff -u anaconda-11.4.0.82.orig/loader2/loader.h anaconda-11.4.0.82/loader2/loader.h --- anaconda-11.4.0.82.orig/loader2/loader.h 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/loader.h 2008-05-13 18:20:26.000000000 -0500 @@ -129,10 +129,12 @@ int ipv6info_set; char * ksFile; int method; + int stage2; char * ddsrc; void * methodData; char * logLevel; char * updatessrc; + void * stage2Data; char * dogtailurl;
pid_t fw_loader_pid;
diff -u anaconda-11.4.0.82.orig/loader2/method.c anaconda-11.4.0.82/loader2/method.c --- anaconda-11.4.0.82.orig/loader2/method.c 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/method.c 2008-05-11 17:51:32.000000000 -0500 @@ -625,6 +624,34 @@ return rc; }
+void setStg2FromCmdline(char * arg, struct loaderData_s * ld) { + char * c, * dup; + + dup = strdup(arg); + c = dup; + /* : will let us delimit real information on the method */ + if ((c = strtok(c, ":"))) { + c = strtok(NULL, ":"); + +#if !defined(__s390__) && !defined(__s390x__) + if (!strncmp(arg, "cdrom:", 6)) { + ld->stage2 = METHOD_CDROM; +#endif + } else if (!strncmp(arg, "harddrive:", 10) || + !strncmp(arg, "hd:", 3)) { + ld->stage2 = METHOD_HD; + ld->stage2Data = calloc(sizeof(struct hdstage2Data *), 1); + ((struct hdstage2Data *)ld->stage2Data)->stg2loc = strdup(arg); + ((struct hdstage2Data *)ld->stage2Data)->partition = strdup(c); + if ((c = strtok(NULL, ":"))) { + ((struct hdstage2Data *)ld->stage2Data)->directory = strdup(c); + } + } + } + free(dup); +} + +
diff -u anaconda-11.4.0.82.orig/loader2/method.h anaconda-11.4.0.82/loader2/method.h --- anaconda-11.4.0.82.orig/loader2/method.h 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/method.h 2008-05-13 19:03:58.000000000 -0500 @@ -40,6 +40,14 @@ char * location, struct loaderData_s * loaderData); };
+struct hdstage2Data { + char * partition; + char * directory; + char * stg2loc; +}; + + + int umountLoopback(char * mntpoint, char * device); int mountLoopback(char * fsystem, char * mntpoint, char * device);
@@ -58,5 +66,6 @@ void copyProductImg(char * path);
void setMethodFromCmdline(char * arg, struct loaderData_s * ld); +void setStg2FromCmdline(char * arg, struct loaderData_s * ld);
#endif
diff -u anaconda-11.4.0.82.orig/loader2/urlinstall.c anaconda-11.4.0.82/loader2/urlinstall.c --- anaconda-11.4.0.82.orig/loader2/urlinstall.c 2008-05-06 16:06:57.000000000 -0500 +++ anaconda-11.4.0.82/loader2/urlinstall.c 2008-05-11 20:29:00.000000000 -0500 @@ -31,7 +31,6 @@ #include <unistd.h>
#include "../isys/iface.h" - #include "copy.h" #include "kickstart.h" #include "loader.h" @@ -45,6 +44,7 @@ #include "cdinstall.h" #include "urls.h" #include "windows.h" +#include "hdinstall.h"
/* boot flags */ extern uint64_t flags; @@ -107,16 +107,19 @@
/* We assume that if stage2= was given, it's pointing at a stage2 image * file. Trim the filename off the end, and that's the directory where - * updates.img and friends must live. + * updates.img and friends must live.JV BUT hacks off /os in url path */ if (FL_STAGE2(flags)) { /* Has to have a / in it somewhere, since it has to be a path name. */ if (!strrchr(ui->prefix, '/')) return 1; + else path = strndup(ui->prefix, strrchr(ui->prefix, '/') - ui->prefix);
- if (!path) + if (path) + logMessage(INFO, "stage2 path is %s", path); + else return 1; } else @@ -161,27 +164,30 @@ } else { stage2img = "stage2.img"; } - rc = asprintf(&buf, "%s/%s", path, stage2img); rc = asprintf(&tmp, "/tmp/%s", stage2img); rc = loadSingleUrlImage(ui, buf, tmp, "/mnt/runtime", "/dev/loop0", 0); free(buf); - } - else { + } else { /* We already covered the case of ui->prefix not having a / in it * at the beginning, so don't worry about it here. */ - rc = asprintf(&tmp, "/tmp/%s", strrchr(ui->prefix, '/')); - rc = loadSingleUrlImage(ui, ui->prefix, tmp, "/mnt/runtime", - "/dev/loop0", 0); - } +/* rc = asprintf(&tmp, "/tmp/%s", strrchr(ui->prefix, '/')); + * rc = loadSingleUrlImage(ui, ui->prefix, tmp, "/mnt/runtime", + * "/dev/loop0", 0); +*/ + stage2img = "stage2.img"; + rc = asprintf(&buf, "%s/%s", path, stage2img); + rc = mountStage2(buf, path); + free(buf); + }
free(tmp); free(path);
if (rc) { - if (rc != 2) + if (rc != 0) newtWinMessage(_("Error"), _("OK"), _("Unable to retrieve the install image.")); return 1; @@ -209,6 +215,7 @@ struct iurlinfo ui; char needsSecondary = ' '; char * cdurl = NULL; + char * stg2url = NULL;
enum { URL_STAGE_MAIN, URL_STAGE_SECOND, URL_STAGE_FETCH, URL_STAGE_DONE } stage = URL_STAGE_MAIN; @@ -218,6 +225,24 @@ while (stage != URL_STAGE_DONE) { switch(stage) { case URL_STAGE_MAIN: + + /* handle stage2 data first if available */ + if (loaderData->stage2 == METHOD_HD && loaderData->stage2Data) { + char * stg2part; + char * stg2dir; + stg2part = ((struct hdstage2Data*)loaderData->stage2Data)->partition; + stg2dir = ((struct hdstage2Data *)loaderData->stage2Data)->directory; + logMessage(INFO, "URL Stage2 partition is %s, dir is %s", stg2part, stg2dir); + + /*if exist, duplicate */ + if (stg2part) + stg2part = strdup(stg2part); + if (stg2dir) + stg2dir = strdup(stg2dir); + logMessage(INFO, "URL setupIso for Stage2"); + setupIsoImages(stg2part, stg2dir, location); + } + if (loaderData->method == METHOD_URL && loaderData->methodData) { url = ((struct urlInstallData *)loaderData->methodData)->url; logMessage(INFO, "URL_STAGE_MAIN - url is %s", url); @@ -266,10 +292,10 @@ * one over the network. However, passing stage2= overrides * this check. */ - if (!FL_STAGE2(flags)) + if (!FL_STAGE2(flags)){ cdurl = findAnacondaCD(location, 0);
- if (cdurl) { + if (cdurl) { logMessage(INFO, "Detected stage 2 image on CD"); winStatus(50, 3, _("Media Detected"), _("Local installation media detected..."), 0); @@ -277,21 +303,22 @@ newtPopWindow();
stage = URL_STAGE_DONE; - } else { + } else { /* need to find stage 2 on remote site */ if (loadUrlImages(&ui)) { stage = URL_STAGE_MAIN; if (loaderData->method >= 0) { loaderData->method = -1; } - - flags &= ~LOADER_FLAGS_STAGE2; - } else { - stage = URL_STAGE_DONE; - } - } + } + } + } else { + /* JV */ + stg2url = ((struct hdstage2Data*)loaderData->stage2Data)->stg2loc; + logMessage(INFO, "URL URL_STAGE2 - stg2url is %s", stg2url); + stage = URL_STAGE_DONE; + } break; - case URL_STAGE_DONE: break; }
anaconda-devel@lists.stg.fedoraproject.org