From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1ciptr-0001dc-OW for mharc-grub-devel@gnu.org; Tue, 28 Feb 2017 17:05:39 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53177) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ciptp-0001br-7B for grub-devel@gnu.org; Tue, 28 Feb 2017 17:05:38 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cipto-0008Cz-1k for grub-devel@gnu.org; Tue, 28 Feb 2017 17:05:37 -0500 Received: from caffeine.csclub.uwaterloo.ca ([2620:101:f000:4901:c5c:0:caff:e12e]:57163) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ciptn-0008CP-U1 for grub-devel@gnu.org; Tue, 28 Feb 2017 17:05:35 -0500 Received: by caffeine.csclub.uwaterloo.ca (Postfix, from userid 20367) id 9CDDCC0086; Tue, 28 Feb 2017 17:05:34 -0500 (EST) Date: Tue, 28 Feb 2017 17:05:34 -0500 To: The development of GNU GRUB Subject: Re: grub-probe for nested BSD partition on Linux Message-ID: <20170228220534.GB31496@csclub.uwaterloo.ca> References: <2e48f17a-20d7-c9cb-2300-1bc5fec88f12@gmail.com> <20170228183141.GA31496@csclub.uwaterloo.ca> <15e78e1d-9d62-5598-dcf9-dca40f85c633@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <15e78e1d-9d62-5598-dcf9-dca40f85c633@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) From: lsorense@csclub.uwaterloo.ca (Lennart Sorensen) Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2620:101:f000:4901:c5c:0:caff:e12e X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:05:38 -0000 On Tue, Feb 28, 2017 at 09:50:27PM +0300, Andrei Borzenkov wrote: > 28.02.2017 21:31, Lennart Sorensen =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Tue, Feb 28, 2017 at 08:13:53PM +0300, Andrei Borzenkov wrote: > >> Sorry? vda7 is 256M, how can you suddenly pretend it is 2G? > >> > >> 10:~ # fdisk -l /dev/vda > >> Disk /dev/vda: 5 GiB, 5368709120 bytes, 10485760 sectors > >> Units: sectors of 1 * 512 =3D 512 bytes > >> Sector size (logical/physical): 512 bytes / 512 bytes > >> I/O size (minimum/optimal): 512 bytes / 512 bytes > >> Disklabel type: dos > >> Disk identifier: 0x882b18da > >> > >> Device Boot Start End Sectors Size Id Type > >> /dev/vda1 2048 2099199 2097152 1G 83 Linux > >> /dev/vda2 2099200 6293503 4194304 2G a6 OpenBSD > >> /dev/vda3 6293504 10485759 4192256 2G 5 Extended > >> /dev/vda5 6295552 6819839 524288 256M 83 Linux > >> /dev/vda6 6821888 7346175 524288 256M 83 Linux > >> 10:~ # fdisk -l /dev/vda2 > >> Disk /dev/vda2: 2 GiB, 2147483648 bytes, 4194304 sectors > >> Geometry: 16 heads, 63 sectors/track, 10402 cylinders > >> Units: sectors of 1 * 512 =3D 512 bytes > >> Sector size (logical/physical): 512 bytes / 512 bytes > >> I/O size (minimum/optimal): 512 bytes / 512 bytes > >> Disklabel type: bsd > >> > >> Slice Start End Sectors Size Type Fsize Bsize Cpg > >> a 2099200 2623488 524289 256M boot 0 0 0 > >> b 2099200 2623488 524289 256M unused 0 0 0 > >> c 2099200 6293503 4194304 2G unused 0 0 0 > >> d 0 10485215 10485216 5G unused 0 0 0 > >> > >> Partition table entries are not in disk order. > >=20 > > Well that does look mostly sane for an ancient BSD version. > >=20 >=20 > In case I was not clear. >=20 > BSD partition a is represented in Linux as /dev/vda7. grub-probe -t > compatibility_hints -d /dev/vda7 returns hd0,msdos2 which is obviously > wrong, because it refers to 2GB area on disk while partition /dev/vda7 > is just 256M. I would expect either hd0,msdos2,openbsd1 or nothing > depending on whether such nested partition is supported. Oh now I see what you mean. Hmm, that is an interesting problem. It seems FFS and UFS reserve either 1 or 8KB at the start for bootblock, which I suppose would save the disklabel from being overwritten if using one of those filesystems. The documentation does seem to say to always leave a gap before the first slice/partition in all cases. > > Slice a is the rootfs for BSD > >=20 > > Slice b should traditionally be swap, but appears to be unused here, > > and for some reason uses the same part of the disk as slice a, which > > does look odd. Maybe since the type is unknown, it doesn't matter. > >=20 > > Slice c is the whole partition containing the slices (vda2) > >=20 > > Slice d is the whole disk (vda), which apparently hasn't been used in > > BSD for a couple of decades now, if wikipedia can be trusted. > >=20 > > So if linux only bothers to count the partition with a type that isn'= t > > unused, then it probably makes sense. That appears to be what the > > partition parsing code does. > >=20 > > The start being the same as the start of vda2 does seem odd given it > > appears that you are supposed to leave space at the start (1 track > > recommended, or 64 sectors), and it appears the disklabel is at secto= r > > 1 (0 being the first), so it doesn't seem like having your filesystem > > start there would be safe unless the filesystem has reserved space at > > the start for such things. > >=20 >=20 > I just pressed 'b' in Linux fdisk and only change two partition sizes. = I > have no idea how fdisk choses partition start. Could be a bug in fdisk. I think fdisk's default is probably wrong in this case. Certainly if you create a slice and then decide to mkfs.ext2 on it, your disklabel is gone if you don't make the start offset a bit higher. --=20 Len Sorensen