[SOLVED]fdisk not allowing use of entire drive

symbioticism · 2013-09-11 06:43:43

Hello,

I don't know if this should go in 'Installation' or 'Newbie Corner': probably both. Anyway, I encountered this problem while installing Arch, so forgive me if this is too n00b to be in this forum.

While I was writing a new partition table with fdisk, I noticed that it won't let me use all of my disk space. I am repartitioning a laptop with 160GB to put Arch Linux on it (it currently has Fedora 17/19 on it; it used to have Windows once upon a time), but fdisk will only start the partitions at sector 2048; when I try to enter 1 or any number smaller than 2048, it says it is out of range, but gives no explanation as to why it is starting so high up.

And again, when I made two logical partitions within an extended partition, it would leave 2048 sectors before each of them. The other primary partitions would write edge-to-edge, without leaving unused space, but not the logical partitions.

It isn't a dire issue: I can still use the computer just fine with that extra space unaccounted for; but I would rather have the use of my entire disk if that is an option.

I have searched all over the internet and cannot find anything that explains this sufficiently - maybe I am googling the wrong keywords?! If anyone knows why this would be happening, or where I can go to find out more about this, please let me know. The help is much appreciated.

Thanks.

I haven't even installed Arch yet, and already I am learning.

Last edited by symbioticism (2013-09-12 12:26:31)

aesiris · 2013-09-11 10:39:49

symbioticism wrote:

...
I have searched all over the internet and cannot find anything that explains this sufficiently - maybe I am googling the wrong keywords?! If anyone knows why this would be happening, or where I can go to find out more about this, please let me know. The help is much appreciated.
...

There are two problems, the first is that you have to leave enough space for the partition table at the beginning.

The second problem is partition alignment.

Decades ago sectors were the physical unit, nowadays (in particular with SSDs) that is not true. Reads and writes to a SSD are done in chunks of a different size, so it is very important that your partition blocks begin and end at a physical boundary.

For example suppose that the blocks have a size of 512 sectors (both physical and partition) and the first block of your partition begins at sector 63. To access a block on the partition you would have to access two blocks on the disk: the first block is from sector 63 to 578, but these sectors belong to the first (sectors 0-511) and second (sectors 512-1023) physical blocks. As you can see misalignment destroys performance.

If you have no reason to believe that 2048 is the wrong number to which align partitions, let fdisk do its job.
At most it will "waste" some MB (< 0,01% of your drive) and you have much bigger overhead at the filesystem level (journal, file smaller that block files, backup superblocks, etc.).

By the way some people think that you should partition your disk with a GPT table (fdisk supports only MBR).
I think that you will be perfectly fine with MBR, but I suggest to also read the Arch wiki page on GPT before you continue.

nomorewindows · 2013-09-11 15:37:47

I think it is to make room for some of the bigger bootloaders, but there is some space needed to allow certain other functions (such as gparted).

alphaniner · 2013-09-11 18:27:55

aesiris wrote:

There are two problems, the first is that you have to leave enough space for the partition table at the beginning.

For the record, this is incorrect. On an MBR partitioned drive, the table of four primary partitions (one of which may be marked as an extended partition) is part of the MBR. Logical partitions are defined in one or more EBRs.

symbioticism · 2013-09-11 18:47:54

aesiris wrote:

By the way some people think that you should partition your disk with a GPT table (fdisk supports only MBR).
I think that you will be perfectly fine with MBR, but I suggest to also read the Arch wiki page on GPT before you continue.

Thanks for this suggestion. I had read a little about GPT before, but was deterred because I had misread that UEFI was needed for it - I have BIOS - but upon your spurring, I reconsidered, read some more, and I think I am going to go with GPT.

Also, in my reading, I found a more complete explanation of the (what I had thought arbitrary) 2048 limit: GRUB2 has various stages of loading (I'm sure you know this, but for other folks trying to find answers that stumble upon this post, I am going to elucidate the process) - stage 1, along with the partition table, uses sectors 1-34; stage 1.5 (which finds stage 2) fills out 34-2048, so MBR automatically covers these sectors, but GPT does not: you can set the stage 1.5, or BIOS boot partition, in GPT.

If that was a poor summation, a better explanation can be found here.

Anyway, thanks for the suggestions. I think have figured out what I needed to move forward with installing Arch Linux!

aesiris · 2013-09-11 22:19:19

alphaniner wrote:

aesiris wrote:
There are two problems, the first is that you have to leave enough space for the partition table at the beginning.
For the record, this is incorrect. On an MBR partitioned drive, the table of four primary partitions (one of which may be marked as an extended partition) is part of the MBR. Logical partitions are defined in one or more EBRs.

Thank you for the correction.

Mine was a lousy explanation of why you can not start at the beginning of the disk (even without a bootloader), but this excludes only sector 0, so did not contribute to OP's problem.

@symbioticism
If you have no more questions regarding this issue, you should mark the thread as solved: edit the title and add [SOLVED] at the beginning.

cfr · 2013-09-11 23:01:52

symbioticism wrote:

aesiris wrote:
By the way some people think that you should partition your disk with a GPT table (fdisk supports only MBR).
I think that you will be perfectly fine with MBR, but I suggest to also read the Arch wiki page on GPT before you continue.
Thanks for this suggestion. I had read a little about GPT before, but was deterred because I had misread that UEFI was needed for it - I have BIOS - but upon your spurring, I reconsidered, read some more, and I think I am going to go with GPT.
Also, in my reading, I found a more complete explanation of the (what I had thought arbitrary) 2048 limit: GRUB2 has various stages of loading (I'm sure you know this, but for other folks trying to find answers that stumble upon this post, I am going to elucidate the process) - stage 1, along with the partition table, uses sectors 1-34; stage 1.5 (which finds stage 2) fills out 34-2048, so MBR automatically covers these sectors, but GPT does not: you can set the stage 1.5, or BIOS boot partition, in GPT.
If that was a poor summation, a better explanation can be found here.
Anyway, thanks for the suggestions. I think have figured out what I needed to move forward with installing Arch Linux!

I think you are referring to legacy grub. Be careful as in Arch "grub" is what some distros call grub2, while legacy grub is no longer in the official repos or officially supported.

However grub(2) certainly needs room for its boot loader and does not like being installed to a partition at all - so the bios boot partition with a GPT table is really important for this case. (Of course, you may well prefer a different boot loader - only grub needs this much room!)

Arch Linux

#1 2013-09-11 06:43:43

[SOLVED]fdisk not allowing use of entire drive

#2 2013-09-11 10:39:49

Re: [SOLVED]fdisk not allowing use of entire drive

#3 2013-09-11 15:37:47

Re: [SOLVED]fdisk not allowing use of entire drive

#4 2013-09-11 18:27:55

Re: [SOLVED]fdisk not allowing use of entire drive

#5 2013-09-11 18:47:54

Re: [SOLVED]fdisk not allowing use of entire drive

#6 2013-09-11 22:19:19

Re: [SOLVED]fdisk not allowing use of entire drive

#7 2013-09-11 23:01:52

Re: [SOLVED]fdisk not allowing use of entire drive

Board footer