On Tue, Apr 17, 2007 at 11:53:16PM +0200, Frans Pop wrote: > > I've now managed to trace this issue to the clean_method function in > partman-auto/recipes.sh that is called from partman-auto/perform_recipe. > > This function will delete the "method" files for _all_ partitions on _all_ > devices. In general this is probably OK, but not if the method file is > used to identify special boot partitions as is the case for HPPA/PALO and > possibly also for other arches (e.g. efi, prep). > > For a PALO partition, the method file contains "palo" and the script > partman-palo/update.d/palo_sync_flag relies on the presence of this to > retain the palo flag. > > I'm not sure what the correct solution for this would be:
In general, the philosophy behind the architecture of partman is that 1. the plugins do almost everything without any support from partman core and 2. the partman core doesn't have to take into account what the plugins do. Because of that in my opinion the right solution in this particular situation is to make the init.d script of partman-palo store the information about the partition type in some other file than the method file. For example it can touch a PARTITION_DIR/palo flag file. Then a commit.d script with low enough number does the following: if the method of a partition is palo or there is no method but the palo flag file exists, then add the palo tag in parted_server (and maybe also set palo method for this partition if there is no method). If there is a method file and the method is not palo, then remove the palo flag file and unset the palo tag in parted_server (if it is set). After this I think the update.d script can be removed which is good because we need to have as few update.d scripts as possible (this is critical for the speed of partman). > I'm not quite sure why clean_method is run at all. Presumably it is to > undo any earlier (manual) changes. In that case running the scripts in > undo.d as is done for "Undo changes to partitions" could be a better > idea. I think this is not safe enough because we can not be sure the partman plugins want everithing to be undoable or that they all are properly written. Partman-auto has to act in a way that works regardless of how the partman modules achieve their goals. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
