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.
Ok.
> > 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
> finished.
Mmm.
> >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
kernels.
> > > > 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
d-i initrd.
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.
> gaudenz
And maybe someway to detect that the harddisk is already partitioned,
and not offering autopartkit by default in this case.
Friendly,
Sven Luther
Reply to: