> On 8. veebr 2017, at 14:51, Ronald Klop <ronald-li...@klop.ws> wrote:
> On Wed, 08 Feb 2017 13:40:25 +0100, Thomas Sparrevohn
> <thomas.sparrev...@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?
>> Would the photos of the screen help?
> Everything helps.
> NB: please keep the mailinglist in the address list. There are more
> knowledgeable people there.
>> -----Original Message-----
>> From: Ronald Klop [mailto:ronald-li...@klop.ws]
>> Sent: 08 February 2017 12:27
>> To: FreeBSDfirstname.lastname@example.org; Thomas Sparrevohn
>> Subject: Re: gptzfsboot trouble
>> On Tue, 07 Feb 2017 17:08:44 +0100, Thomas Sparrevohn
>> <thomas.sparrev...@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?
>> 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.
> email@example.com mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"