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"Received on Wed Feb 08 2017 - 13:52:53 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:10 UTC