Re: grub error 18
- From: "davesurrey" <dave@xxxxxxxxxxxxxxxx>
- Date: Fri, 13 Feb 2009 13:31:38 -0000
"Daniel James" <wastebasket@xxxxxxxxxxxxxxxx> wrote in message
news:VA.0000166f.28ad3196@xxxxxxxxxxxxxxxxxxx
In article news:<49942035$0$16176$db0fefd9@xxxxxxxxxxxxxx>, DavesurreyHello Daniel,
wrote:
I did post the result of fdisk which may help a lot.
Yes, I've just seen it.
Think you mean sdb4 here rather than sdb5.
Or have I mis-understood.
My fault. I actually meant to type sdb2 (sdb5 was a thinko on my part)
because I thought the EXTEND partition would be the second partition in
the MBR, but I see now that you actually have three primary data
partitions in there and that the EXTEND partition is sdb4 (as you say).
Sorry for any confusion there.
Understand but I have since added an sdb13 and it worked just fine.
So doubt any limit is causing this.
There's clearly no /physical/ limit, or you wouldn't be able to create
the partitions in the first place.
The error message you're getting, though:
"Error 18: Selected cylinder exceeds maximum supported by BIOS."
is one that suggests that something (presumably grub) is trying to read
the disk using CHS addressing (that is: telling the BIOS a head number,
cylinder number, and sector number to read, rather than just a logical
block number from the start of the disk -- that's the only way that
"selected cylinder" makes any sense).
The problem with CHS is that the way the head number, cylinder number,
and sector number are passed to the BIOS limits the values that are
passed. The sector number must be 1..63, the head number must be
0..255, and the cylinder number must be 0..1023 -- which is where the
8GB limit comes from. Back in the dawn of time when hard drives were
only around 10MB or 20MB in size those CHS numbers represented the
actual position of a sector on the disk ... a disk with 4 heads and 16
sectors per track gave 32k bytes per track, so 20MB used 640 tracks.
Modern disks lie about the number of heads (fdisk thinks your disk has
255 -- the maximum that can be addressed using CHS -- but it probably
only has 2 or 4) and the number of sectors per track (fdisk thinks
yours has 63 -- again, the maximum addressable). They do this to enable
CHS addressing to be able to access the maximum possible amount of the
disk ... but as CHS can't use more than 1024 cylinders the limit is
still a measly 8GB.
To overcome that limit, modern BIOSes (in the last 10 years or so)
offer an alternative way to tell the BIOS which sector(s) to read. this
is called Logical Block Addressing (LBA). In this, the caller just
specifies the sector it wants as a 32-bit number and leaves it up to
the disk's onboard controller to work out where to look for it on the
disk. That gives an addressing range of up to 2^32 sectors (of 512
bytes each) or about 2TB a disk, and so allows decent-sized modern
disks like your 250GB drive to be accessed.
Note that fdisk says that your disk has 30515 cylinders ... it didn't
get that directly from the BIOS (which can only return the information
as a 10-bit number ... and so will always say 1024) it got that by
asking the BIOS for the size of the disk (the 251.0GB figure, but
expressed in sectors) and dividing by the claimed number of heads and
sectors per track. Disks have been lying about their actual size and
geometry for years, partly to make best possible use of the limited
addressing afforded by CHS, but also to enable them to keep spare
sectors that can be mapped in in case of failure. The BIOS's view of
the disk as something that has cylinders, heads, and sectors is very
naive by modern standards!
When I run fdisk on my laptop (running debian) it says:
The number of cylinders for this disk is set to 7752
There is nothing wrong with that, but this is larger than 1024
and could in certain setups cause problems with:
1) software that runs at boot time (e.g. old versions of LILO)
2) booting and partitioning software from other OSs
(e.g. DOS FDISK, OS/2 FDISK)
that is: part of the disk will not be accessible to tools that can only
use CHS addressing.
Now, your version of grub clearly /can/ access the higher cylinders on
your disk -- which is why you can boot from sdb10 and sdb12 -- so it is
certainly capable of using LBA addressing, but it appears that for some
reason it is NOT using LBA addressing when it tries to boot sdb11.
The type ID of 83 of the data partition doesn't specify how grub should
read the disk, but grub may be looking at the type of the enclosing
EXTEND partition ... and when it sees 5 rather than f it may deduce
(incorrectly, as it happens) that your BIOS doesn't support LBA and so
tries to use CHS.
.. OTOH, if this is the problem I'd expect that grub would fail to
boot your Puppy installation from sdb5, as its EXTEND partition is
definitely a CHS type and its start cylinder is also >1024.
I'm beginning to doubt my own theory, here ...
Maybe it's the kernel that it trying to use CHS addressing, and the
kernels in your different partitions are sufficiently different that
some work and some don't when booting from high-numbered cylinders? Do
your kernels (in the partitions that are failing) have the disk driver
modules built-in or are they loaded as modules? If the drivers are
built-in then they will be loaded with the kernel by grub and
everything should be OK, if the drivers are loaded as modules the
kernel will have to use real-mode (i.e. BIOS) calls to load them, and
if the kernel bootstrap code that loads them uses CHS addressing (in
some distros) that could cause a problem.
Can you try installing "Puppy 412 Full" (which currently seems to be
working from sdb5) in (say) sdb12 in place of the non-booting MEPIS (if
I've got those partitions right, from your grub.conf (aka menu.lst))
and see whether that works?
Cheers,
Daniel.
I appreciate you sticking with me on this and giving up your time.
I have to go out now so this will have to be short.
However:
It's actually sdb10 and sdb12 that won't boot. Sdb11 and the others are just
fine.
Very easy to get confused however woth all these partitions :)
Puppy on sdb5 is fundamentally the same (as far as booting/kernels go )
as Puppy NOP on sdb10. Just some diff apps and windows manager.
But one works the other doesn't.
I have tried Puppy 412 on sdb12 before and got the same boot error message.
This was after deleting sdb12 and reformatting it.
Not sure how I can check whether the non-booting kernels have the
disk-modules in-built. How do I tell? Sorry lack of knowldge here.
But in any case as I mentioned above sdb10 is, I strongly believe, the same
as sdb5
as far as kernels go.
But I could be wrong.
Have you seen my reply to Mike above. You might find something there of
interest??
Thanks again Daniel
Appreciated
Dave
.
- Follow-Ups:
- Re: grub error 18
- From: Daniel James
- Re: grub error 18
- References:
- grub error 18
- From: davesurrey
- Re: grub error 18
- From: Daniel James
- Re: grub error 18
- From: davesurrey
- Re: grub error 18
- From: Daniel James
- Re: grub error 18
- From: davesurrey
- Re: grub error 18
- From: Daniel James
- grub error 18
- Prev by Date: Re: Why does Vista do this, and how do I turn it off?
- Next by Date: Re: Why does Vista do this, and how do I turn it off?
- Previous by thread: Re: grub error 18
- Next by thread: Re: grub error 18
- Index(es):
Relevant Pages
|
