Re: d-i steps order : why directly go into cfdisk?
On Sat, Nov 01, 2003 at 11:17:45AM +0100, Gaudenz Steinlin wrote:
> Am Sam, den 01.11.2003 schrieb Sven Luther um 10:45:
> > On Sat, Nov 01, 2003 at 09:50:54AM +0100, Christian Perrier wrote:
> > > Currently, the steps order looks like :
> > >
> > > Language selection
> > > Network hardware detection
> > > Modules loading
> > > ...
> > >
> > > then partition hard disk (the good old cfdisk)
> > >
> > > Going to main-menu first would be better, imho : this would allow
> > > users to go to autopartkit if they wish to do so.
> > The real solution would be to have a single harddisk partitioning menu
> > entry, which would have many submenus : autopartitioning, partitioner,
> > parted, cfdisk, ....
> Partitioner calls parted or cfdisk. It just searches for hard-disks and
> starts the appropiate partitioning programm for the particular
> arch/subarch. If it does not start the correct program for you, you
> should add or modify the script which starts the partitioning program in
Ah, ok, so partishioner is not a nice text-graphical frontend to
libparted as i thought it was. I have never seen it actually, since it
has never worked on pegasos.
> > The next step would be partconf, which will also write the fstab, as
> > discussed elsewhere.
> not for autopartkit which also does format and mount partitions.
So, the choice then is :
auto partitioning -> autopartkit
manual partitioning -> partitioner + partconf.
I don't know if partitioner will provide choice of multiple partitioning
programs (cfdisk or parted, amiga-fdisk or parted, etc ...) or not.
But again, i agree with the idea of not running autopartkit
automatically like it seems to be done right now, but have it fill in
automatically defined partition data to a common partitioning tool,
which will allow a manual feedback, and eventually small modifications
of the automated selection if wanted. But then maybe it does already do
that, my only interaction with it was when it ate my partition table.
> > Everything else is a less than satisfactory solution, but then nobody
> > seems to care, i am busy with powerpc kernels right now, and nobody has
> > confirmed that this is even possible (or not) with the current modular
> > main menu approach.
> So probably everyone is busy fixing bugs in the installer and nobody
> cares to introduce new ones :-)
But having a setup which is prone to erasing pre-installed disks is
something which is worth looking at, and there is a critical bugreport
> OK, I will try to answer this to my best knowledge:
> It's not easily possible with the current design. You can not have
> submenus in main-menu and because main-menu is just another debconf
> question with priority medium it's only shown if the debconf priority is
> medium or lower. Normal installations start at high and therefore do not
> show main-menu unless there was an error.
> So the short answer is: This is somehow a problem of the modularity of
> debian-installer and it is not easy to fix it in a sane manner without
> changing the design of the installer.
So, work for post-sarge debian-installer maybe. Still the current state
of things is broken, and will cause much grief to our users once sarge