The version 6.0 installer invites users to specify the sizes of disk
partitions and volumes in units of "K", "M", "G", and "T". Only later do
they find out that what is meant by this is the politically-correct
decimal units 10^3, 10^6, 10^9, and 10^12, rather than the conventional
binary units of 2^10, 2^20, 2^30, and 2^40. One is only likely to
discover this when the installation is complete, and if that is not what
was wanted, it is then too late to do anything about it other than wipe
the disk and start all over again.

This is not a trivial problem. It is quite reasonable, for example, to
want to be able to say "this system has eight gigabytes of main memory"
and "this system has eight gigabytes of swap space", and have those two
values mean the same thing. The difference between a binary and decimal
"gigabyte" is over seven percent, not insignificant when allocating
filesystem storage.

Currently the only solution is to know in advance (probably by learning
the hard way) that decimal units are being used, and if binary units are
wanted, to write them out in full: 1024, 1048576, 1073741824, etc. This
is clearly not adequate.

Possible solutions:

1 - AT AN ABSOLUTE MINIMUM: at the point where the use of metric
suffixes is suggested, explain that these really are decimal, so that
people who want the binary values know that they need to write them out,
as above.

2 - Give the suffixes the same binary values that many people would
expect them to have, and explain this. There is no need to support the
hard disk manufacturers' deceptive marketing strategy. Flash drives are
not specified with decimal units. (Are they?)

3 - Let the user choose at the beginning of partitioning whether these
units will have binary or decimal meanings, both for specifying new
partitions and volumes, and reporting those that are already present, as
well as the sizes of physical media.

4 - The disk partitioner is presumably based on GNU parted, which allows
either binary ("KiB", "MiB", "GiB", "TiB") or decimal ("KB", "MB", "GB",
"TB") units to be used. Explain to the user that they may specify any of
these units, and pass them through to parted.

5 - Solution (4) leaves open the question of what units will be used to
report volume/partition/disk status. Parted provides the "unit" command
for this purpose, as well as that of solution (3). Perhaps this should
be made available as a menu option, or in some other way.

6 - Alternatively, if the size of some disk volume is an exact multiple
of 2^{10,20,30,40}, report it using the appropriate binary unit,
otherwise with a decimal unit.

http://www.gnu.org/software/parted/manual/html_node/unit.html

Hopefully something can be done about this problem before the next major
release.

So if the partitioner invites people to specify their swap space, or any
other volume, in units of "gigabytes", which JUST ABOUT EVERYBODY
understands to mean 2^30 in that context, and instead it uses the hard
disk manufacturers' phony units which are seven percent smaller, WITHOUT
EVEN TELLING YOU THIS, and you only find out when the installation is
complete, and nothing can be done about it except starting all over
again, then this isn't a real bug, but just "wishlist"?

Thanks for clearing that up.



quote from ls(1) man page:

reassign 684128 partman-partitioning
thanks

Quoting Ian Bruce (ian_bruce@fastmail.net):


All of theseimply too invasive changes in the installer, particularly
in translatable material. This is zero chance that anything is done at
this point of the release.

This issue will have to be worked on for jessie, not for
wheezy. Hopefully someone will come with a patch (I somehow doubt it
as I think that only incredibly picky people really do care about
differencesbetween MB and MiB......but, who knows?).

Anyway, reassigning this to the package it belongs to.

Quoting ian_bruce@fastmail.net (ian_bruce@fastmail.net):

I think you probably have a strange definition of "just about
everybody". In reality, I think that just about nobody cares about
gigabytes being 2^30, or 1000000000. This is basically splitting
hairs, which "wishlist" perfectly fits.

Yes. Please don't shout.

Christian PERRIER wrote:

The difference between a TB and a TiB is 93 GiB (or 99 GB).

While I loathe the SI decimal units [1] displaying them is the right default,
sadly. But human2longint should certianly be extended to handle the "iB"
units.

    $ bc <<< "scale=6 ; (2^40) / (10^12)"
    1.099511

The difference between a binary and decimal terabyte is ten percent, or
one hundred gigabytes.

I would have thought that a lot of people would care about that, but
maybe I'm just strange.

    $ bc <<< "scale=6 ; (2^30) / (10^9)"
    1.073741

    $ bc <<< "scale=6 ; (2^20) / (10^6)"
    1.048576

Clearly the hard disk manufacturers care about differences of even five
and seven percent, or they wouldn't have been deliberately ripping
people off for decades.

http://en.wikipedia.org/wiki/Binary_prefix#Legal_disputes

This has caught me out in the past. When it says gigabyte I expect 2^30
bytes. Hopefully this time when I do an installation I will remember to get
a calculator out. The people who don't care are mostly those who don't know
what a gigabyte is.

Roger

Le mardi, 7 août 2012 22.46:03, Roger Lynn a écrit :

(FTR, that's near to be insulting in my standards…)

I know what giga- and gibi-bytes are, but I still don't care right now; we are
actually trying to get Wheezy out and there are other priorities (such as 572
Release-Critical bugs) than this type of problem.

That said, I don't think anyone is trying to avoid a proper resolution of this
bug. So the people who care mostly (and know what a gibibyte is) should start
working on patches if they really want to get this fixed; this work will not
come magically out of the blue.

Cheers,

OdyX

I'm sorry, that was over the top.

Absolutely agreed. I wouldn't hope to see this fixed for Wheezy - even just
changing the wording of the text requires an enormous amount of work at this
stage - it's just frustrating to see it apparently being dismissed out of
hand as not being a problem.

Thanks,

Roger

Please have a look at IEC 60027-2 (or Wikipedia) to make clear that
the wording is absolutely correct. So if anybody wants to change
the units of measurement, a change to the wording _and_ the code
is required.

cu
  Herbert

I don't think anyone has suggested that the wording is wrong, just not what
is expected by many users. (Not that I agree with those standards, but
that's irrelevant.)

Roger

<odyx@debian.org> wrote:
longint2human() and human2longint(), which implement both base-1000 and
base-1024 conversions to/from decimal, depending on a configuration
option.

MD5 checksums:
c75b7b8e66eff67f188fa18d328897ad  partman-base_158.diff
77d5ea04ee877a29cd9246d621156f0d  cvt.sh

Apart from the 2^(10*n) versus 10^(3*n) issue, this code improves on the
current version in the following respects:

- the longint2human() function produces a result with a precision of two
decimal places, rather than just one. This is consistent with what lvm,
mdadm, and parted do. This could be extended to any number of decimal
places with no code changes, just by altering a few constants.

- if the unit displayed is bytes, then the decimal places are omitted.
There cannot be a fractional number of bytes allocated, so it makes no
sense to suggest this by printing a decimal point followed by zeros.

- the current code suffers from the following anomaly: longint2human()
maps the value 999999 to "1000.0 kB", and 1000000 to "1.0 MB". These
rounded values are equivalent, so they ought to be displayed the same
way. The new code maps the entire range [995000..1004999] to "1.00 MB",
and behaves analogously with other units.

- the new code is twelve lines shorter than the original.

By defining a single environment variable, the new code can be
configured to use the binary, rather than decimal, values of the
suffixes {K, M, G, T} for both input and output, while retaining the
above features.

*******

I take the point that it is not currently feasible to get translations
of new or changed text for the installer. What I propose is to apply
this small patch, and make no changes at all to any text. When operating
in decimal mode, the new code is functionally identical to the old,
apart from the improvements listed above. When operating in binary mode,
identical input text will simply be interpreted as s*(2^(10*n)) rather
than s*(10^(3*n)).

The choice of whether the partitioner operates in binary or decimal mode
can be controlled by a boot parameter, so as not to introduce any new
user-visible text into the installer.

http://www.debian.org/releases/stable/i386/ch05s03.html.en#installer-args

*******

Now we can all fight about whether the default partitioning mode should
be binary or decimal. I'm curious to hear why, if just about nobody
cares about the difference between 2^(10*n) and 10^(3*n), it would be
unacceptable to default to 2^(10*n), which is what just about everybody
who does care would expect.

reassign 684128 partman-base
thanks

Quoting ian_bruce@fastmail.net (ian_bruce@fastmail.net):


Thanks for your care providing a patch. Even if I don't give a great
importance to this issue, some people seem to (including you) so
there's no reason to not consider your patch.

Still, however, I'd like to get other D-I people advice about
including these changes *now* as thereis always a risk of regressions
which, at this point of the release, we would like to avoid.

So, others, advice? Should we apply this patch or should we wait
post-wheezy (with the risk of forgetting about it, which would be
sad).

ian_bruce@fastmail.net wrote:

I hate to bring this news, but this cannot be used in the installer, because
shell arrays are a bashism, and the installer uses busybox sh.

joey@gnu:~>busybox sh

BusyBox v1.20.2 (Debian 1:1.20.0-6) built-in shell (ash)
Enter 'help' for a list of built-in commands.

~ $ decimal_units=(1 1000 1000000 1000000000 1000000000000)
sh: syntax error: unexpected "("

FWIW, it is possible, though painful to emulate shell arrays using eval,
or other tricks.

For example:

decimal_units_0=1
decimal_units_1=1000
index=1
eval echo \$decimal_units_$index

Le jeudi, 9 août 2012 12.13:12, ian_bruce@fastmail.net a écrit :

To be completely coherent, I think the patch should actually use the correct
units in the two "modes": {K,M,G,T}B in the case of 10^ and {Ki,Mi,Gi,Ti}B in
the case of 2^, otherwise we're just allowing two interpretations of the same
units instead of making sure the correct units are used for the correct
numbers.

Cheers,

OdyX

Thanks for pointing that out. It seems that shell arrays are more of a
ksh-ism; see the manual page for mksh(1). I did try to avoid obvious
bashisms, but I didn't know that Bourne shell doesn't have arrays, or
that its arithmetic was so crippled.

Fixed now; I've tested this version with busybox, and it seems to work
fine. See attachments.

checksums:
425334e865579c218e15f66fa018dd50  partman-base_158.diff
0e38d0168a14c42cccd24857c0fd219c  cvt.sh

I'll remember that trick; it will be useful sometime. In this case, the
arrays are read-only, so a case statement wrapped up in a function will
do fine. Arrays are just functions on a subset of integers, anyway.

As a special bonus, this version outputs "KiB", "MiB", etc, when
operating in binary mode.

As an extra special bonus, it now has support for {peta,pebi}bytes, just
in case somebody wants to set up an array of 400 three-terabyte disks.
Unfortunately, this isn't currently working, apparently because of
64-bit arithmetic overflows in "expr". (Isn't that what "expr" is
supposed to avoid?)

For those who don't care, a decimal petabyte is only 8/9 of a binary
pebibyte.

For output, there's no problem with that; see my second patch, here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#88

If the {Ki,Mi,Gi,Ti}B units were to be used for input, then the
installer text would have to explain that. However, it was stated that
it is not now feasible to get new text translated. This is why I wrote
the patch such that binary or decimal units would be selected
automatically, possibly depending on a boot parameter; no text changes
are necessary.

In any case, not everybody agrees that the "correct" units are those
officially certified for the convenience of the hard disk manufacturers,
rather than what has been conventional usage for decades. I offer again
the example of lvcreate(8), which only provides the binary units, with
"incorrect" symbols, and does not see any need to even explain this.

Thanks for taking seriously, the fact that /other/ people take this
issue seriously. I'm quite willing to change the patch, to incorporate
other people's advice.

That's an important consideration. I offer the following test scripts as
evidence of non-regression.

The h-to-l.sh and l-to-h.sh scripts should be run in busybox, once with
the old definitions of human2longint() and longint2human(), and once
with the new definitions, and the output saved to file.

The old and new versions of human2longint() produce output that is
byte-for-byte identical.

The new versions of longint2human() produces output that is different
from the old in the following respects, as previously advertised:

- if the chosen unit is bytes, then decimal fractions are not printed

- otherwise, two decimal places are printed

- values such as 999999 are rounded up to "1.00 MB"

The third script, round.sh, when applied to the new version output,
accounts for the first two causes of difference, leaving the third:

    $ ./round.sh <l-to-h.new | diff l-to-h.old -

These tests must obviously be run in decimal mode, since the reason for
the patch is that the old code does not operate with binary unit values.

I would be interested to hear suggestions as to what sort of tests of
binary mode operation would be considered sufficient for the patch to be
accepted.

It seems that Historical Revisionism, of the bad kind, is now in
operation at Debian, in that critical commentary about unapplied patches
is made to disappear down the memory hole, without leaving so much as a
trace on the relevant bug report.

If it were thought that the criticism was unfair, or inaccurate, then it
could be allowed to remain in place, so that other people might judge
its lack of merit for themselves.

In the case of bug #684128, post #108, however, the fact that the
offending message was promptly vaporized* (as will be this one also), of
course suggests that the opposite is true.

It seems to me that this kind of thing sets a bad precedent for the
future, but I'm just a bug reporter, of the worst kind, those that
actually fix the problem that they're complaining about.

So what do I know?



* after an automatic acknowledgement had been sent:

Subject: Bug#684128: Info received ("When I use a word," Humpty Dumpty said...)
Message-ID: <handler.684128.B684128.136491666013227.ackinfo@bugs.debian.org>
References: <20130402083114.6bba69b4.ian_bruce@fastmail.net>

[...]

Since you took so long to get to the point in that message, it's
possible that your message was incorrectly identified as spam.

Or this may just be an accident in processing of incoming mail, which
has occasionally occurred.

Ben.

I initially wrote up a detailed bug report, and then when somebody
suggested that the problem would get fixed faster if a patch were
provided, I wrote that too. Somebody else pointed out that the patch
contained a bashism, which couldn't be used in the installer, so I fixed
that within a day. It was then objected that the patch might break
something, so I wrote a set of test scripts to show that it produced
exactly the same results as the existing code if operated in decimal
mode, and offered to write tests for binary mode, if anybody could
suggest what would constitute acceptable correctness proofs.

I then waited for eight months for any indication that the slightest
notice would be taken of any of this.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128

Seeing none, and concluding that a technical "style of communications"
had failed, it occurred to me to resort to allegory, and a literary
reference which I thought would be both familiar and directly relevant.

http://lists.debian.org/debian-boot/2013/04/msg00020.html

When THAT disappeared into a black hole, another literary reference came
to mind (1984, if anyone cares).

http://lists.debian.org/debian-devel/2013/04/msg00176.html

Apparently some conclusions are so obvious that they may never be
mentioned.

Yes, indeed. What I've learned is that technical arguments, and patches
offered in support of them, will be either completely ignored,
apparently forever, or actually ridiculed as being "incredibly picky"
and "splitting hairs".

Previous experience with the Debian BTS suggests that if I presume to
offer ANY technical comment at all, I may be subjected to personal
insults and told to keep my mouth shut.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495049

Attempts to reason by way of analogy to different but parallel
situations, while quoting directly from previous argument, will be
assumed to be "spam", and vaporized at the click of a mouse button.

So you win. There is apparently no mode of argument, or "style of
communications", which is capable of penetrating the Debian
bureaucracy. It is impervious, even to patches which have been
previously solicited. Silly me, for taking that seriously.

As for moving on, I think I will, to some other project where they don't
think that lying to absolutely everybody who installs it, about the size
of their disk partitions, by as much as seven or ten percent, is a
matter of complete indifference, to be dismissed in favour of More
Important Things.

And in case you hadn't noticed, the subject line of this message is yet
a THIRD literary reference. I guess you're well rid of me and my spam.

Goodbye.

I supplied plenty of facts.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#5

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#12

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#36

I even supplied patches, after I was invited to do so.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#66

The first was justly criticised on the grounds that it contained a
bashism. I immediately corrected it.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#88

It was stated that the time was not appropriate to introduce
user-visible changes in the installer. I pointed out that my patch did
not require any such thing, and that if it had been acceptable for the
installer to operate for many years, and many Debian releases, without
mentioning that it was using a definition of "megabytes" and "gigabytes"
contrary to what technically knowledgeable people would expect, it could
just as well operate in conformance with their expectations, and not
mention that either.

The only other objection raised was the danger of introducing
regressions. I supplied test scripts which demonstrated that my code
produced results which were byte-for-byte identical to the existing code
when operating in decimal mode, and offered to write tests for binary
mode if anybody could suggest what would be accepted as proof of
correctness.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684128#103

I was polite to everyone involved in the discussion, and answered every
question put to me.

Then I waited to see if anything would happen, or any further comment
would be made. For eight months.

If Debian bug report #684128 proves anything, it is that you will never
convince anyone with technical argument, facts advanced in support of
it, patches which completely solve the problem, test scripts which prove
non-regression of those patches, and answering every single question or
objection advanced regarding any of this.

All of that will be completely ignored, without further comment.

If you then attempt, as a last resort, to reason by way of analogy, this
message will be categorized as "spam" and disappear into thin air.

Perhaps there's some new and improved way of convincing people that I'm
just unaware of. If so, tutorial references would be appreciated.

Well, that's certainly clear.

As I said, I've tried everything I can think of.

I'm out.

That's right; I wrote it up in detail, provided patches when asked to do
so, provided test scripts to demonstrate the correctness of those
patches, answered every question and objection raised about it.

And then waited patiently to see if any notice would be taken of it. In
silence. For eight months.

Hearing nothing, I concluded that my previous mode of argument was not
persuasive, and decided to try something else. That disappeared into
thin air. I wondered whether anybody thought that was a problem, and
asked. So here we are.

What could possibly be longer and more sordid than that?

Sorry, I, personally, do not care -- note: neither this nor my previous
response represent the project as a whole, but is solely *my* opinion --
about the long and sordid tale of your bid to get attention for this
bug. I only chimed in because your ranting, baseless accusations against
the project all hinged on your assumption that someone was "out to get
you" whereas, in fact, it seemed obvious to me why someone mistook your
response for spam, and I had hoped to get through to you on that one
point. Well, if you can't learn from that and modify your approach, and
thus you have decided to put your energies elsewhere, maybe it is best
for all parties involved.

Ben

Quoting ian_bruce@fastmail.net (ian_bruce@fastmail.net):
team) were mostly trying to release an installer for wheezy during the
last 8 months....and that the proposed changes were not judged as
suitable for wheezy....as nobody picked them up.

Nothing proves that the patches you proposed will be ignored *after*
the release of wheezy. Frankly speaking, given the current manpower in
the D-I team, it might need help to get them in, mostly by reminding
us *on time*, and factually, that these patches are here.

D-I has several dozens of components, each with a few dozens of
bugs....several probably with working patches that only need someone
in the team to have enough time and his|her attention focused on them.

I perfectly understand you can be frustrated but, honestly, as of now,
we're focused on the wheezy release, again. Fixing debootstrap has
much more importance than Giga/Gibibytes. Once wheezy is released, I
see no reason for your proposed patch to be "rejected".

But, again, the best way to remind this to us is a simple mail like
"Hello, folks, may I remind you about this patch and proposed fix?
Would you consider it for jessie?". No need for dozens of line of
irony which....being (most of us in the D-I team) non native speakers
of English...we won't even understand..:-)

Sadly, it appears that failure to communicate was from both sides

Ian was told several times that changes may not be accepted for wheezy

However, that communication was overshadowed by several comments
suggesting nobody cares about the issue at all, rather than comments
like that above explaining the relative importance of fixing other issues.

This issue of units comes up again and again, there is a huge thread on
debian-devel in 2007[1] - that hardly seems like something that nobody
cares about.

So while it may not make it into wheezy (I won't give my own opinion on
this one, it is for the release team to decide), I don't think the
reporter of this bug should be deterred by comments about it being a
trivial wishlist or nonsense item.

It may actually be useful for the technical committee to review what is
on the wiki and make some general statement about Debian's position (if
they haven't done so in the past), and that can guide the way similar
bugs are classified for jessie and beyond.

1. http://lists.debian.org/debian-devel/2007/06/thrd2.html#00700

2. http://wiki.debian.org/ConsistentUnitPrefixes

I was not following this bug report but reading it, it reminds me of
the Unit Policy [1] that got approved and is gradually implemented in
ubuntu/debian packages.

Looking at d-i the usage is mostly correct sans 'k' should only be
used lower-cased with current base-10 units.

The major problem with changing these is that same prefixes are
accepted for pre-seeding and it would be ill-advised to change those,
thus backwards compatability must be preserved in the values that can
be preseeded as well as entered by the user.

The default to base-10 units, is good as majority of the installer
deals with HDD drives (not SSD) and not RAM. If I have 1TB drive and
want half of it for one thing and 1/4 for this and 1/4 for that, no
space should be left on the drive. Hence matching and using same units
as disk-manufacturers is good.

The case where we mix & match => e.g. making swap big enough (base-10)
for RAM size (base-2) is tricky. And it's something to consider in the
UI.

I understand your frustration, but as it happens installer
work/improvements becomes a hot topic post-freeze as this is when
people start to use the installer, notice things and try to write
features. And all of these features will only land for the next cycle
with a release in ~= 2 years time. Tell me about bad timing, eh?! =)

W.r.t. boundry alignments, I believe it its already aligning at 2048
by default and there is ongoing work to align with 4K boundries
properly. But note that boundry alignment has little to do with user
displaying/specifying amount of gigaheaps one wants to be allocated
where.

Everyone seems to agree to bring support to input/output Ki/Mi etc
prefixes. That's a feature and can only go into jessie branches and or
wait for wheezy release. Once that lands we can bike shed to death
where to display what units and what to default to where going
forward.

[1] https://wiki.ubuntu.com/UnitsPolicy

Regards,

Dmitrijs.

ps. there are disk manufactures that mix base-2 and base-10 units.
E.g. using one to calculate "1MB" and then using the other multiply
and gain GB/TB factors /o\

Daniel Pocock writes ("SI units (was Re: failure to communicate)"):

You should try to address this through the policy process.  If and
when we have competing policy proposals the TC might want to
arbitrate.

Ian.

Am Freitag, den 05.04.2013, 12:59 +0100 schrieb Dmitrijs Ledkovs:

SSD manufactures use base-10 units, too. Even 128 GB SSDs have 128 *
10^9 bytes for the users, but 128 * 2^30 bytes internally. The
difference between 128 GiB and 128 GB (9.44 GB) is used for
over-provisioning.
as much space as a "720 KB" floppy. The "720 KB" floppy has 720 KiB and
the "1.44 MB" has 2 * 720 KiB = 1.44 * 1000 * 1024 bytes = 1.41 MiB =
1.47 MB!

Come on... it's not! Let's be serious 5 minutes here.
There isn't even a warning about which units are in use.
This fools our users (me included, for many years...).

The freeze of Wheezy might be an argument, but what you
wrote above, really isn't one.
I really hope that it wont be the case. That it doesn't go into
Debian 7.0.0, I would understand, but at least, we need it
for a point release. And at least, we need things written in
the release notes about it, if not a message in the installer
itself (Christian, don't kill me... ;).

Could we stop the winning and have this bug fixed please,
or the patch rejected (with a valid motivation)?

Thomas

P.S: Not only with SSD you have problems with boundaries.

Hi Thomas,

Le vendredi, 5 avril 2013 17.52:19, Thomas Goirand a écrit :

Are you seriously arguing in favour of pushing a behavioural change into a
stable point release? I doubt the stable release team would accept that, but
I'm not under their hats.

I disagree. It has worked that way for a long time (and many releases in that
timeframe), so it is probably not "that" broken.

I'm not saying the bug isn't valid of course, just that it's severity is IMHO
correct.

The patch doesn't need rejection: it is a valid patch for a valid bug. It just
affects d-i, which is quite an important piece of software for sane Debian
releases. As you know, d-i is critically low on manpower.

You want that bug fixed? Great: test the patch, document your tests, upload to
experimental with the patch, gather feedback, get involved, etc. For a fix to
land in Wheezy, this should have happened 8 months ago. Now is the time to
release Wheezy, not the time to add cosmetic and disruptive fixes to it. (And
again, I think the changes are probably worthwhile, it's only the timing which
is wrong.)

OdyX

Hi Ian.

ian_bruce@fastmail.net wrote:

I'm (again) not really sure what you mean with these paragraphs, but
the message

(for reference, that mail is available online at
http://lists.debian.org/20130402083114.6bba69b4.ian_bruce@fastmail.net)

looked a lot like non-sense spam to me and I reported it as such in
the BTS. And obviously the one reading that report was of the same
opinion. I wouldn't be surprised if others hit the "Send a report that
this bug log contains spam" link after that mail of yours, too.

If you want to make comments about bugs that people should actually
read, please make sure that your mail is concise and does not tell
fairy tales to hide your intent. The BTS is no literature contest.

TIA.

		Regards, Axel

I've wrote that we should at least address the issue, in a way
or another, through the next point release if that is safer.

But, are you seriously proposing that we leave the issue as-is ???

Well, at least *I* didn't know it was broken (yes, you read
well: BROKEN !!!), and I was quite shocked to read it, Knowing
that absolutely nothing gives you clues about it is equally
shocking. In fact, I saw that strange behaviors, and couldn't
explain it. We are talking about someone who has been using
Debian for 10 years. Now, think about someone who is a new comer...

Sure. And let's add the fix for the next point release if
everyone think it's not a good idea to fix it right now
(though it's quite a shame we can't).
That's all I'm saying.

Yes, I know. And the patch author is also right to tell that
refusing contribution isn't a good idea to address this lack
of manpower.

As much as I don't agree with his tone, I do agree with
the arguments.

Do you believe the legend that d-i was frozen 8 months
ago? I don't... :D

(only half joking here...)

I don't agree it is cosmetic. I'm not sure it's disruptive.
Then make your case for the next point release, not
for Jessie, please !

Thomas

[ Not answering all occurrences, things got repeated a few times… ]

Thomas Goirand <zigo@debian.org> (06/04/2013):

It is not.

For wheezy, certainly.

Now is not the time, point releases are not the time. Next release
cycle is perfect for considering such requests.

It is disruptive, and that's what matters right now for wheezy; that
means r0 but also later point releases.

Mraw,
KiBi.

Quoting Thomas Goirand (zigo@debian.org):


Of course. The issue is there since partman exists (about 2005, from
memory) and has probably never prevented anyone to install Debian
since then. So, yes, this issue will still be in wheezy.

Hopefully, the issue will be fixed in jessie, though.

Hi Ian (and thanks Ian),

Your issue is now on the radar and this is a clear way forward - even if
it has been missed for wheezy, I too would like to see this progress in
Debian, not just for the installer

Here is the link to the policy team:
http://wiki.debian.org/Teams/Policy

and this is the existing wiki on units, which doesn't appear to be
formal policy just yet:
http://wiki.debian.org/ConsistentUnitPrefixes

In the short term, the installer team really appear to have a lot of
competing demands, there are a range of bugs listed for D-I related
packages.  In the long term, to keep Debian at the forefront, things
like installing onto bootable btrfs RAID1 works fine[1] but needs
changes to the installer to make it easy, and that appears to require
strategic changes to the installer architecture[2].  There is a clear
opportunity here for more people to be involved in the installer project
(both collaborating on the more urgent bugs and doing strategic work),
and approaching these issues as a whole would certainly give you a
chance of influencing its future direction.

Regards,

Daniel



1. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686130

2. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686097

Well, it's been 7 years since this bug was opened.

Sure, it's not killing anyone.  And I assume that the partitioner
correctly handles alignment issues for current drives.  But still, IMHO,
any time software does something other than what you expect it to do,
it's broken.

A simple suggestion: just have partman correctly parse KiB, MiB, GiB,
and TiB when someone manually enters a partition size.  Currently, these
generate an error message.  Also, on that page, include a short
explanation of the acceptable units and their meanings.

I'd say it's fine for partman to just always display partition sizes in
10^n units.  The only folks likely to care about this are ones doing
manual partitioning.  It's likely that any such person will understand
what's going on when they specify a 32GiB partition and then see 34.4GB
in the list of partitions.

It also might be handy to include fdisk on the net-install cd, for use
in a shell (or ctrl-alt-f2).  But that might be a pain, given that fdisk
now has its own shared libs.

Just my 2c.
-Jeff

found 684128 226
thanks

Hi,

why is this bug still unfixed?

In bookworm d-i, entering 512 MiB seems to be using something
entirely different, and 512 Mi gives an error “invalid size”.

This still makes d-i unsuitable for most partitioning.

bye,
//mirabilos

Hi,

Thorsten Glaser <tg@debian.org> (2023-07-25):

https://www.debian.org/devel/debian-installer/News/2023/20230516.en.html
documents a fix for #913431, which is a duplicate of this bug report.

Closing this one accordingly.

“Something entirely different” compared to what?

The second syntax is indeed invalid.

Feel free to use a different tool.


Cheers,

Cyril Brulebois dixit:

Huh.

I was a few metres across the room, but I heard something around
twohundred-something, which was definitely no power of two either.

OK, it was only tried as last resort anyway.

Oh, I personally do, but not everyone is I.

bye,
//mirabilos

Thorsten Glaser <tg@debian.org> wrote (Tue, 25 Jul 2023 20:15:04 +0000 (UTC)):

With a 12.0 netinst image, creating a new partition with a size of 512 MiB
results in a parition of 536 MB, creating a partiton of 10 GiB results in
a partition of 10,7 GB.
So I guess it works as it should.

The (visual) output is still in MB / GB, apart from this a see no issue.


Holger

reopen 684128
retitle 684128 src:debian-installer: show ISO/IEC 60027-2 units (as well); show valid suffixes
found 684128 226
thanks

Holger Wansing dixit:

Hrm, the output being only in one format can be a problem, but it’s
not as critical. I would still love for *that* to be fixed, i.e. either
only ISO/IEC 60027-2 units or both those and decimal.

OK, thanks for confirming. I heard twohundred-something across the room,
which would have been quite off, but didn’t have a chance to visually
inspect myself.

Could this information (valid unit sufficēs) be added to the dialogue
where the size is entered? Screen space should suffice.

I’ll repurpose this bug for that (both input and output changes).

Thanks,
//mirabilos

Hi,


Am 26. Juli 2023 23:19:31 MESZ schrieb Thorsten Glaser <tg@debian.org>:

Yes, I already thought about if changing the template would make sense here.



That would require synchron changings in partman-partitioning and
partman-auto-lvm.


Patches attached as a proposal.
CC'ing debian-l10n-english for template review (three identical additions
in two packages).


Holger

Holger Wansing wrote:
[...]
[...]

Looks good to me.  Mind you, this makes the passive voice in the first
line a bit more of a stylistic and syntactic mismatch, so I might
suggest changing it to

    Hint: you can use "max" as a shortcut to specify the maximum size, or

throughout...

Holger Wansing dixit:

Thanks!

Could we also get the size output in both formats? I realise that
will most likely not be a change as simple…

bye,
//mirabilos

Hi,

Justin B Rye <justin.byam.rye@gmail.com> wrote (Fri, 28 Jul 2023 10:04:09 +0100):

I found there is another template, which needs to be changed for this.

Patch attached (especially for review on l10n-english).


Holger

Holger Wansing <hwansing@mailbox.org> writes:

diff --git a/debian/partman-lvm.templates b/debian/partman-lvm.templates
index 509d9a7..63219c0 100644
--- a/debian/partman-lvm.templates
+++ b/debian/partman-lvm.templates
@@ -376,8 +376,9 @@ Type: string
 # :sl3:
 _Description: Logical volume size:
  Please enter the size of the new logical volume. The size may be
  entered in the following formats: 10KB (Kilobytes), 10KiB (Kibibytes), 10MB
 (Megabytes), 10MiB (Mebibytes), 10GB (Gigabytes), 10GiB (Gibibytes), 10TB
 (Terabytes), 10TiB (Tebibytes). The default unit is Megabytes.
                                                     ^^^^^^^^^^

I wonder if this last word is a typo and should say Gigabytes? (if not
please consider changing the installer default - no-one is going to be
happy to have accidentally made a MB-sized partition!)

I reads OK as-is, but to avoid repetition of 'enter the size' you could
start the second sentence with something like "You can use the following
formats:"

Hi,

Am 13. August 2023 10:46:50 MESZ schrieb Richard Lewis <richard.lewis.debian@googlemail.com>:

No, that's no typo. And the patch does not touch this.
So, it's just the current status quo.

But I will evaluate, if that should be changed.

LGTM, thanks


Holger

Hi,

Thorsten Glaser <tg@debian.org> wrote (Fri, 28 Jul 2023 19:53:52 +0000 (UTC)):

Just pushed (to partman-partitioning, partman-auto-lvm and partman-lvm).


Holger

Hi,

Holger Wansing <hwansing@mailbox.org> wrote (Wed, 16 Aug 2023 19:40:38 +0200):
- partman-partitioning 148
- partman-auto-lvm 92
- partman-lvm 147