Re: partman-auto: preseeding a multiboot install
Hi Christian,
On 08/27/2013 12:11 AM, Christian PERRIER wrote:
> Quoting John Morris (john@zultron.com):
>
>> 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:
>
>
> You know, a discussion I was having with Joey Hess at DebConf 13 had
> one of its conclusion as this: it is very sad that partman has indeed
> no more "real" maintainer.
Ah ha! An orphaned package would explain why the original question
about 'reusing' partitions or LVs has been asked many times in the past,
but never been answered.
> The framework is indeed fairly well robust
> as it is in this state for several years and, still, things are mostly
> working (except when I break everything by committing an unchecked
> patch)....and even allowed some people to plumb in their own pet
> filesystem.
As already described, partman-auto and partman-auto-lvm leave something
to be desired.
On the other hand, partman's underlying infrastructure looks quite
solid. As you say, someone with enough dedication can make interesting
customizations without requiring major, widespread changes.
In fact, it would be fairly easy to generalize the 'multiboot' work and
undo those assumptions in partman-auto-lvm, even while preserving the
current behavior as default. Nearly all changes would be localized
within the partman-auto-lvm package, possibly with a minor change to
partman-lvm.
> But, still, the overall code is mostly unchanged and we have tons of
> interesting suggestions piling up in the BTS.....but remaining as they
> are: interesting suggestions...:-)
Yes, I understand very well how that happens.
> We would definitely welcome someone ready to invest some time
> (preferrably in the long term) to enhance the parts that could be
> enchanced. Really. But, at the moment, there is nobody who stepped in
> for this....
On the technical side, I'm well-qualified to work on partman.
Unfortunately there are other aspects that would make it hard for me to
jump in. For one, I'm already a Fedora developer with way too many
packages, ha! Also, I'm not a Debian developer. Fedora's process to
become a developer requires a LOT of busy work, most of which I managed
to circumvent by demonstrating experience. Debian's process is probably
similar. I've written and currently support .debs (for the LinuxCNC
community), including a few very challenging ones, but I've only been
involved with Debian over the last year, and couldn't demonstrate enough
contributions to the community to qualify for shortcuts. :) Also, I
see a *lot* of bugs against e.g. partman-lvm in the BTS. Agreeing to
fix all those would be quite a commitment on top of the developer
hurdle-jumping process.
> There is some learning curve as you mentioned but, after all, it is
> not that huge and all this requires some good understanding of
> shell-script programming (and everything related to partitions and filesystems of course).
It took about 4-5 days of solid work, including rebooting about 200
times! But you're right, really not too bad, and most of it was spent
reverse-engineering partman and understanding debconf and d-i.
Some things that could have made the work easier:
- sshd: Editing scripts remotely, such as over sshfs or emacs' tramp,
would have made life easier. Also, connecting to the installer through
an emacs inferior shell or one's favorite editor, one would have more
powerful command-line editing facilities than ash provides. Maybe sshd
is available in d-i somewhere, but from the moment I started, I kept
thinking the job wouldn't take much longer, so I never looked. :)
- debconf/frontend doesn't steal stdio: In 'confmodule', there's a
comment saying a socket for debconf communication would be ideal. True!
The ability to '. /usr/share/debconf/confmodule' and then run db_*()
from the shell would be handy.
- documentation! Of course the source is the ultimate documentation,
but a basic 'principles of operations' ('POOPS', in IBM slang) document
would have been very valuable.
John
Reply to: