Re: fdisk(8) no longer capable of altering geometry

My little follow-up to this issue. This bug is quite critical on 
products using bsdinstaller such as FreeSBIE or pfSense. I heard rumours 
that PC-BSD also encounter this problem and had to workaround it by 
sysinstall.

Can somebody please take a look at it?

Thanks,
Dario

Chris Pressey wrote:
> [this is a follow-up to / correction of my post to geom_at_ a few days ago,
> to which there was no reply]
> 
> Hello,
> 
> It appears that fdisk(8) is no longer capable of altering the geometry
> of a disk.  (By which I mean, the kernel's idea of the BIOS'es idea of
> the geometry, of course.)  I'd find it reassuring to know whether or not
> anyone else is seeing the same behaviour, before I go the official route
> and file a PR.
> 
> Initially I thought that this failure case was only for uninitialized
> disks, but I have tried further tests and I can't get fdisk(8) to change
> the geometry in any of the cases.  These cases are:
> 
> a. uninitialized, totally blank disk (dd if=/dev/zero of=/dev/ad1 ...)
> b. initialized disk with FreeBSD (or any other OS) installed on it
> c. same as b, but with its root partition mounted on /mnt
> d. the disk containing the currently booted FreeBSD system
>    (mounted on /, of course)
> 
> In each of these cases, I tried a sequence like the following:
> 
>   fdisk -BI ad1
>   fdisk -u ad1
>   <when asked if I want to change "our idea of what the BIOS thinks",
>    say yes, and plug in different but compatible values for cylinders,
>    heads, and sectors/track>
>   <when asked if I want to write the new partition table, say yes>
>   fdisk ad1
>   <observe that the geometry hasn't changed>
> 
> The behaviour I see is, in summary:
> 
> a & b: fdisk issues the warning "fdisk: Geom not found" which presumably
>        refers to the fact that there is no GEOM MBR provider for that
>        disk. It then falls back to the legacy behaviour of raw-writing
>        the partition table into sector zero of the disk.  This does not,
>        however, trigger an update of the kernel's idea of the geometry.
> 
> c & d: no "Geom not found" warning, but no change in geometry either.
> 
> I don't see this behaviour on DragonFly; cases a and b work as you would
> logically expect (as they worked in 4.x, AFAIR, but I have not yet
> tested this) where the geometry does get changed, and subsequent runs of
> fdisk report the changed geometry.
> 
> In cases c & d, the behaviour is the same as FreeBSD - nothing changes. 
> This is not too surprising, since the disk _is_ in use - but an error
> message would probably make more sense.
> 
> This bug is one of the few remaining things standing in the way of
> porting the BSD Installer to FreeBSD.  Without some way of altering the
> the geometry, it can't install onto a system whose BIOS misreports the
> disk geometry.
> 
> My analysis of the problem can be found in my previous post to geom_at_,
> but to sum it up: I think fdisk needs to inform GEOM somehow that the
> geometry should be changed.  It might need to trigger the creation of a
> GEOM MBR provider for the disk before it does so; but I'm not certain of
> any of this, since my knowledge of GEOM is slim at best.
> 
> Hopefully someone more familiar with GEOM and such under -CURRENT is
> listening and can shed more light on this problem and/or provide a
> workaround and/or explain how I'm wrong and show me the right way to do
> what I'm trying to do (change geometry) in -CURRENT.
> 
> Thanks for your time,
> -Chris
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 


-- 
Dario Freni (saturnero_at_freesbie.org)
FreeSBIE developer (http://www.freesbie.org)
GPG Public key at http://www.saturnero.net/saturnero.asc