Bug#217503: Evil autopartkit should _NEVER_ _NEVER_ try to overwrite an unknown partition table
Package: autopartkit
Version: 0.62
Severity: critical
Justification: causes serious data loss
Ok, i am trying to make debian-installer work on the pegasos, and to my
surprise, yesterday, autopartkit without really giving me the choice
(but then, i might have missed something with the garbled console i
got), just proceeded to overwrite my partition table and something
started to format a partition. So no more powerpc kernel work, no more
parted patches, no more changes to debian-installer. No more anything i
had on that disk, which was not even the disk i was doing the
installation tests on.
This should never never never happen like that, and the whole partition
and disk touching thingy is utterly broken as is.
It is also not only pegasos related, but will break on m68k/amiga as
well as ppc/amiga, as well as all the not yet supported by libparted
partition schemes.
I see two solutions to this :
1) an NMU of libparted including my amiga patches, which are sitting
in the BTS since almost a month now. This is only a partial solution
though, as we would need to add at least probing code for _every_
partition scheme around (not all that difficult to do). An upload of a
new libparted may mean a recompilation of all the libparted using
binaries, not sure though, it should not happen, as i don't modify the
external representation, but ...
2) Some more rationale chosing of partitioning scheme based on
arch/subarch detection. I notice that partitioner was first tried and
failed, and then it got on to propose to mount partitions and such,
and then it went on to autopartkit. This is broken. One thing that can
be checked is, that despite libparted not recognizing the partition
table type, the kernel _DOES_ know about it, so it should detect it
and warn the user about this in big flashing letters. And something
more flashy than the usual "Are you sure you want to erase this disk"
thingy, since we _know_ that autopartkit is going to write over the
existing partition table.
As i see it, the ideal way of handling this would be a coordinated
effort of the different partitioning/formating tools available, which
somehow shows the limits of the modular system.
Ideally, we should have :
We have a disk. It is either partitioned or not, we parse the
/proc/partitions to see what the kernel thinks about it. We would need
to load the partition table modules for this though.
We do a libparted probe on the disk, to see if the partition table is
recognized. If it is, then we can propose the user to choose either
partitioner, autopartkit or parted. Ideally we should have some
heuristic (arch/subarch related) for proposing also other tools. This
should be one menu entry only, which would have something like
submenus. I don't know if this is possible with the modular
debian-installer, but until this is done, i don't consider
debian-installer as releaseable, so if it not possible, we better work
on it. If the kernel discovered a partition table on the disk, we also
automatically propose to not change anything, and go on with it.
If the kernel detects a partition table on the disk, but neither
libparted nor the standalone partitioning tool is able to detect it,
then we have a huge flashing warning about the fact. And something
which should _not_ be comparable to the normal "are you sure" question
currently used.
Once one of the tools is choosen (or not) and the disk is partitioned,
we go on with the filesystem creation stuff as usual.
Like said, this is a critical bug report. In the current status
debian-installer is totally unreleasable, and this should be fixed.
Friendly,
Sven Luther
-- System Information: (NOTE, the above is irrelevant information, since
this is naturally not the box where i lost my disk on).
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux iliana 2.4.22 #1 SMP dim oct 12 10:52:56 CEST 2003 i686
Locale: LANG=fr_FR.ISO-8859-1, LC_CTYPE=fr_FR.ISO-8859-1
Reply to: