On 08.08.2013 01:46, Peter Wemm wrote:
> I've run into this before. Our loader and kernel are excessively
> pedantic about this.
>
> gpart create -s gpt -n ...
>
> leads to bootblocks or loader or kernel rejecting it if it is < 128,
> and some of the bootblocks reject it if it is > 128.
>
> As
On Wed, Aug 7, 2013 at 11:59 AM, J David wrote:
> On Wed, Aug 7, 2013 at 4:08 AM, Andriy Gapon wrote:
>> Could you please hack gpt_checkhdr() in sys/boot/common/part.c to print all
>> the
>> relevant values for this check and try bootparttest again?
[..]
> So it looks like this check is tripping
On Wed, Aug 7, 2013 at 6:49 AM, Andrey V. Elsukov wrote:
> can you please dump first 34 blocks from da2 and send to me?
Will send off-list.
> Also, it is interesting, what tool did you use for partitioning?
Unfortunately I'm not sure. This pool may have been created on
Solaris. Seems like may
On Wed, Aug 7, 2013 at 4:08 AM, Andriy Gapon wrote:
> Could you please hack gpt_checkhdr() in sys/boot/common/part.c to print all
> the
> relevant values for this check and try bootparttest again?
Your wish is my command:
--- common/part.c.orig 2013-08-05 19:00:49.536868414 +
+++ common/pa
On 07.08.2013 01:26, J David wrote:
> On Tue, Aug 6, 2013 at 5:53 AM, Andrey V. Elsukov wrote:
>> looking to your `zfs status` output and this, we can see, that GPT
>> wasn't detected on most of disks. Can you try to boot with this loader:
>> http://people.freebsd.org/~ae/zfsloader
>> It's from 10
on 07/08/2013 00:26 J David said the following:
> $ sudo ./bootparttest da2
> GEOM provider "da2" opened
> Mediasize: 1000204886016 Bytes (1953525168 sectors)
> Sectorsize: 512 Bytes
> da2: read 1 blocks from the offset 0 [+0]
> da2: read 1 blocks from the offset 1 [+0]
> ptable_open: PMBR detected
On Tue, Aug 6, 2013 at 5:53 AM, Andrey V. Elsukov wrote:
> looking to your `zfs status` output and this, we can see, that GPT
> wasn't detected on most of disks. Can you try to boot with this loader:
> http://people.freebsd.org/~ae/zfsloader
> It's from 10-CURRENT and was build with -DPART_DEBUG,
On 06.08.2013 13:53, Andrey V. Elsukov wrote:
>> disk5: BIOS drive H:
>> disk6: BIOS drive I:
>> disk7: BIOS drive J:
>
> Hi,
>
> looking to your `zfs status` output and this, we can see, that GPT
> wasn't detected on most of disks. Can you try to boot with this loader:
> http:/
On 06.08.2013 03:54, J David wrote:
> OK lsdev -v
> cd devices:
> disk devices:
> disk0: BIOS drive C:
> disk0p1: FreeBSD boot64KB
> disk0p2: FreeBSD swap2048MB
> disk0p3: FreeBSD ZFS 28GB
> disk1: BIOS drive D:
> disk1p1: FreeBSD boot
On Mon, Aug 5, 2013 at 8:01 PM, J David wrote:
> I should add that this is indeed the correct guid for the pool:
>
> $ zpool get guid
> NAME PROPERTY VALUE SOURCE
> data guid 2022708996989799150 default
After a full make buildworld installworld, I finally got the revised output:
ZFS: c
On Mon, Aug 5, 2013 at 7:54 PM, J David wrote:
> OK show vfs.zfs.boot.primary_pool
> 2022708996989799150
I should add that this is indeed the correct guid for the pool:
$ zpool get guid
NAME PROPERTY VALUE SOURCE
data guid 2022708996989799150 default
Thanks!
__
On Sat, Aug 3, 2013 at 3:16 PM, Andriy Gapon wrote:
> Very unusual. Would you be able to try 9.2 zfsloader again?
Surely.
> I would like to see values of loaddev, currdev and vfs.zfs.boot.primary_pool
> loader variables (if any are set). These can be obtained using 'show' command
> at loader p
on 31/07/2013 10:49 J David said the following:
> But the system still wouldn't boot, moving on to:
>
> ZFS: can't find pool by guid
> ZFS: can't find pool by guid
>
> We got around this by interrupting the stage1 loader and invoking
> data/root:/boot/zfsloader.old instead. Then we moved the 9.2
On Fri, 2 Aug 2013 11:31-0400, J David wrote:
> On Fri, Aug 2, 2013 at 2:36 AM, Trond Endrestøl
> wrote:
>
> > I'll try the 8.4-R -> 9.2-BETA2 route later this afternoon, and avoid
> > updating the boot blocks with the ones from 9.2-BETA2. That leaves the
> > raidz2 configuration unexplored.
I
On Fri, Aug 2, 2013 at 2:36 AM, Trond Endrestøl
wrote:
> I'll try the 8.4-R -> 9.2-BETA2 route later this afternoon, and avoid
> updating the boot blocks with the ones from 9.2-BETA2. That leaves the
> raidz2 configuration unexplored.
Thanks for looking into this. Is there anything you can think
On Wed, 31 Jul 2013 12:12-0400, J David wrote:
> On Wed, Jul 31, 2013 at 5:20 AM, Trond Endrestøl
> wrote:
> > I'm curious as to why you use da?p1 as the freebsd-zfs partitions.
>
> Those are whole-disk partitions.
>
> > Where does the freebsd-boot partition reside? da?p2?
>
> Only the log and
On Wed, Jul 31, 2013 at 11:36 PM, Shane Ambler wrote:
> I think that 8M partition looks weird. It looks like a leftover from a
> previous config?
We leave some space at the end of drives in case we need to change
drive vendors. Sometimes vendor A's drives are a few sectors smaller
than vendor B'
On 01/08/2013 01:42, J David wrote:
=>34 1953525101 da2 GPT (931G)
34 222 - free - (111k)
256 19535084951 freebsd-zfs (931G)
1953508751 163849 !6a945a3b-1dd2-11b2-99a6-080020736631 (8.0M)
da3 - da7 are identical to da2.
So m
On Wed, Jul 31, 2013 at 5:20 AM, Trond Endrestøl
wrote:
> I'm curious as to why you use da?p1 as the freebsd-zfs partitions.
Those are whole-disk partitions.
> Where does the freebsd-boot partition reside? da?p2?
Only the log and cache disks have boot and swap partitions.
> What does the "gpar
On Wed, 31 Jul 2013 03:49-0400, J David wrote:
> In order to test ZFS on the upcoming 9.2 release, we upgraded a
> non-production 8.4 root-on-ZFS fileserver to 9.2-BETA2.
>
> The result was a non-bootable system. The first problem was
> gptzfsboot, but that was our fault? it never got upgraded w
In order to test ZFS on the upcoming 9.2 release, we upgraded a
non-production 8.4 root-on-ZFS fileserver to 9.2-BETA2.
The result was a non-bootable system. The first problem was
gptzfsboot, but that was our fault… it never got upgraded when we
switched to feature flags. So some time with the 8
21 matches
Mail list logo
