[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

autopartkit vs. partman-auto


As most of you might know the Debian-Edu people are working a bit on the 
autopartitioning. Therefore we have two ways which we can go.

First one would be to choose autopartkit and bring it back into a shape where 
we can use it for etch. This includes updating the code so that it fits with 
the new libparted API and works nice. (We don't have a maintainer for it, it 
just means trying to make it working) 

Second one would be to go for partman-auto. This way was suggested by most of 
the d-i people I guess (please feel free to correct me if i am wrong).

After the small talk on debian-boot I had a small talk to Petter Reinholdtsen 
and there I want to quote one or two points (with his agreement):

22:00 < pere> white: if partman-auto can be fixed to do the things we need, I 
do not have any reason to keep autopartkit. But that include LVM support, 
creating ext3 fs with resize_inode option and scaling the partition sizes 
with the disk size.

22:13 < pere> adding resize_inode to ext3 file systems seem to require a 
rewrite of partman-ext3, as it now uses libparted to create ext2, and then 
tune2fs -j to convert it to ext3.  there is no safe way to add the 
resize_inode option after the file system is created, so the parman module 
will need to be rewritten to use mke2fs.
22:13 < pere> there is an unsafe way to add the resize_inode option, using 
ext2prepare from the ext2resize package.

Can you please comment on that? Will partman-auto have the required features?
Shall we drop autopartkit from Debian and integrate/implement features into 
partman-auto or shall we have both and keep autopartkit alive and fix it as 
good as we can?

I am sorry to bother you again with that, but I guess a clear answer to this 
mail and a discussion via mail thread is in this case better than several IRC 

Greetings and thanks in advance

Attachment: pgpuVx2CxDa2w.pgp
Description: PGP signature

Reply to: