> While things change pretty quickly, patches are generally able to be > applied with some ease across versions, so as long as it's relatively > recent (which this is), then I'm less concerned about the specific > version the patch is against. > These patches, though, seem to have a fair bit of whitespace changes > making finding the real changes more difficult. A diff for the > relevant changes is far easier to review. Also, having a separate diff > for each logical change helps as well. Thanks. We'll provide separate patches and keep them clean after we've addressed the questions you raise below. > What happens then if there's more than one device that has a ks.cfg or > an install source? Is the problem you're trying to solve the fact that > device naming isn't all that reproducible from one machine to another? > If so, is there anything about the device that you're having people > install from that could be used instead as the device key (much like > the biosdisk/part stuff). The patch we initially provided selected the first partition encountered with the kickstart/install source. A solution that gives the user more control, however, is to identify all partitions with the specified kickstart/install source and: * if the number of devices is 0, do nothing, or * if the number of devices is 1, use that one, or * else pop up the dialog box and ask the user. Something similar to this is done in the loadUpdates() function in the loader section, where the user is asked for input if the number of potential update disks is greater than 1. This solution is general and doesn't rely on device specific information. Our initial thinking (and that of others on the mailing list as well) had been to idenfity the device by determining the device used to boot the system, but we don't have a way to find this. > This is something that used to be supported, but invariably, people > would delete files they didn't think they needed. This then led to > tracebacks which weren't clear or otherwise failing installations. > Since people are going to be downloading the ISOs anyway, just using > the ISOs for the hard drive install is far better. It also has the > plus of the ISOs can be trivially verified. RHupdates could be > supported pretty trivially with hard drive installs if it was desired, > but it seems a lot less important with the ease of creating an > updates.img now that they can be a cpio.gz. In our scenario, the OS is preinstalled on client systems and a complete install image is provided on a secondary storage device. The secondary device is used for client data backup as well as for OS recovery in the event of primary hard drive corruption or failure. The install image on these secondary devices is kept up to date via synchronization. Since the systems can be located across slow network connections, we minimize data download by syncing at the file rather than iso/updates.img level. We could sync individual files and have client side code create an updates.img for anaconda to read. But for us it is cleaner over the long run to modify anaconda to deal with reading exploded trees. Since others on this mailing list have requested this functionality, we hoped to provide a general solution. As for exploded tree verification, one general approach could be to provide a file with a list of file-md5 pairs that sits alongside the .discinfo file (perhaps named .filemd). This file would have a function similar to the repomd.xml file in the repodata folder, but presumably would be in plaintext format rather than xml (since it would be read by loader). This file could be used when the mediacheck flag is present to check md5 values for files in the distribution. We can imagine several issues with this approach, but will do some experimenting to see what we can come up with. > How is this different than the existing protected partition support? > Why not just continue to use it instead of implementing new methods? The bootloaderSetupChoices function in bootloader.py, the __call__ method in PartitionTypeWindow (for text-based install) and the createAllowedDrives function in partition_ui_helpers_gui.py (for graphical install) do not filter out the kickstart and the source devices. We can simplify our implementation to avoid new methods. Note that something similar to what we are trying to do is done with the updates device (the device containing the updates img - anaconda.updateSrc) to uncheck it by default in the partitions list displayed. Thanks much, Uday.
