On Thu, 2006-12-07 at 09:12 -0600, David Lehman wrote: > Installation methods utilizing a remote tree enjoy the task of verifying > that the remote tree matches the boot media used. This prevents a user > from trying, for example, to perform an installation using RHEL4 boot > media and a RHEL3 tree. This verification is achieved through the use of > a stamp file that exists in both the initrd image and the stage2 image. > A successful comparison of the stamps is required for a remote tree to > be deemed acceptable. Historically, yes, this was the case. And to a large extent, this was because of a lot of hard-coding about things like what modules correspond to what pci id, kudzu not handling a different kernel version than the running one, and other things along those lines. Over time, these have been resolved and with current things, there is really only one piece left that falls into this category (SELinux policy). > There is an old shortcut in loader that tries to use a stage2.img from > cdrom when setting up an HTTP install (to save time). This leads to a > short-circuit of the above verification process, since we are only > verifying that the stage2 on the cdrom matches the boot media. The > remote HTTP tree is not verified at all. We have committed to fixing > this bug, starting with RHEL4. > > The simplest fix that I have come up with would be to require that all > exploded remote trees contain the .discinfo from the ISO. Since this > only comes into play when the user has booted with a disc1 (not boot.iso > as it doesn't contain stage2.img) we can assume/require that the cdrom > already contains a .discinfo file. > > The thing is, to make it consistent we'd pretty much have to start > requiring the presence of .discinfo in all exploded remote trees, which > we don't currently do. This is bound to incur some amount of > belly-aching. >From the point of view of legacy releases, making a change like this ends up meaning a change in how people have to roll out releases. This seems like something that could cause some heartburn for users of those releases. What might be sensible as the "hack" for RHEL4 would be to check for the .discinfo and if it doesn't exist, give a warning that can be clicked through. Longer term, though, this is actually a direction we *want* to be able to enable. By continuing to decouple the "bits being used for installation" (ie, the installer) from the "bits being installed (ie, the distribution) we actually get a lot of wins -- it becomes easier to a) Do installer development. This is perhaps the single biggest reason I can come up with. As it stands right now, developing installer features requires a significant amount of legwork and infrastructure. If instead, you just have to build your own installer CD and point at a repository (or set of repositories), then this is a good thing! b) Easier ways to play with changes in the distribution. As we move towards a world where derived distributions are more and more common, it's increasingly important to be able to provide a stage2.img that they can use with their specific package set and not have to worry as much about how to generate the installer image c) The .discinfo is really just a description of what CD is being used. Trying to (ab)use it for more than that is a recipe for trouble. So for HEAD, I'm very against making a change like this. Jeremy
