[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: PATCH: Partition auto-detection and HD exploded treeinstallation



> 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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]