Date: Wed, 20 Jun 2012 07:44:57 -0400 From: John Baldwin <jhb@freebsd.org> To: "Andrey V. Elsukov" <ae@freebsd.org> Cc: src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r237294 - user/ae/bootcode/sys/boot/i386/pmbr Message-ID: <201206200744.57808.jhb@freebsd.org> In-Reply-To: <201206200829.q5K8TPcK028907@svn.freebsd.org> References: <201206200829.q5K8TPcK028907@svn.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, June 20, 2012 4:29:25 am Andrey V. Elsukov wrote: > Author: ae > Date: Wed Jun 20 08:29:24 2012 > New Revision: 237294 > URL: http://svn.freebsd.org/changeset/base/237294 > > Log: > In case when we have damaged several first sectors, GEOM_PART_GPT class > will not detect GPT even if backup GPT header is ok. To recover we should > write PMBR to the LBA 0. But we can't use `gpart bootcode` command until > GPT is detected and geom created. We can dd(8) /boot/pmbr image and > kernel will be able detect GPT. But our PMBR image contains only empty > partition entries and our loader can't detect GPT when it hasn't the > partition record with type PMBR. > > Add one partition record to the PMBR image. It covers all space after > the LBA 0. It is better to have one partially correct record, than > have nothing. This latter part is not true. :( boot1 has a hardcoded partition in it (for use in dangerously dedicated mode). This has a mixed history. At one point the table entry it used caused certain SCSI BIOSes to crash due to a divide by zero (the SCSI BIOS read the MBR to try to guess what C/H/S geometry the rest of the system was expecting). I think having a hardcoded entry here can only really result in problems. I would rather you add some sort of 'restore' functionality to gpart that allowed it to build a PMBR 'from scratch' with a proper partition entry than to resort to this hack. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201206200744.57808.jhb>