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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]