gptzfsboot trouble

Wed Feb 8 14:52:53 UTC 2017

The disk is small 320GB but I have tried on a vanilla 600GB drive - same
issue - as a matter of fact I have tried on all 5 SATA drives - but I
suspect that BIOS could be an issue but I have not seen any updates for
years (old machine) 

I have tried with single drive pools on both 600GB drive and 320GB drive -
same issue - I wonder if it could be a memory error - I think I have an
original resource CD somewhere would make sense to try a diagnostics from
that 

-----Original Message-----
From: owner-freebsd-current at freebsd.org
[mailto:owner-freebsd-current at freebsd.org] On Behalf Of Toomas Soome
Sent: 08 February 2017 13:18
To: FreeBSD Current <FreeBSD-current at freebsd.org>
Subject: Re: gptzfsboot trouble

> On 8. veebr 2017, at 14:51, Ronald Klop <ronald-lists at klop.ws> wrote:
> 
> On Wed, 08 Feb 2017 13:40:25 +0100, Thomas Sparrevohn
<Thomas.Sparrevohn at btinternet.com> wrote:
> 
>> 
>> The bug in the bugzilla could be related - what is weird is I have 
>> been running this setup for years without issues - which I guess just 
>> shows how good ye'ol FreeBSD still is ;-) Tried to run through the 
>> svn log but could not immediately see anything that seemed to be 
>> related
> 
> I was triggered on that bugzilla issue because of the wrong lba number.

I would start from carte blanche.

1. extract/write down the GPT header content;  especially
important/interesting ones are alternate LBA for backup label location (and
therefore the disk end), the sector size used by GPT.

2. verify we do get the same sector size used with BIOS  INT13 and if we can
actually read the last sectors. This one is with catch - it implies some
coding with gptzfsboot just to try to extract the information, fortunately
the BIOS interface is simple enough to use and it should not be too hard:)

Based on the results, we can try to figure out what really is happening
there and why things break down.

One possible hypothesis is: as you wrote, your disk is 3TB; now it *may* be
the actual BIOS INT13  interface to address higher sectors is just buggy,
and it just can be so that the zfsloader binary is stored towards the disk
end in case of zfs and therefore revealing the issue.

Another way to verify this hypothesis is to create separate (smaller) zroot
partition at the beginning of the disk. Having older system sort of points
towards the possibility.

Another thing - have you checked for BIOS updates? 

rgds,
toomas

> 
>> Would the photos of the screen help?
> 
> Everything helps.
> NB: please keep the mailinglist in the address list. There are more
knowledgeable people there.
> 
> Ronald.
> 
> 
>> -----Original Message-----
>> From: Ronald Klop [mailto:ronald-lists at klop.ws]
>> Sent: 08 February 2017 12:27
>> To: FreeBSD-current at freebsd.org; Thomas Sparrevohn 
>> <Thomas.Sparrevohn at btinternet.com>
>> Subject: Re: gptzfsboot trouble
>> 
>> On Tue, 07 Feb 2017 17:08:44 +0100, Thomas Sparrevohn
<Thomas.Sparrevohn at btinternet.com> wrote:
>> 
>>> Hi all
>>> 
>>> 
>>> Last week I decided to upgrade my FreeBSD installation - it's been a 
>>> while (September 16 was last time). Unfortunately CURRENT does not 
>>> boot and cash in a weird way. Both 11-RELEASE and 12 CURRENT boot 
>>> loader seems to attempt to read blocks that exceeds the physical disk.
>>> Initially I through it was a hard disk error - but after a "oh"
>>> experience I realised that the
>>> "gptzfsboot: error 4 lba 921592" is actually beyond the physical 
>>> boundaries of the disk (300GB disk). In order to rule out different 
>>> options - I installed a vanilla 11-RELEASE on the 300G with a simple 
>>> stripe - it also gives the error but does boot - the LBA of the 
>>> error is slightly different on 11 CURRENT and comes up with LBA 
>>> 921600
>>> 
>>> 
>>> I have scanned all the disks for physical faults and there seems to 
>>> be none and I have tried doing a single disk installation on each 
>>> disk - they give the same error - Does anybody have any idea? 
>>> Included Photos as sometimes it get through to the actual boot menu 
>>> but then crash in another place
>>> 
>>> 
>>> I have some images - but they are 2 bit for the mailing list ;-)
>> 
>> 
>> Can it be related to this issue?
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=144234
>> 
>> Would be nice if you tell more about the system. CPU? dmesg?
>> The 11-RELEASE did that boot from the same disk? In the mentioned issue
there is the case that gptzfsboot does recognize a secondary disk (can be
configured as mirror), but not the first.
>> 
>> As you say UFS works, the bug might be in the gptzfsboot code, because
that is not used for UFS.
>> 
>> Regards,
>> Ronald.
> _______________________________________________
> freebsd-current at freebsd.org mailing list 
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"

_______________________________________________
freebsd-current at freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"