partitioning bug?

[webanmeldung at backenhoernchen.de]

Thanks for your fast reply.

----- "Michael Tautschnig" <mt at debian.org> schrieb:

> Hi!
> 
> > 
> > Hi,
> > 
> > I just do my first steps with fai and had some problems. After a few
> debugging steps - not many since I am new to fai - it seems to me that
> there is a bug in the partitioning by the "setup-storage" program.
> Maybe you can help me to figure out if it is really a bug or just a
> mistake of mine.
> > 
> > At the end of my post I am pasting the debug code of setup-storage.
> > 
> > As you can see, my system has three Harddrives. One of them is
> almost 3 TB and therefore partitioned using gpt. The problem is with
> that (sdc). I set this up with one partition using 100% of the space.
> This does not work for sdc.
> > As you can see almost at the bottom of the debug code, there is an
> error thrown in the middle of the output. It sais that sdc is too
> small. I looked around a little and could not find any clue about
> where the program get that exact number. So I hope you can make more
> out of it.
> > 
> 
> The problem is that setup-storage will first take your 100% and
> convert it to
> bytes; then it adds space needed for partition tables, extended
> partitions, etc.
> This results in that "strange" number.
> 
> > I solved the problem by setting the size in the config file to 99%.
> > 
> > Since I am still working on my configuration I can provide you more
> information, if needed --- at least for a little while.
> > 
> 
> I think things should be exactly the way you want them to be if you
> use "0-"
> instead of "100%". Could you give that a try.

This worked. But you suggestion is different to the % value. The meaning of "0-" is: Create a partition which is at least of the size 0. "100%" on the other hand means: Use 100% of the disk size of the partition.
As I would think of the setup-storage program, it should exit with an error on 100% if it is not possible to create such a partition, because there are already others or what ever. "0-" instead would run through, even there is not 100% of the disk size available.

In my opinion the implementation you use should be considered a bug since it is not what a user expects and additionally seems to brake under certain conditions (like mine).

> 
> I'm not sure whether I'd call this a bug or just a problem of
> interpreting
> values. Maybe we should first sum up overhead costs, subtract that
> from the disk
> size and then evalute relative values such as "100%". Not sure,
> though.
> 
> Hope this helps,
> Michael