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

Bug#353573: partman: [hppa] 'PALO' partition on /dev/sda changed to 'linux' during install to /dev/sdc

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

Reply to: