1. Large disks
You got a new disk. What to do? Well, on the software side:
use fdisk or cfdisk to create partitions,
and then mke2fs or mkreiserfs or so to create a filesystem,
and then mount to attach the new filesystem to the big file hierarchy.
Make sure you have relatively recent versions of these utilities -
often old versions have problems handling large disks.
You need not read this HOWTO since there are no problems with large hard disks these days.
Long ago, disks were large when they had a capacity larger than 528 MB, or than 8.4 GB, or than 33.8 GB. These days the interesting limit is 137 GB. In all cases, sufficiently recent Linux kernels handle the disk fine.
Sometimes booting requires some care, since Linux cannot help you when it isn't running yet. But again, with a sufficiently recent BIOS and boot loader there are no problems. Most of the text below will treat the cases of (i) ancient hardware, (ii) broken hardware or BIOS, (iii) several operating systems on the same disk, (iv) booting old systems.
Advice
For large SCSI disks: Linux has supported them from very early on. No action required.
For large IDE disks (over 8.4 GB): make sure your kernel is 2.0.34 or later.
For large IDE disks (over 33.8 GB): make sure your kernel is 2.0.39/2.2.14/2.3.21 or later.
For large IDE disks (over 137 GB): make sure your kernel is 2.4.19/2.5.3 or later.
If the kernel boots fine, and the boot messages indicate that it recognizes the disk correctly, but there are problems with utilities, upgrade the utilities.
If
LILO hangs at boot time, make sure you have
version 21.4 or later, and specify the keyword lba32
in the configuration file /etc/lilo.conf. With an older version
of LILO, try both with and without the linear keyword.
There may be geometry problems that can be solved by giving an explicit geometry to kernel/LILO/fdisk.
If you have an old fdisk and it warns about
overlapping partitions:
ignore the warnings, or check using cfdisk that really all is well.
For HPT366, see the Linux HPT366 HOWTO.
If at boot time the kernel cannot read the partition table, consider the possibility that UDMA66 was selected while the controller or the cable or the disk drive did not support UDMA66. In such a case every attempt to read will fail, and reading the partition table is the first thing the kernel does. Make sure no UDMA66 is used.
If the BIOS hangs at boot time because of a large disk, and flashing a newer version is not an option, take the disk out of the BIOS setup. If you have to boot from the disk, look whether a capacity clipping jumper helps.
If you think something is wrong with the size of your disk,
make sure that you are not confusing binary and decimal
units
,
and realize that the free space that df reports on an empty disk
is a few percent smaller than the partition size, because there
is administrative overhead. Software that does not understand
48-bit addressing will view a 137+ GB disk as having a capacity
of 137 GB. When a capacity clipping
jumper
is present, a larger disk may have been clipped to 33 GB or to 2 GB.
If for a removable drive the kernel reports two different sizes, then one is found from the drive, and the other from the disk/floppy. This second value will be zero when the drive has no media.
Now, if you still think there are problems, or just are curious, read on.
Below a rather detailed description of all relevant details. I used kernel version 2.0.8 source as a reference. Other versions may differ a bit.
Next Previous Contents