The disk partitioning section of the gentoo handbook makes no mention of cfdisk as an alterative to fdisk. Reproducible: Always Steps to Reproduce:
I suppose the handbook uses fdisk because it is easier to document. A few output samples and a few characters to type in. cfdisk would require screen snapshots. I believe fdisk will remain as the default partitioning tool, but it might be worth mentioning cfdisk is available for those who might prefer it. A small <note> should do IMHO. Unless my fellow docdevs disagree, I'll add one.
it should be included *only* as a note and with wording similar to something like this: cfdisk may also be available for you and provides a simple ncurses interface instead of the command line-like fdisk the reason being that cfdisk has many 'problems': (1) it's not always on the livecd and i'm tired of seeing bugs that complain that cfdisk is documented but not on the livecd and vice versa (as is this bug) (2) it doesnt work for all architectures all the time making a note like you suggest would be perfect as long as we keep it sufficiently vague :)
Exactly what I had in mind. We're on the same wave length.
How about <note> Some users prefer using <c>cfdisk</c>. It might be available on your LiveCD. Note that it does not always work properly. Gentoo only supports <c>fdisk</c>. Please do not complain if cfdisk is missing from your LiveCD or if it does not work on your hardware. </note> Besides, this should appear in an arch-specific part of the handbook. Is there any arch on which cfdisk is and will not be available for sure? No need to write this all over for nothing. I suggest we add such a note to the relevant arches of the 2004.2 handbook.
Agreed. fdisk and cfdisk are both part of util-linux; assuming cfdisk supports the same stuff as fdisk it should be allright to mention it for all architectures that use fdisk.
Strangely enough <c>man fdisk</c> says """ BUGS There are several *fdisk programs around. Each has its problems and strengths. Try them in the order cfdisk, fdisk, sfdisk. (Indeed, cfdisk is a beautiful program that has strict requirements on the partition tables it accepts, and produces high quality partition tables. Use it if you can. fdisk is a buggy program that does fuzzy things - usually it happens to produce reasonable results. Its single advantage is that it has some support for BSD disk labels and other non-DOS partition tables. Avoid it if you can. """ It looks like cfdisk is recommended over fdisk by its own authors. Any comment?
This might make fdisk fans upset, but with the absense of any arguments to keep fdisk as the default tool, it looks cfdisk should become the new default tool. Also, it wouldn't require screenshots, A simple text description of the items to select would be plenty sufficient, and cfdisk does support single keystrokes to access the menu items. After looking at the fdisk doc section, and looking over cfdisk, I think the cfdisk documentation could be made shorter and easier then the current fdisk doc. An argument for cfdisk is that it is much more user friendly to the newbie linux user, and I beleive the handbook is largely built to assist that group, though not exclusively. While we are talking about partitioning, maybe I should ask default recommended partitions in the handbook. A while ago I had a conversation in #gentoo and we came to the conclusion that the /boot partition is not really necessary, as it was only for large HD support on older BIOSes that had cylinder boot partition limits. This is only necessary on PCs that have a system BIOS dated from 1992 to 1998. From looking around the web, it look like intel came out with 500+ mhz processor in 1999. The BIOS IDE Harddisk Limitations http://web.inter.nl.net/hcc/J.Steunebrink/bioslim.htm
The separation of /boot on a separate partition has other reasons such as to ensure security (if you don't mount the partition automatically) and keep the boot information separated (at least if you use grub), but it also teaches the users about using _several_ partitions for a Linux installation. You're of course free to do as you want; our default partitioning scheme is merely an example (but one that works). It's also in line with some architectures that require a separate bootpartition (even though it might be different from a /boot). Regarding cfdisk vs fdisk: I'm all in favor if the developers themselves agree that cfdisk is better. Would it be a good thing to implement this before 2004.3 goes live or is this too soon? I don't know how much time we still have; if it's less than one month I'd rather wait - rewriting those instructions means that we are again likely to have issues with it _and_ the translation teams would kill me again (luckily I have 9 lives) for making such big changes to the installation instructions a few weeks before the release.
It seems like file permission would be a much better way to handle security at /boot rather then a seperate partition. In any case, I do agree that it helps the user to learn a bit about using different partitions and for general compatibility it does have its purpose. I'd be happy with a short note added at 4.c. Using fdisk to Partition your Disk...Creating the Boot Partition. Something like ... Note: Having a seperate /boot partition is most likely only required on PCs that have a system BIOS dated earlier then 1998 (roughly anything less then 500 mhz.)
1998 was not that long ago. Instead of breaking compatibility with systems from before 1998, why not just mention that the /boot partition is not necessary for newer machines, but that it may provide some benefit to users that choose to have an initrd, or users that have special concerns about security.
We never state that a separate /boot is necessary. It's just the partitioning scheme we use as an example throughout the installation instructions.
Timeout! ARCH-maintainers are free to either warn us about not even mentioning cfdisk, mention its availability or use it instead of fdisk in their hb-install-{arch}-disk.xml file. Personally, I still use fdisk on pata, sata and scsi disks, and combinations thereof, on x86, amd64 & sparc and can't find anything wrong with it.
Closing this bug as per Josh's request in gentoo-doc's ML.