Re: d-i steps order : why directly go into cfdisk?
On Sat, Nov 01, 2003 at 12:52:27PM +0100, Gaudenz Steinlin wrote:
> Am Sam, den 01.11.2003 schrieb Sven Luther um 12:12:
> > 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 :
> > > 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
> > > partconf.
> > 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.
> It should start parted, but partitioner 0.11 needs to be uploaded for it
> to work (wrong path to archdetect).
Mmm, who is the maintainer of partitioner, and why does a fixed version
not get uploaded ? is there a source apt repository for the udebs we
use, and can we look at them with apt-cache ?
> > > > 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.
> This could be implemented in the partitoner scripts.
> > 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.
> Right now autopartkit is quite simple, just take the defaults or leave
> it. There is some code to make it smarter, but the implementation is not
> >From your description of what happend, I think it was not autopartkit
> but partconf, which had a bug which lead to formating the wrong
> partition at that time, who ate your disk.
Nope, i think it was both. autopartkit ate my partition table, and
partconf began formating my first partition, thus erasing all my boot
> > > > 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
> > against autopartkit.
> It is currently very difficult to track this down, because it is not
> even clear if it's an autopartkit bug. Both autopartkit and partconf
> issue warnings to the user before doing anything, so I don't know how
> this happend to you without you seeing the warning.
because the display was hosed, and i had only a black screen to look at ?
Because partconf and autopartkit only offered the continue button and no
abort or something such ? I don't remember exactly, and i can't really
retry it, since i lost everything that was on the disk, including the
About the warning, every disk touching program issue such warning, user
mostly have come to ignore them. But autopartkit is potentially more
dangerous, and should have a more flashy warning than the usual "this
will erase all data" one.
> > > 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
> > is released.
> I think the most important thing will be that the installation manual
> has to stress the fact that if you want more control over the
> installation and do fancy things you need to lower the debconf priority.
And maybe someway to detect that the harddisk is already partitioned,
and not offering autopartkit by default in this case.