From owner-freebsd-current@FreeBSD.ORG Wed Jun 27 12:45:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1EBCD106566B; Wed, 27 Jun 2012 12:45:50 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [IPv6:2a02:6b8:0:602::1]) by mx1.freebsd.org (Postfix) with ESMTP id 26D2A8FC0A; Wed, 27 Jun 2012 12:45:49 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id 665711241787; Wed, 27 Jun 2012 16:45:47 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340801147; bh=PVgBaSsktQdbS9+UkEnby+reOAT1fMAQ04WXbr4hIs8=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=WeM8tCijMnGCFgFD8k2AbZ0wdOte7bbZ5so1L1VokQSW2RwIDw1cu1tgyu8hJ/hU8 v7PK20PKKYWxd4iWGQunHo/Oi0tP0bUY1Bhu3TIYklgh38W0FKgOUqarJ4Eh5CQxxQ WAWuu75zbA6IfDe/QtdYV3aAyZ4FSHdmAUPwi69A= Received: from smtp4.mail.yandex.net (localhost [127.0.0.1]) by smtp4.mail.yandex.net (Yandex) with ESMTP id ECC265C03D0; Wed, 27 Jun 2012 16:45:46 +0400 (MSK) Received: from ns.kirov.so-ups.ru (ns.kirov.so-ups.ru [178.74.170.1]) by smtp4.mail.yandex.net (nwsmtp/Yandex) with ESMTP id jjF8mO0D-jkFKHr2u; Wed, 27 Jun 2012 16:45:46 +0400 X-Yandex-Rcpt-Suid: jhb@freebsd.org X-Yandex-Rcpt-Suid: freebsd-current@freebsd.org X-Yandex-Rcpt-Suid: freebsd-hackers@freebsd.org X-Yandex-Rcpt-Suid: dfr@freebsd.org X-Yandex-Rcpt-Suid: avg@freebsd.org X-Yandex-Rcpt-Suid: pjd@freebsd.org X-Yandex-Rcpt-Suid: marcel@freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1340801146; bh=PVgBaSsktQdbS9+UkEnby+reOAT1fMAQ04WXbr4hIs8=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=gDSsrrIPivDByUjfLpQ8xPlKgqY0xsGvIUNufvG79RPHNDK02zD1RV3e4TOjL3Rez ZQJkOrPHZ95rj7SfBF5fVvs+1TIPwNuVYy6jxHlVC8Pu60gf/IMYdUkgYGMV7dO6vx MbknUl29y9liE5Kqtk+m5n2TRZnD2A+Ju0k+p2mc= Message-ID: <4FEB0079.7050008@yandex.ru> Date: Wed, 27 Jun 2012 16:45:45 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.5 (FreeBSD/20051231) MIME-Version: 1.0 To: John Baldwin References: <4FE9B01C.30306@yandex.ru> <201206261337.11741.jhb@freebsd.org> <4FEA910C.4090305@yandex.ru> <201206270807.23347.jhb@freebsd.org> In-Reply-To: <201206270807.23347.jhb@freebsd.org> X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , freebsd-hackers , Andriy Gapon , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2012 12:45:50 -0000 On 27.06.2012 16:07, John Baldwin wrote: >> • Check the Signature >> • Check the Header CRC >> • Check that the MyLBA entry points to the LBA that contains the GUID Partition Table >> • Check the CRC of the GUID Partition Entry Array >> If the GPT is the primary table, stored at LBA 1: >> • Check the AlternateLBA to see if it is a valid GPT >> If the primary GPT is corrupt, software must check the last LBA of the device to see if it has a >> valid GPT Header and point to a valid GPT Partition Entry Array." > > Right, we break the last rule. If you want to use a partition editor > that doesn't grok gmirror (because you are using another OS's editor), > to repair a GPT, it will do the wrong thing. When we are in the FreeBSD, our loader can detect that device size is lower than it see and it will work. When primary header is OK, then other OSes should work with this GPT. When it isn't OK, you just can't load other OS :) >>> As I said earlier, I do not think this is appropriate and that instead >>> gpart should have an appropriate 'recover' command to install just the pmbr on >>> a disk and also create a correct entry in the MBR if needed while doing so. >> >> gpart(8) is only one of several geom(8)' tools to manage objects of a GEOM class. >> It only sends control requests to the kernel. If GPT is not detected, >> there is no geom objects to manage. And we can't write bootcode with gpart(8). >> I think that adding such functions to the gpart(8) is not good. Maybe, >> the boot0cfg is the better tool for that. Also we still haven't any tool to >> install zfsboot. > > We can't write bootcode with gpart? What do you think the 'bootcode' command > does? `gpart bootcode -b` reads file, creates ioctl request and sends this data to the GEOM_PART class. GEOM_PART receives the control request, checks the data and writes it to the provider. `gpart bootcode -p` works like dd(1) and writes bootcode to the given partition. gpart(8) haven't any knowledge about specific partitioning scheme. > Also, there is no reason we can't have a 'recover' command that attempts to > recover a corrupted table including repairing the PMBR. gpart(8) already > generates a full PMBR when you use 'gpart create' to create a GPT even though > there isn't a GPT object yet. `gpart create` creates only ioctl control request to the GEOM_PART class. GEOM_PART class creates new GPT geom object and this objects writes PMBR and its metadata to the provider. -- WBR, Andrey V. Elsukov