From http://www.linuxforums.org/forum/redhat-fedora-linux-help/118994-error-18-selected-cylinder-exceeds-maximum-supported-bios.html
`Your BIOS does not see the whole drive. If you create a small
partition, mounted at /boot, then the BIOS will be able
to find the stage 2 of the bootloader. It depends on the size
of the Windows partition, whether there is enough space
to do this. Boot from a live cd and, in a terminal, issue
the command fdisk -l
This will tell you if the Windows partition extends beyond
the limit, probably the old 1024 cyl limit. If you create a partition
wholly under this limit for /boot, you will be OK'
This makes it sound like the fresh drive should have three
partitions: One for /boot', one for swap (at the end of the
drive), and one for everything else. /boot should be small.
This was not the case on this drive: I had put all the
installation files into a single, large partition (sdc2) and wondered
why, during installation, Ubuntu had insisted on
creating three partitions; the first of which was tiny.
Elsewhere, a recommendation to run fsck was found:
$ sudo fsck /dev/sdc
fsck 1.40.8 (13-Mar-2008)
e2fsck 1.40.8 (13-Mar-2008)
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdc
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193
Doing this with sdc1 gave the same error, but sdc2 was ok. sdc1, I think,
should contain the boot stuff. Maybe I should reformat it as ext3
and copy /boot over to it.
From http://wiki.linuxquestions.org/wiki/GRUB#Error_18
`This error is returned when a read is attempted at a linear block address beyond the end of the BIOS translated area. This generally happens if your disk is larger than the BIOS can handle (512MB for (E)IDE disks on older machines or larger than 8GB on others.). In more practical terms this means the BIOS is unable to start executing the kernel because the kernel is not located within the block it can access at boot up time.
This can be circumvented by creating a boot partition at the beginning of the disk that is completely within the first 1023 cylinders of the harddrive. This partition will contain the kernel.
The kernel itself does not suffer from the same limitations as the BIOS so after the BIOS has loaded the kernel the kernel will have no problem accessing the whole harddrive. Newer BIOSes will automatically translate the harddrives size in a way that it can be completely contained within the first 1023 cylinders and hence modern computers do not suffer from this problem.
The same error can happen when the BIOS detects a disk in a different way as Linux does. This can happen when changing motherboards or when moving a GRUB-bootable disk from one computer to another. If this happens, just boot with a GRUB floppy, read the C/H/S numbers from the existing partition table and manually edit the BIOS numbers to match. If using a SUSE linux and installing on VM Ware this problem is solved by creating a small partition at the very beginning of the harddisc, and mounting it as /boot
Read more: http://wiki.linuxquestions.org/wiki/GRUB#Error_18#ixzz0tpqX29V7
'
So, it looks like the partition containing the kernel image
and initrd must be smaller than 8Gb for the BIOS to understand
it. That would explain the small first partition.
Another note at
http://www.supergrubdisk.org/forum/index.php?topic=150.0
suggests the grub lines should refer to sdc, not sdc1 as:
device (hd3) /dev/sdc1
root (hd3,0)
So, to summarise:
I need three partitions.
A small, primary, initial one to contain /boot
A large secondary one to contain everything else.
A third, medium swap one.
So, reformatting:
$ sudo parted /dev/sdc
No. parted does not support ext3. What format should
the first partition be? Does this imply it's usually
ext2? Odd. So, parted won't work (ext2 only), and
fdisk won't work (sdc has a GPT (GUID Partition Table)):
I'm getting annoyed.
The Parted user manual says that to manage ext3, use resize2fs or mke2fs.
Great.
----------------------------------------------------------------
OK. Reformat sdc completely. I think there may be a hangover
from the first attempt to install Lynx.
I reinstalled Lynx in an ext3 partition. Move these files, first.
Partition, format, copy back as appropriate. Can't! Permissions etc will get
ruined, I think. So, create a new partition table, format, install.
Set the partition table:
1) Make a small primary
partition to contain linux images (they're about 2 Meg) and
initrd.image files (they're about 8 meg each). Make the
partition, say 4 gig. It will, I think, be either ext2 or ext3.
sudo fdisk sdc
p
Disk /dev/sdc: 2000.3 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000
Device Boot Start End Blocks Id System
OK. It's blank, but I still get the GPT warning, oddly.
Space is 255 heads * 63 sectors * 243201 cylinders * 512 bytes = 2000396321280 bytes = 1.8193498556502163 Terabytes. Yes, the units are bullshit.
Reserve 50 Gig = 50 Gig * 1024 Meg/Gig * 1024 k/Meg * 1024 bytes/k = 53687091200 bytes
for swap, at the end of the drive. We are left with 2000396321280 bytes - 53687091200 bytes = 1946709230080 bytes.
Use a primary partition for swap. I therefore have three primaries left.
Use a (small) primary for /boot, and a large primary for everything else.
So, use 4 Gig for \boot = 4 * 1024 Meg / Gig * 1024 k/Meg * 1024 bytes / k = 4294967296 bytes.
That leaves the main primary space as, 2000396321280 - 4294967296 - 53687091200 = 1942414262784 bytes.
BOLLOCKS. fdisk is not behaving properly. p1 of 4 gig is ok. Then, setting p2 with 1.8T - 4gig
WHY IS THIS SO DAMN COMPLICATED?!
For fucks sake. I want:
p1: boot. 4gig = 4294967296 bytes.
p2: data. 1.8T - 4g - 50g = 1.8 * 1024**4 - 4 * 1024**3 - 50 * 1024 ** 3 = 1921138871500 bytes
p3: swap. 50 g = 50 * 1024 ** 3 = 53687091200 bytes
fdisk, new, primary, 1, default cylinder (1), + 4294967296 is ok
then, new, primary, 2, default cylinder (2), + 1921138871500 is NOT OK.
Use 1000 instead of 1024?
p1: boot. 4gig = 4 * 1000**3 = bytes.
p2: data. 1.8T - 4g - 50g = 1.8 * 1024**4 - 4 * 1024**3 - 50 * 1024 ** 3 = 1921138871500 bytes
p3: swap. 50 g = 50 * 1024 ** 3 = 53687091200 bytes
No! Use cylinders instead?
>>> total = 1.8*1024**4
>>> boot = 4*1024**3
>>> swap = 50*1024**3
>>> data = total - boot-swap
>>> cylinders = 243201
>>> boot / total * cylinders
527.77994791666674
>>> data / total * cylinders
236075.970703125
>>> swap / total * cylinders
6597.2493489583339
OK! Lets do this. In fdisk:
new, primary, 1. Start: 1. Last: 6597
new, primary, 2. Start: 6598. Last: (6598 + 236075 = ) 242673
new, primary, 3. NO FREE SECTORS AVAILABLE.
WHAT THE FUCK?!
More reading. http://www.ibm.com/developerworks/linux/library/l-gpt/index.html
says that GPT is the new system, used with HDD > 2Tb. The problem is
also with filesystems. EXT2 and 3 have a filesize limit of 2Tb.
A GPT disk does not have a Master boot record, as the MBR is
limited in the size it can address: to 2Tb.
LILO and fdisk cannot cope with GPT. parted (gnu parted) can.
Looks like a change to parted is due.
So, the boot disk has a (limited) MBR, describing where
part two of the MBR is (for code) and describing the
partitioning. Gavin may have been correct in his suggestion
of removing the other disks and installing to the new one:
this would result in a GPT disk that could be chained to (I think)
from the original MBR or, maybe even boot to the GPT
disk with the chaining to the old, MBR disk.
Step one. AVOID fdisk! USE parted.
No comments:
Post a Comment