[CALUG] Disk alignment and boundaries -- WAS: Fedora upgrade

James Ewing Cottrell 3rd JECottrell3 at Comcast.NET
Mon Jun 20 16:26:02 EDT 2011


  I was gonna ask what stars too. Yes, the '+' means that you have an 
odd sector.

I suppose the newer fdisks may deal directly in sectors rather than 
cylinders, but remember that Primary Partition 1 shares space with the 
MBR, and the first track of the disk is reserved as a Boot Code 
Extension, so we're not totally away from CHS yet. Primary Partitions 
[234] start at a Cylinder Boundary. I always start my P1's ar Cylinder 2 
so that they are the same size as P[234] as long as they have the same 
number of cylinders.

Logical Partitions are not handled correctly in fdisk...use the x 
command followed by the p command and see that the Start offset of all 
but the first LP is 63 rather than 16065. Disk Druid et al will fix this 
for you during installation, but you are on your own later.

JIM

On 6/20/2011 3:08 PM, Walt Smith wrote:
>
> Yes, I meant the "+".  thanks.
>
> and I suppose I picked on fdisk since as far as I know, grub
> provides no user info except some kinda map.   IF grub has
> knowledge about the boots chain(s), perhaps a boot_chain_print() method
> could be added.
> I suppose my 10 partitions on my FC6 drive was still before fdisk was 
> "fixed" ??
> Unless the one Windows install on it screwed up the fdisk display.
> ( by adding "+" 's).
>
> Way way way long ago, I had surmised that having a small "normal" 
> partition
> was the way for a boot to be easy.  Of course Microsoft was perceived to
> be owning the FAT technology at the time, so I didn't think it could 
> happen
> until some court ruled FAT wasn't MS's anymore.
>
> I've seen brief mention of uEFI once or twice.. as a bios replacement ?
> Would like to see more about how it might work.  Is it in "product" now ?
> I mean, firmware has to start doing something at power-on no matter what
> else is in the box.  I guess having a ROM linux is the rage at some 
> places.
> But how different would a uEFI be ?  Or did they just leave out leggy 
> stuff ?
>
> W.........
>
>
> Celebrating over 13,000 emails in my Yahoo Inbox !
>
>     ------------------------------------------------------------------------
>     *From:* Bryan J Smith <b.j.smith at ieee.org>
>     *To:* Walt Smith <waltechmail at yahoo.com>; "calug at unknownlamer.org"
>     <calug at unknownlamer.org>
>     *Sent:* Monday, June 20, 2011 1:25 PM
>     *Subject:* Disk alignment and boundaries -- WAS: Fedora upgrade
>
>     Did you mean plus (+) instead of star (*)?  The latter is used for
>     active (not
>     required with Linux, or a non-Windows MBR).
>
>     The problem is that 63/255 sectors/heads is _non-aligned_.  That's
>     why one gets
>     the plus (+) at times.  The problem is the legacy
>     cylinder/heads/sectors (CHS)
>     geometry.
>
>     Newer fdisk versions in Linux distribution releases no longer use
>     CHS, but raw
>     sectors -- be it 512b or 4KiB.  This makes things easier to deal
>     with, and get
>     perfect alignments.  As I mentioned, I use 1GiB myself.
>
>     As far as boot chain, that has nothing to do with fdisk.  Fdisk is
>     not even
>     related to such.  The boot chain is dynamic in GRUB, handled and
>     generated at
>     boot-time.  And Windows has an extremely dumb boot approach to
>     complicate
>     matters in dual-boot.
>
>     uEFI could have solved it better than it did.  But so far, it's
>     just doing what
>     ARC did prior.  You have a FAT slice where you locate boot
>     loaders.  It is read
>     dynamically, but the rest of the boot is handled as before.
>
>     I will say one thing.  At least with Linux, you can address boot
>     issues.  With
>     NT, you're f'd if it dorks up, which has been the case with some
>     bare metal
>     Windows systems of ours on uEFI.
>
>     ________________________________
>     From: Walt Smith <waltechmail at yahoo.com
>     <mailto:waltechmail at yahoo.com>>
>     Sent: Mon, June 20, 2011 10:32:06 AM
>
>     I've always been NOT happy with the little stars that show
>     in fdisk displaying partition sizes. (I'm not complaining about
>     fdisk per se..
>     I think it was a good idea to display the info ).
>
>     Windows seems to want more precise
>     boundaries, or used to..  Haven't tried anything lately though.
>
>     But Bryans suggestion is a good one: and I would add/amplify:
>
>     There should be a way to make ( create ) nice partition boundaries
>     to make the "star" go away ( rather than some user calculation on
>     a note pad ):  either an option in fdisk or
>     a separate tool.  (you'll notice I'm not detailing the meaning
>     of "star").  I never got it down  quite perfect why other OS's
>     needed some boundary and others didn't.  ...  I believe there
>     was some discussion ( on another list ??)
>     regarding some defect in fdisk.  I'm not sure there was a defect
>     so much as
>     it's design was to simply make the part size exactly as the user told
>
>     it to.  Although perhaps round-down was a problem if the size entered
>     was "mega-something byte" rather than 123 sectors... sector
>     boundary ???
>
>     Also, fdisk allowed more than one partition to be marked "bootable".
>     I don't have an explanation for that.  I'd like to see that fixed if
>     theres not a reason.  Perhaps a marker for each partition part of
>     the boot chain
>
>     ??
>
>     An fdisk display also does not show the boot chain.
>     There have been times when I'd simply forget what the boot sequence
>     was  and have to trace it again..  I mean the path thru the
>     partitions,
>     not the kernel boot vmlinuz.
>
>     If the boot is straight from MBR, there could be a simple text display
>     showing:
>     MBR =>  /dev/hda2
>
>     if the boot is chained,
>
>     MBR => /dev/hda1 =>  /dev/hda5  ( primary partition )
>
>     MBR= > /dev/hda4(LBA) => /dev/hda6
>
>     ( chain is on partition of LBA, where LBA is encapsulation for
>     logical hda6,7,8
>     )
>
>
>
> _______________________________________________
> CALUG mailing list
> CALUG at unknownlamer.org
> http://lists.unknownlamer.org/listinfo/calug

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.unknownlamer.org/pipermail/calug/attachments/20110620/a46fb30c/attachment-0001.htm 


More information about the CALUG mailing list