1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

GEOM: ad0s2: geometry does not match label (255h,63s != 16h,255s)

Discussion in 'Installing and Upgrading FreeBSD' started by mickey, Dec 6, 2009.

  1. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    Since upgrading from 7.2 to 8.0, I am seeing these messages during boot:
    Code:
    GEOM: ad0: partition 1 does not start on a track boundary.
    GEOM: ad0: partition 1 does not end on a track boundary.
    GEOM: ad0s2: geometry does not match label (255h,63s != 16h,255s).
    
    Despite these scary messages, everything works fine.

    The system is set up for dual boot FreeBSD/W2k and FreeBSD has been updated from source since initial 6.x install. I am pretty certain, that the slice layout had originally been created, using the w2k installer.

    Initial surveys indicate that the geometry, that for example fdisk is using, must have changed somehow:
    Code:
    ******* Working on device /dev/ad0 *******
    parameters extracted from in-core disklabel are:
    cylinders=191525 heads=16 sectors/track=255 (4080 blks/cyl)
    
    Figures below won't work with BIOS for partitions not in cyl 1
    parameters to be used for BIOS calculations are:
    cylinders=191525 heads=16 sectors/track=255 (4080 blks/cyl)
    
    Media sector size is 512
    Warning: BIOS sector numbering starts with sector 1
    Information from DOS bootblock is:
    The data for partition 1 is:
    sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX)
        start 63, size 67103442 (32765 Meg), flag 80 (active)
            beg: cyl 0/ head 1/ sector 1;
            end: cyl 1023/ head 254/ sector 63
    The data for partition 2 is:
    sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
        start 67103505, size 209728575 (102406 Meg), flag 0
            beg: cyl 1023/ head 255/ sector 63;
            end: cyl 1023/ head 254/ sector 63
    The data for partition 3 is:
    sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX)
        start 276832080, size 294873075 (143980 Meg), flag 0
            beg: cyl 1023/ head 0/ sector 1;
            end: cyl 1023/ head 254/ sector 63
    The data for partition 4 is:
    sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX)
        start 571705155, size 209712510 (102398 Meg), flag 0
            beg: cyl 1023/ head 0/ sector 1;
            end: cyl 1023/ head 254/ sector 63
    
    and that they do not correspond, with what's in the disklabel:
    Code:
    # /dev/ad0s2:
    type: ESDI
    disk: ad0s2
    label:
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 255
    sectors/cylinder: 16065
    cylinders: 48641
    sectors/unit: 781422768
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0           # milliseconds
    track-to-track seek: 0  # milliseconds
    drivedata: 0
    
    8 partitions:
    #        size   offset    fstype   [fsize bsize bps/cpg]
      a:  4194304        0    4.2BSD     2048 16384 28552
      b:  8388608 33554432      swap
      c: 209728575        0    unused        0     0         # "raw" part, don't edit
      d:  4194304  4194304    4.2BSD     2048 16384 28552
      e:  8388608  8388608    4.2BSD     2048 16384 28552
      f: 16777216 16777216    4.2BSD     2048 16384 28552
      g: 167785535 41943040    4.2BSD     8192 65536 46928
    disklabel: partition c doesn't cover the whole unit!
    disklabel: An incorrect partition c may cause problems for standard system utilities
    
    I am wondering how to fix this. Looking for solutions, some people suggest to adjust the geometry contained in the bsd label. For me it seems though, that adjusting the values, that for example fdisk uses in it's calculations would be the correct way. But I am somewhat reluctant to perform wild experiments upon a live installation.

    It seems this is a "known problem", caused by the change of GEOM_[BSD|MBR] to GEOM_PART_[BSD|MBR] in /sys/${arch}/conf/DEFAULTS.
     
  2. richardpl

    richardpl New Member

    Messages:
    841
    Likes Received:
    0
    I fixed it partialy recreating partitions with gpart.

    But 'geometry does not match label' still happens if I enable
    native sata mode in bios.
     
  3. SpeedVin

    SpeedVin New Member

    Messages:
    16
    Likes Received:
    0
    Same here :)
     
  4. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    The harddisk in this system is PATA, and there's not much in the BIOS to configure, so I am still at a loss here.

    Looking at the output of fdisk, I still conclude, that up until FreeBSD 8.0, FreeBSD as well as w2k must have agreed upon a track being 63 sectors. Why else would the first partition have a start sector of 63?
     
  5. Supernico

    Supernico New Member

    Messages:
    2
    Likes Received:
    0
    Same problem here when I upgraded to 8.0. Problem is it was messing with the raid5 gvinum array the disk is part of, any atempt of accessing something on the raid5 was freezing the OS. Reverted to 7.2 and all is fine now
     
  6. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    Yes, I have been running FreeBSD 6.x and 7.x on this machine without ever changing the slices, and everything was fine until 8.0.

    But I do not consider downgrading to 7.2 an option here, especially as everything works fine, other than the complaints about the geometry when booting up.

    So what are the options here?

    Can GEOM_PART_[MBR|BSD] be fixed, to behave similarly as GEOM_[MBR|BSD] did ?
    Is there a possibility to store the original geometry (255h,63s) somewhere, so that GEOM_PART_[MBR|BSD] will use it instead of 16h, 255s ?
    Can that be done without rendering the machine inoperable?
     
  7. Erratus

    Erratus New Member

    Messages:
    320
    Likes Received:
    0
    I'm booting 8.0-RELEASE-p1 on a ZFS mirror (ad8+ad10). On a third harddisk (ad4)I have a swap slice (no ZFS). For this swap (ad4s3), which was created by 7.2-RELEASE I get the same warning geometry does not match label (255h,63s != 16h,255s).
     
  8. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    I've found sort of a solution...

    In /usr/src/sys/i386/conf/DEFAULTS I commented out:
    Code:
    options         GEOM_PART_BSD
    options         GEOM_PART_EBR
    options         GEOM_PART_EBR_COMPAT
    options         GEOM_PART_MBR
    
    and replaced these with:
    Code:
    options         GEOM_BSD
    options         GEOM_MBR
    
    then recompiled and installed my kernel. No warnings anymore, kernel is happy again with the slice layout.

    On a sidenote, this is how the DEFAULTS file used to look up to 7.2.

    I have the strange feeling something is terribly wrong with GEOM_PART_[BSD|MBR].
     
  9. richardpl

    richardpl New Member

    Messages:
    841
    Likes Received:
    0
    You are wrong, GEOM_BSD and GEOM_MBR are terribly broken ....
     
  10. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    Then probably so is Windows 2000 installer, which created this slice layout in the first place.

    Wasn't the intention of all that slice/MBR stuff, to be compatible with windows?
     
  11. fonz

    fonz Moderator Staff Member Moderator

    Messages:
    2,436
    Likes Received:
    5
    This post is not intended as yet another Microsoft bashing, but then again they do have a (deserved) reputation in Redmond for having a mind of their own about many things...

    I have seen on several occasions that Linux and/or {Free,Net,Open}BSD "complain" about the way Windows lays out slices. However, I'm not entirely sure how many of these geometry complaints are actually caused by Windows itself and how many by installers provided by computer manufacturers (e.g. Dell, Packard Bell, Toshiba and others). Some of those installers are quite braindead and it wouldn't surprise me if they were the ones to blame rather than Windows itself.

    When I do a multi-boot install, I usually try to partition the disk with a Linux/BSD partitioner before installing Windows, just to err on the safe side.

    On the upside though, I have so far never experienced any actual problems caused by these geometry warnings.

    Just my 2 holiday cents,

    Alphons
     
  12. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    I think as this is a FreeBSD forum, we all agree on this point ;)

    I also agree on this point, although I must say that the Windows 2000 disk management also has never complained about this layout.

    In the end, we are talking about C/H/S values, that are there for historical reasons, although modern drives support LBA addressing and actually don't care how you calculate these numbers to make up something near the total number of sectors.

    I have done that once, with the result that windows wouldn't want to work with that partition. I must admit though, that quite some time has passed since then, but I never had any problems in partitioning the drive with win2k, install wink2 and then FreeBSD. And I have done multiple installations in this way.

    No, as I said, other than having these warnings, which of course is a PITA, both OS work well.

    The point is, try your favourite search engine for something like the term "geometry does not match label", and see for yourself, how many users are out there, having this exact same problem in one facette or another. And though I have spent some time, looking for a definite answer as to how to handle this problem, the solution is yet to be found.
     
  13. Beastie

    Beastie Member

    Messages:
    1,916
    Likes Received:
    1
    Sure many will agree. But *because* this is the FreeBSD Forum, we also don't *care*.
    And we also agree (at least some of us) that this type of discussion -- comparing foos and bars, bashing, etc. -- is pointless and can easily end up in endless flame wars.

    Besides, if users don't trust Microsoft or computer manufacturers and resellers with partitioning and formatting disks, they can easily redo all this themselves. That's what I do every time I get a new HDD, pendrive, etc.
    If you want to dual-boot, create the (first) Windows slice using Windows' fdisk/setup, and the FreeBSD slice using FreeBSD's fdisk. As simple as that.
    I only use native tools, never touch the other OS's slice during a setup and install FreeBSD's boot0 as boot manager. I've never had any problem with that and on one machine I actually dual-boot with Windows 2000 just like you.
     
  14. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    @mickey

    >the solution is yet to be found.

    Forget about this message, it's because the harddrive lies to the system about its true nature. Ask some devs, the 'problem' is almost as old as FreeBSD and once in a while it will show up and confuse new users.
     
  15. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    I guess we have all seen this. Actually my intention was not to compare any foos or bars, I just wanted to find a workable solution to a problem that obviously does exist.

    Sure thing, though I never bought any pre-configured machines, other than notebooks.

    As almost something like 2 years have passed since I initially installed this machine after replacing the old HDD, I cannot exactly reproduce the steps I had taken back then, but I guess it was something like this:
    1. Use win2k installer to create the first primary partition and install win2k onto that.
    2. Boot FreeBSD 6.X install CD, create second primary partition with it and install FreeBSD onto that.
    3. Use FreeBSD's fdisk command to set active flag back to the first primary partition.
    4. Boot win2k, copy over /boot/boot1 to Windows C: drive and modify boot.ini to add FreeBSD to boot menu. Create and format using NTFS the third and fourth primary partition using the win2k disk management.

    Well I am using BSD since 386BSD 0.1, and I am confused, so I guess this is not limited to new users only ;)
     
  16. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    >Well I am using BSD since 386BSD 0.1, and I am confused, so I guess this is not limited to new users only

    I didn't say it's a mere 'newbie-thing', but something like the 'crappy' sysinstall ... we have to live with it, at least for a while yet ;-)
     
  17. Beastie

    Beastie Member

    Messages:
    1,916
    Likes Received:
    1
    Why do you do that? Doesn't FreeBSD's default boot manager work well?

    BTW it's possible to make it read-only and boot automatically from a specific slice if you want.
     
  18. Beastie

    Beastie Member

    Messages:
    1,916
    Likes Received:
    1
    Why do you think it's a sysinstall thing?
    Wasn't the duplicate code removed from sysinstall? Doesn't it now share the same code with the command-line versions of fdisk and bsdlabel? Shouldn't these two be affected too?
     
  19. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    >Why do you think it's a sysinstall thing?

    I didn't say it's a sysinstall thing, but it's like the .... I did mention sysinstall, because it is behind the times and a bunch of nasty bugs.

    FreeBSD tells you one thing, "hey I see your harddrive, but it talks nonsense to me". That's confusing like mickey said, but it's a known "problem", imho some kind of a bug.
     
  20. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    Because:
    1. Win2k already comes with a bootloader, whether you use it, or install a second one.
    2. It nicely integrates into the boot menu
    3. I always hated that raw "F1 ... F2 ..." screen. NDOS converter on my 8 bit ATARI had more style :)
     
  21. Erratus

    Erratus New Member

    Messages:
    320
    Likes Received:
    0
    I like to remember that this warning does not show on 7.2-RELEASE. It is new on 8.0-RELEASE systems.
     
  22. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    Neither did they appear on the 6.x series.

    The interesting part is that I have two other machines installed in the same manner (Dual boot w2k/FreeBSD 8.0), which have just been upgraded from 7.2 to 8.0, and I don't remember seeing such warnings on these. Maybe I will find the time to look at these tomorrow.
     
  23. Erratus

    Erratus New Member

    Messages:
    320
    Likes Received:
    0
  24. mickey

    mickey Member

    Messages:
    306
    Likes Received:
    0
    I had a look at one other machine, that is installed dual boot w2k/FreeBSD 8.0 and does not suffer from GEOM warnings. As you can see it too uses a geometry with 63 sectors/track:

    Code:
    ******* Working on device /dev/ad0 *******
    parameters extracted from in-core disklabel are:
    cylinders=10592 heads=15 sectors/track=63 (945 blks/cyl)
    
    Figures below won't work with BIOS for partitions not in cyl 1
    parameters to be used for BIOS calculations are:
    cylinders=10592 heads=15 sectors/track=63 (945 blks/cyl)
    
    Media sector size is 512
    Warning: BIOS sector numbering starts with sector 1
    Information from DOS bootblock is:
    The data for partition 1 is:
    sysid 7 (0x07),(NTFS, OS/2 HPFS, QNX-2 (16 bit) or Advanced UNIX)
        start 63, size 4913937 (2399 Meg), flag 80 (active)
    	beg: cyl 0/ head 1/ sector 1;
    	end: cyl 1023/ head 14/ sector 63
    The data for partition 2 is:
    sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
        start 4914000, size 5095440 (2488 Meg), flag 0
    	beg: cyl 1023/ head 255/ sector 63;
    	end: cyl 1023/ head 14/ sector 63
    The data for partition 3 is:
    <UNUSED>
    The data for partition 4 is:
    <UNUSED>
    
    which conforms with the label:

    Code:
    # /dev/ad0s2:
    type: unknown
    disk: amnesiac
    label: 
    flags:
    bytes/sector: 512
    sectors/track: 63
    tracks/cylinder: 15
    sectors/cylinder: 945
    cylinders: 5392
    sectors/unit: 5095440
    rpm: 3600
    interleave: 1
    trackskew: 0
    cylinderskew: 0
    headswitch: 0		# milliseconds
    track-to-track seek: 0	# milliseconds
    drivedata: 0 
    
    8 partitions:
    #        size   offset    fstype   [fsize bsize bps/cpg]
      a:   524288        0    4.2BSD     2048 16384 32776 
      b:   262144   524288      swap                    
      c:  5095440        0    unused        0     0         # "raw" part, don't edit
      d:  4309008   786432    4.2BSD     2048 16384 28552 
    
    So the question is, why does GEOM_PART_* want to use a geometry based on 255 sectors/track on the other machine, where GEOM_[BSD|MBR] happily uses a geometry based on 63 sectors/track?

    I might be wrong, and for quite some time now, I actually haven't cared much, but isn't it so, that these 16 heads, 63 sectors/track were imposed by limitations in BIOSes for some time?
     
  25. oliverh

    oliverh New Member

    Messages:
    557
    Likes Received:
    0
    http://lists.freebsd.org/pipermail/freebsd-current/2009-March/004830.html

    Some people think using gpart instead of fdisk could be a solution. I did have this 'problem' while installing FreeBSD 8 current and later with sysinstall and FBSD 8.0R, but it's gone since I use gpart and ZFS.

    Maybe this helps:

    http://koitsu.wordpress.com/2009/10/12/testing-out-freebsd-8-0-rc1/