The fdisk(8) utility, when called to update the MBR of a disk, asks you whether you want to change "our idea of that the BIOS thinks" (i.e. the in-core value) of the geometry of that disk. However, it never actually succeeds in doing that. This behaviour has been independently observed (also on recent -CURRENT) by Andrew Turner (FreeBSD SoC BSD Installer project.) The bug was first suspected due to consistent failure of the BSD Installer tool, which calls /sbin/fdisk to change the geometry of the user's disk. The same failure is seen in FreeBSD 6.x, indicating that the same bug is in all likelihood present in 6.x as well. Anecdotal evidence from a different source suggests it may be in 5.x as well, but this is less certain. Fix: Problem is probably in the GEOM layer, or in how fdisk(8) talks to the GEOM layer, but is not precisely known. How-To-Repeat: - As root, run "fdisk -u ad1" (or on whatever disk you like) - Tell fdisk(8) "yes, I'd like to change our idea of what the BIOS thinks (of the geometry of this disk)" - Give fdisk(8) any new geometry values you like - Be happy with this choice - Choose to write the new partition table - Get a "GEOM not found" error (optional) - Run "fdisk ad1" again and observe that the geometry hasn't changed.
Responsible Changed From-To: freebsd-bugs->freebsd-geom This is GEOM-related
Hello, this patch seems to fix the problems outlined in this pr. I am not sure if this is the "correct" fix but it does ineed work. This patch was given to me by Olavi Kumpulainen <olavi@ipunplugged.com> and he asked me to follow up to the PR if it worked. I've also sent this patch to 2 other parties with the same problems and they reported that this fixed their issues as well. --- fdisk.c=09Wed Oct 5 03:16:39 2005 +++ fdisk-patched.c=09Tue May 16 14:36:51 2006 @@ -750,6 +750,7 @@ =09char fbuf[BUFSIZ]; =09int i, fdw; +=09close(fd);=09/* Give the GEOM layer exclusive access to the disk */ =09grq =3D gctl_get_handle(); =09gctl_ro_param(grq, "verb", -1, "write MBR"); =09gctl_ro_param(grq, "class", -1, "MBR"); @@ -760,13 +761,15 @@ =09=09q++; =09gctl_ro_param(grq, "geom", -1, q); =09gctl_ro_param(grq, "data", secsize, buf); -=09q =3D gctl_issue(grq); +=09q =3D gctl_issue(grq); =09if (q =3D=3D NULL) { =09=09gctl_free(grq); +=09=09open_disk(u_flag); =09=09return(0); =09} =09warnx("%s", q); =09gctl_free(grq); +=09open_disk(u_flag); =09 =09error =3D pwrite(fd, buf, secsize, (sector * 512)); =09if (error =3D=3D secsize)
Sorry for the previous mungled patch. I'll provide a link to our CVS repo which has the patch: http://cvs.pfsense.com/cgi-bin/cvsweb.cgi/tools/patches/fdisk.c.diff?rev=1.1;content-type=text%2Fplain And in case the above gets mungled: http://tinyurl.com/nthtc
Here is an updated patch for this issue: http://cvs.pfsense.org/cgi-bin/cvsweb.cgi/tools/patches/RELENG_7_0/fdisk.c.diff or the tiny version: http://tinyurl.com/5gp6eu
AFAICT, the fdisk code skips to using pwrite to write the MBR if the MBR GEOM class fails (which it will do if an MBR does not exist), and should update the MBR info correctly anyway. I was however unsuccessful altering the geometry even with this patch. But the warning printed when geom_mbr fails is a bit confusing, since the write request might be successful anyway, so we should either just quell the warning, or make using geom_mbr work. -- Ulf Lilleengen
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped