Re: old snapshot install images?

just for an update: apparently this was buggy BIOS and the BIOS update did fix it. The curious fact was that the gptzfsboot INT13 calls were failing, while pmbr INT13 calls were doing OK also the usb stick boot had no apparent problems.

rgds,
toomas


> On 3. mai 2017, at 21:53, Toomas Soome <tsoome_at_me.com> wrote:
> 
>> 
>> On 3. mai 2017, at 21:23, Michael W. Lucas <mwlucas_at_michaelwlucas.com <mailto:mwlucas_at_michaelwlucas.com>> wrote:
>> 
>> On Wed, May 03, 2017 at 09:11:05PM +0300, Toomas Soome wrote:
>>> 
>>>> On 3. mai 2017, at 21:06, Michael W. Lucas <mwlucas_at_michaelwlucas.com> wrote:
>>>> 
>>>> On Wed, May 03, 2017 at 08:03:21PM +0300, Toomas Soome wrote:
>>>>> There was many issues fixed step by step and some fixes for particular problem did reveal next one (at least in some systems), and indeed, it can cause some problems if you are caught in middle of updates. From my point of view, the most important question is if the current “current” is ok:)
>>>> 
>>>> 
>>>> Agreed 500%.
>>>> 
>>>> The latest snapshot is NOT ok.
>>>> 
>>> 
>>> What is the error there?
>> 
>> 
>> error 1
>> error 1
>> gptzfsboot: error 1 lba 4294967288
>> gptzfsboot: error 1 lba 1
>> gptzfsboot: no ZFS pools located, can't boot
>> 
>> My first thought was that the BIOS was looking at a different drive,
>> not the SATADOMs, so I disabled booting from all the spinning drives
>> in the BIOS.
>> 
>> On a related note: my script at http://www-old.michaelwlucas.com/zm.sh <http://www-old.michaelwlucas.com/zm.sh> <http://www-old.michaelwlucas.com/zm.sh <http://www-old.michaelwlucas.com/zm.sh>>
>> also gives the same error at boot.
>> 
> 
> well, yea, i know what it is. sigh. Welcome to the x86 hell.
> 
> error 1 is: Invalid command. And it is resulting firstly from drvsize() (the lone “error 1” messages) and then from drvread(). Now the question is, did you do the install from usb stick or cd, and has this system booted fbsd from the disk before?
> 
> The question is up because, the boot2 is only using INT13 extended read (INT13 EAX=0x4200) and INT13 EAX=0x4800 to get disk size; if the read is now getting error but was working before, it is pointing towards the error from 0x4800 (drvsize) is triggering the error with read - meaning we should probably attempt the disk reset on error.
> 
> As an first take on possible fix, I think we need to address the drvsize() to get size from INT13 0x800 as biosdisk.c bd_int13probe() does, and reset the disk on error. And if this is not enough, then check further.
> 
> However, since you have the system to test with, the testing is all on you;) So if you are up to the task, poke me in private (mail or irc) and we can work it out - no need to kill the list with all that noise;)
> 
> rgds,
> toomas 
> 
> _______________________________________________
> freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org <mailto:freebsd-current-unsubscribe_at_freebsd.org>"