Thanks for information and the update, if I can help you in any way please let 
me know! Closing this issue now.

regards,
-mika-

I hope this message does not automatically reopen it, I was just late with 
reading my mails.

> Just noticed that this bugreport didn't receive any love in the last time,

Indeed, not even mine. No, I didn't contact anyone else about my patches. Near 
the end of last year I came across this again but since nothing had happened, I 
didn't give it high priority and then forgot about it.

> Grml stopped shipping gnu-fdisk because gnu-fdisk doesn't play together
> with util-linux fdisk and caused to much headaches.

I prefer util-linux fdisk over gnu-fdisk by far, so I'm satisfied with the 
situation.

> ... would suggest contacting upstream if any patches need to be applied.

Right, I should do that. But these days I'm very occupied with my job. So, most 
likely I will not put much effort into it within the few months. When I manage 
to get my patches merged in upstream, I inform you, ok? Maybe I must 
investigate a bit, because leaving a testing version to be the last one for 
several years looks suspicious.

Closing this issue as part of our bug squashing party, please feel free to 
reopen this issue if we should investigate further. Thanks!

regards,
-mika-

Just noticed that this bugreport didn't receive any love in the last time, 
sorry for that. :( Dirk, is upstream aware of your patches? Grml stopped 
shipping gnu-fdisk because gnu-fdisk doesn't play together with util-linux 
fdisk and caused to much headaches. Therefore I tend to close this bugreport 
and would suggest contacting upstream if any patches need to be applied.

Thanks!

regards,
-mika-

Here's the new patch, with "Bytes" for display and size specification and some 
other improvements.

There's still something that could be seen as either a bug or a feature: Unless 
you specify the size of a partition in sectors, it is adjusted to whole 
cylinders. I don't know what the GNU cfdisk does if you specify a size that 
would cause a partition to end or begin in the middle of cylinder. I thought 
about a new command line parameter to switch off this security feature, but 
that'a something that requires a bit more thinking. Mark, would you need that?

Regards
Dirk

That should be "Thanks, Mika", of course.

Meanwhile I noticed that I forgot the "Bytes" unit and while testing the new 
units, I got some ideas about improvements... but I rather have some sleep now 
(it's 4:57 local time now). So please wait for about a day for the next, better 
patch :)

Thanks, Mike, and sorry for being that late. But please read on :)

Mark wrote: "(only 1 year vs. 6 years old for util-linux?)"
I checked, util-linux is hosted at kernel.org, the latest (testing-)version is 
2.13-pre7 from 6th march 2006, about 2 years and 2 months old. I think they are 
a bit too careful or conservative with their development and adding features, 
on the other hand I don't buy that "Anything 6 years old has bugs of its own", 
rather the opposite. But anyway:
 
Mark wrote: "Personally I wouldn't care if only the util-linux cfdisk offered
decent units like GNU cfdisk."
Well if that's your only issue: Here's a patch against util-linux-2.13-pre7, 
you can get it from kernel.org. Unpack the sources, apply my patch, configure, 
make, make install as usual.

This will give you the following additional units: 
KILOBYTES = 1000 Bytes, 
KIBIBYTES = 1024 Bytes, 
MEBIBYTES = 1024*1024 Bytes, 
GIBIBYTES = 1024*1024*1024 Bytes and while I was at it,
2Ki-Blocks= 2048 Bytes and
4Ki-Blocks= 4096 Bytes.
Additionally, when giving the size of a partition, you can now not only specify 
the units K,M,G,S,C but also Ki,Mi,Gi.
I wrote this change yesterday and it works nicely. This patch is hereby put 
under the GNU Copyleft - Mika, if you feel like using it for grml and thereby 
making grml the first distribution with the best cfdisk ever, please do. :) 
It's quite simple anyway. Since the built-in "ceiling" function seemed to have 
troubles with high values, I replaced it with calls to "ceil" from the math 
library, because of that it needs to be linked with -lm now, but that shouldn't 
be a problem anywhere. 

Regards, Dirk

* Mark <bts@bts.grml.org> [20080813 06:26]:

> Thanks Mika; we may be on different wavelengths?  I never use GNU "fdisk" but
> only GNU "cfdisk" and no problems.  There is also GNU "parted"?  And shared
> libparted?  The only program I ever use is GNU cfdisk, I assume dynamic-linked
> to libparted?  Yes?  No?

> I do not understand Debian's bug 46188 response (today) from Aurélien GÉRÔME. 
> He claims: "util-linux fdisk is more mature than gnu-fdisk whose upstream
> development has stopped from quite some time."  Even if true, Debian is supposed
> to enable choice.

ACK regarding "supposed to enable choice", I'll f'up on #461888.

> But is it true?
> http://www.gnu.org/software/parted/features.shtml
> "Latest Stable Release
> 1.8.8 was released on 2007-08-10"
> (only 1 year vs. 6 years old for util-linux?)

> Aurélien could resolve the artificial conflict here, with or without GNU
> collaboration.  Thanks for contacting GNU, we'll see what they say.

Don't mix parted and GNU fdisk, two different programs just using
the same lib. And GNU fdisk IS pretty out-of-date, just visit
http://directory.fsf.org/project/fdisk/ and browse through the
links to mailinglist, code, etc..

Just to get an idea about the state of GNU fdisk:

# fdisk -l > /tmp/fdisk.gnu
[1]    947 segmentation fault (core dumped)  fdisk -l > /tmp/fdisk.gnu
# fdisk -v
GNU Fdisk 1.0

And I definitely won't mix fdisk and cfdisk from two different
packages. The only chance I see is to use fdisk/cfdisk of util-linux by
default and provide gnu-fdisk on request. Though I'd like to see
this within the official Debian packages.

regards,
-mika-

That GNU web site links to
http://lists.alioth.debian.org/pipermail/parted-devel/
...seems active to me...?

Here is some nearly 10-year old Debian history FWIW.
http://lists.debian.org/debian-devel/1999/01/msg00436.html

Comment.  Personally I wouldn't care if only the util-linux cfdisk offered
decent units like GNU cfdisk.  After 6 years they can't add that feature?  Now
that's stale development...

But I may be thoroughly confused, sorry if I am.

# GNU cfdisk libs
ldd /sbin/cfdisk
	linux-gate.so.1 =>  (0xb7fd3000)
	libparted-1.8.so.9 => /lib/libparted-1.8.so.9 (0xb7f5c000)
	libuuid.so.1 => /lib/libuuid.so.1 (0xb7f59000)
	libdl.so.2 => /lib/libdl.so.2 (0xb7f55000)
	libncurses.so.5 => /lib/libncurses.so.5 (0xb7f24000)
	libc.so.6 => /lib/libc.so.6 (0xb7dd7000)
	libdevmapper.so.1.02.1 => /lib/libdevmapper.so.1.02.1 (0xb7dc2000)
	/lib/ld-linux.so.2 (0xb7fd4000)
	libselinux.so.1 => /lib/libselinux.so.1 (0xb7da8000)
	libsepol.so.1 => /lib/libsepol.so.1 (0xb7d67000)

Thanks Mika; we may be on different wavelengths?  I never use GNU "fdisk" but
only GNU "cfdisk" and no problems.  There is also GNU "parted"?  And shared
libparted?  The only program I ever use is GNU cfdisk, I assume dynamic-linked
to libparted?  Yes?  No?

I do not understand Debian's bug 46188 response (today) from Aurélien GÉRÔME. 
He claims: "util-linux fdisk is more mature than gnu-fdisk whose upstream
development has stopped from quite some time."  Even if true, Debian is supposed
to enable choice.

But is it true?
http://www.gnu.org/software/parted/features.shtml
"Latest Stable Release
1.8.8 was released on 2007-08-10"
(only 1 year vs. 6 years old for util-linux?)

Aurélien could resolve the artificial conflict here, with or without GNU
collaboration.  Thanks for contacting GNU, we'll see what they say.

* Mark <bts@bts.grml.org> [20080805 04:02]:

> The bugs.debian links are not working right now, so I'll just shoot from the hip.

> Anything 6 years old has bugs of its own....that's archaic, even by Debian
> standards.  Run vol_id in another tty to get labels.  This is the first I've
> seen label trouble in GNU cfdisk and as bugs go, that's a minor affair.  But
> both programs have quirks.  We could debate forever.

It's NOT that someone can't "get labels" (of course we all know of
the existence of vol_id) but GNU fdisk has a serious problem with
several partitions and does not start at all then!

> Since grml is a sysadmin distro, it should have both tools on CD.  Not every
> machine has net connections when repair/setup needs to happen.

> Debian packages that kill each other are poorly designed, and grml *should*
> deviate.  That is, include both programs, but not by means of Debian packaging.
>  A zsh/bash script/alias for 'cfdisk' can prompt for user choice.

If we want to ship GNU fdisk together with util-linux (which we need
as dependency for other packages as well) we have to solve
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461888 somehow.

It wouldn't be such a problem to work around this issue if GNU fdisk
wouldn't fail due to the "unrecognised disk label" problem. But
users were REALLY annoyed by this cfdisk problem and we had to get
rid of GNU fdisk therefore (just see
http://bts.grml.org/grml/issue417 to get an idea, I got several
mails regarding this issue). If we would work around this issue
using a script/alias users still might encounter problems when
scripting cfdisk (like 'cfdisk -P s /dev/ice') without noticing the
difference between GNU fdisk and util-linux behind the cfdisk
binary.

I'll ping the maintainer of GNU fdisk regarding #461888, lets' see
what options we have.

regards,
-mika-

The bugs.debian links are not working right now, so I'll just shoot from the hip.

Anything 6 years old has bugs of its own....that's archaic, even by Debian
standards.  Run vol_id in another tty to get labels.  This is the first I've
seen label trouble in GNU cfdisk and as bugs go, that's a minor affair.  But
both programs have quirks.  We could debate forever.

Since grml is a sysadmin distro, it should have both tools on CD.  Not every
machine has net connections when repair/setup needs to happen.

Debian packages that kill each other are poorly designed, and grml *should*
deviate.  That is, include both programs, but not by means of Debian packaging.
 A zsh/bash script/alias for 'cfdisk' can prompt for user choice.

Additionally having bytes, KiB, GiB would be nice, yes. I also tend to change 
my mind while looking at the screen. Or rather, I create and re-create 
partitions several times, fine-tuning the size by moving start and end, 
maximizing and putting on filesystems... Gparted isn't usable for me, it lacks 
precision. 

To get on-topic, an additional package with gnu (c)fdisk would be fine by me - 
provided that it does not clobber the names of other programs. How about 
renaming it, to gcfdisk, gfdisk and so on? But if I must choose between a known-
good program that did not change during the last 6 years and a new one with 
obvious bugs, I take the first one any time. ;)

I hope this will not become an either-this-or-that case, but if this happens, I 
hereby vote for the old package in advance.

* Mark <bts@bts.grml.org> [20080711 09:05]:

> Grml has superior package selections.  GNU cfdisk is one of them.  Please keep
> it.  Sidux 2008-02 (just released) has a Debian cfdisk version 2002 (6 years old!).

> That variant has few units (MB, sectors, cyl).  GNU cfdisk has bytes, KiB, KB,
> GiB, GB, etc.  This choice is extremely helpful.  I use dd_rescue to copy
> partitions and need byte precision for that.

> I loathe fdisk input/output operation because I change my mind while staring at
> the screen.  Fdisk gives nothing to look at.  Gparted shows bars, but lacks the
> byte precision of GNU cfdisk and needs an X session too.

> Unclear what the "annoying bugs" are...package problems?  Isn't that a Debian
> issue?  The program has always worked for me.  My favorite partitioning tool.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461888 is really
just a Debian packaging issue (though an annoying one), yes.

The main problem is:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=445304

It was such an annoying problem that we even added it to our FAQ:
http://grml.org/faq/#fdisk

Sad situation. :-/

mfg,
-mika-

Grml has superior package selections.  GNU cfdisk is one of them.  Please keep
it.  Sidux 2008-02 (just released) has a Debian cfdisk version 2002 (6 years old!).

That variant has few units (MB, sectors, cyl).  GNU cfdisk has bytes, KiB, KB,
GiB, GB, etc.  This choice is extremely helpful.  I use dd_rescue to copy
partitions and need byte precision for that.

I loathe fdisk input/output operation because I change my mind while staring at
the screen.  Fdisk gives nothing to look at.  Gparted shows bars, but lacks the
byte precision of GNU cfdisk and needs an X session too.

Unclear what the "annoying bugs" are...package problems?  Isn't that a Debian
issue?  The program has always worked for me.  My favorite partitioning tool.

Yes, GNU fdisk has some annoying bugs (see http://bugs.debian.org/cgi-bin/
bugreport.cgi?bug=461888 for my bugreport). gnu-fdisk will be removed again 
with the next release and won't be shipped again until the outstanding issues 
are resolved.

thanks for reporting,
-mika-

GNU cfdisk 1.0 does not show labels of partitions on /dev/hda. I mounted the
grml-64_0.1 partition (as /mnt/grml-0.1_64_iC2_, so the label was found and used
by the script that sets up the mount points) and started cfdisk 2.12r from there
- it shows all labels correctly. All partitions have been created with cfdisk
2.12 as "maximized", except  /dev/hdb2 and /dev/hdb3. All partitions except
/dev/hdb8 contain filesystems with labels.
Possible solution: Use cfdisk 2.12r instead of GNU cfdisk 1.0.