Bios freaks

Mikkel L. Ellertson mikkel at infinity-ltd.com
Mon Aug 20 14:43:43 UTC 2007


Tim wrote:
> On Sun, 2007-08-19 at 18:52 -0600, Karl Larsen wrote:
>> I have heard a thousand words a week about LVM and it never made the
>> point that it moved /boot close to the near end of a hard drive.
> 
> I haven't heard about that happening.  It's always been my experience
> that if you used the install routines to prep your drive, that it made
> the /boot partition the first one.  I don't know if that's coincedental,
> but it would be a good thing for it to deliberately do.  Other
> partitions get shuffled about, though.  I don't know the reasoning
> behind it (if there is any).
> 
I don't think Karl understood what people were trying to tell him.
The problem is not LVM moving /boot close to the end of a hard
drive, but that when you have /boot as part of the / partition,
instead of giving its own partition, the files in /boot may end up
towards the end of the drive.

> e.g. If you had created /boot/, /home/, /tmp/, /usr/, /var/, in that
> order, you might find that at the end of your manual intervention, it
> actually created the partitions in another order, albeit with /boot/
> being the first partition.
> 
> Of course, thanks to how drives fake their number of heads and
> cylinders, to accomodate how BIOSs (and IDE?) are still terribly poor at
> handling large drives, there's still no guarentee that all of the first
> partition is going to be where the BIOS can access it.
> 
The drives internal remapping should have no affect on what the BIOS
can access. The BIOS just tells the drive I want this track, head,
sector, and it could care less where it really is on the drive. If
the partition is the first x blocks on the drive, the BIOS can
access it, regardless of the physical location on the drive, as long
as the logical h,t,s is in the range the BIOS can handle.

Mikkel
-- 

  Do not meddle in the affairs of dragons,
for thou art crunchy and taste good with Ketchup!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/users/attachments/20070820/a4768219/attachment-0002.bin 


More information about the users mailing list