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

mickey · #1 December 6th, 2009, 20:51

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.

richardpl · #2 December 6th, 2009, 23:26

I fixed it partialy recreating partitions with gpart.

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

SpeedVin · #3 December 7th, 2009, 17:55

Quote:

Originally Posted by richardpl

I fixed it partialy recreating partitions with gpart.

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

Same here

mickey · #4 December 7th, 2009, 21:55

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?

Supernico · #5 December 20th, 2009, 18:36

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

mickey · #6 December 21st, 2009, 03:35

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?

Erratus · #7 December 24th, 2009, 00:42

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).

mickey · #8 December 24th, 2009, 01:43

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].

richardpl · #9 December 24th, 2009, 11:37

You are wrong, GEOM_BSD and GEOM_MBR are terribly broken ....

mickey · #10 December 24th, 2009, 17:26

Quote:

Originally Posted by richardpl

You are wrong, GEOM_BSD and GEOM_MBR are terribly broken ....

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?

**fonz** · #11 December 24th, 2009, 17:56

Quote:

Originally Posted by mickey

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?

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

mickey · #12 December 24th, 2009, 20:29

Quote:

Originally Posted by fonz

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 think as this is a FreeBSD forum, we all agree on this point

Quote:

Originally Posted by fonz

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.

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.

Quote:

Originally Posted by fonz

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.

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.

Quote:

Originally Posted by fonz

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

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.

Beastie · #13 December 25th, 2009, 00:16

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.

oliverh · #14 December 25th, 2009, 00:33

@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.

mickey · #15 December 25th, 2009, 12:12

Quote:

Originally Posted by Beastie

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.

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.

Quote:

Originally Posted by Beastie

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.

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

Quote:

Originally Posted by Beastie

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.

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:

Use win2k installer to create the first primary partition and install win2k onto that.
Boot FreeBSD 6.X install CD, create second primary partition with it and install FreeBSD onto that.
Use FreeBSD's fdisk command to set active flag back to the first primary partition.
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.

Quote:

Originally Posted by oliverh

@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.

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

oliverh · #16 December 25th, 2009, 14:37

>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 ;-)

Beastie · #17 December 25th, 2009, 15:54

Quote:

Originally Posted by mickey

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.

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.

Beastie · #18 December 25th, 2009, 16:02

Quote:

Originally Posted by oliverh

something like the 'crappy' sysinstall

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?

oliverh · #19 December 25th, 2009, 16:19

>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.

mickey · #20 December 25th, 2009, 23:46

Quote:

Originally Posted by Beastie

Why do you do that? Doesn't FreeBSD's default boot manager work well?

Because:

Win2k already comes with a bootloader, whether you use it, or install a second one.
It nicely integrates into the boot menu
I always hated that raw "F1 ... F2 ..." screen. NDOS converter on my 8 bit ATARI had more style

Erratus · #21 December 25th, 2009, 23:52

I like to remember that this warning does not show on 7.2-RELEASE. It is new on 8.0-RELEASE systems.

mickey · #22 December 25th, 2009, 23:55

Quote:

Originally Posted by Erratus

I like to remember that this warning does not show on 7.2-RELEASE. It is new on 8.0-RELEASE systems.

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.

Erratus · #23 December 26th, 2009, 00:08

May be this thread is related to this MBR problem?

http://forums.freebsd.org/showthread.php?t=9524

mickey · #24 December 26th, 2009, 10:21

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?

oliverh · #25 December 26th, 2009, 12:31

Quote:

Originally Posted by mickey

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.

http://lists.freebsd.org/pipermail/f...ch/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/...eebsd-8-0-rc1/

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Disk label inconsistencies	jaymax	General	0	October 12th, 2009 01:03
du and df don't match with used space.	bones18	General	5	August 6th, 2009 14:02
Label for provider * is ufsid/*	nickolas	Installing & Upgrading	1	April 24th, 2009 11:35
How to correctly match broadcast packets with ipfw?	gelraen	Firewalls	1	April 6th, 2009 16:18
[GEOM] How to scan pending BIOs queue for given geom-provider?	zuborg	FreeBSD Development	0	January 27th, 2009 17:40