On 08/20/2013 04:56 PM, John Morris wrote:
> Is it possible to reuse an existing VG from partman-auto-lvm, and I'm
> missing something obvious? If not, could partman scriptlets be used?
It is not possible to reuse an existing VG, or even partition for that
matter. The reason is that all current partman-auto methods call
auto_init_disks(), which wipes LVM and the partition label from the
disk, forcing partitioning to start from scratch.
Another simpler problem is the last LV in a VG is created to fill all
remaining free space instead of honoring the requested size in the
expert_recipe.
This behavior is difficult for me to understand, since one would expect
a preseeded 'expert_recipe' to be able to do anything possible in a
manual install, and also to do exactly what the expert requested.
Building scalable engineering and web infrastructures in the past, I've
often set up systems to reinstall OS partitions but preserve existing
(or leave space for future) data partitions, or leave free space in a VG
for snapshots and other purposes. I was surely surprised to see the
requested 2GB swap partition created as 70GB!!! Hopefully someone will
pipe up and tell me what obvious thing this Debian n00b has missed.
Otherwise,
For the next person:
It is painful to overcome the learning curve of d-i, debconf and
partman, and just about any alternate means of achieving one's goals
should be considered. If hacking partman-auto and partman-auto-lvm is
really the only solution, here's what I did, in broad strokes:
Create a new function based on auto_lvm_prepare():
- Disable the call to auto_init_disks().
- If you want to reinstall LVs specifically requested in the recipe, at
some point after $pvscheme has been determined, call a function
containing parts of device_remove_lvm() that remove LVs, but only
lv_delete() volumes matching entries in $pvscheme. If any LVs are
deleted, the partman server needs a kick.
- The function needs to replace the call to auto_lvm_create_partitions()
with something that doesn't run create_primary_partitions() and
create_partitions(), but that cribs from the former to create the
$pv_devices list needed later in the install. If you want to mount an
existing primary partition like /boot, add handling for a recipe
parameter like '$ondisk{ /dev/sda1 }' that can be matched against the
parted-server PARTITION command output's 'path' column to get an id to
pass to setup_partition().
- Disable the parted-server COMMIT.
Then plumb this all in:
Creating a script like /bin/autopartition-lvm that calls the above
auto_lvm_prepare() replacement. Instead of calling all of
auto_lvm_perform(), it only needs to run the bottom code where LVs are
created, since the PVs and VGs already exist. If ballooning the last LV
up to fill all free space is not desired, it should execute a copy of
/bin/perform_recipe_by_lvm with the check for $last removed.
Finally, copy display.d/10initial_auto to a script that runs earlier.
It should check for a new method (e.g. 'multiboot'); if found, disable
10initial_auto and execute the /bin/autopartition-lvm clone.
Have fun!
John
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/521be5b4.5090...@zultron.com
