Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 20 Nov 2020 17:04:19 +0100
From:      Mateusz Guzik <mjguzik@gmail.com>
To:        mike tancsa <mike@sentex.net>
Cc:        "Bjoern A. Zeeb" <bz@freebsd.org>, netperf-admin@freebsd.org, netperf-users@freebsd.org
Subject:   Re: zoo reboot Friday Nov 20 14:00 UTC
Message-ID:  <CAGudoHHNN8ZcgdkRSy0cSaPA6J9ZHVf%2BBQFiBcThrtQ0AMP%2BOw@mail.gmail.com>
In-Reply-To: <0ddec867-32b5-f667-d617-0ddc71726d09@sentex.net>
References:  <1f8e49ff-e3da-8d24-57f1-11f17389aa84@sentex.net> <2691e1fd-5a27-4dd0-2ef7-b1c06fd4e751@sentex.net> <A3934CD4-57C1-4215-99F2-9500CB9EDC7C@neville-neil.com> <5A5094BC-D417-4BA6-97E2-7CB522B51368@FreeBSD.org> <4ec6ed6f-b3b4-22ae-e1ec-93a46f3d88ea@sentex.net> <d2ffd0f1-1dd8-dc6b-9975-93f20d7974a4@sentex.net> <dc8fed75-0262-c614-3292-6b8ce5addcfc@sentex.net> <0ddec867-32b5-f667-d617-0ddc71726d09@sentex.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Oh, that's a bummer. I wonder if there is a regression in the boot
loader though.

Does the pool mount if you boot the system from a cd/over the network/whate=
ver?

On 11/20/20, mike tancsa <mike@sentex.net> wrote:
> Some progress. But now
>
>
> Consoles: internal
> video/keyboard
> BIOS drive C: is
> disk0
> BIOS drive D: is
> disk1
> BIOS drive E: is
> disk2
> BIOS drive F: is
> disk3
> BIOS drive G: is
> disk4
> BIOS drive H: is
> disk5
> BIOS drive I: is
> disk6
> BIOS drive J: is
> disk7
> BIOS drive K: is
> disk8
> zio_read error:
> 5
> zio_read error:
> 5
> zio_read error:
> 5
> ZFS: i/o error - all block copies
> unavailable
> ZFS: can't read MOS of pool
> zroot
> BIOS 615kB/1983396kB available
> memory
>
>
> FreeBSD/x86 bootstrap loader, Revision
> 1.1
> (Thu Nov 19 08:18:03 EST 2020
> mdtancsa@zoo.freebsd.org)
> ERROR: cannot open /boot/lua/loader.lua: invalid
> argument.
>
>
>
>
> Type '?' for a list of commands, 'help' for more detailed
> help.
> OK
>
>
> On 11/20/2020 9:28 AM, mike tancsa wrote:
>> I am wondering this is a problem with having the 2 SSD drives off the
>> LSI controller as part of the pool as vdev / meta data caches :(=C2=A0 A=
t
>> boot time I guess those are not seen yet ? Gonna have to make a trip to
>> the office to try and move those drives off the LSI controller and onto
>> the motherboard if possible to test out this theory and hopefully it
>> will boot. Anything else to try ?
>>
>> =C2=A0=C2=A0=C2=A0 ---Mike
>>
>> On 11/20/2020 9:09 AM, mike tancsa wrote:
>>> Hmm, not off to a good start.=C2=A0 This will take a little longer.
>>>
>>>
>>>
>>> ZFS: i/o error - all block copies
>>> unavailable
>>> ZFS: can't read MOS of pool
>>> zroot
>>> gptzfsboot: failed to mount default pool
>>> zroot
>>>
>>>
>>> FreeBSD/x86
>>> boot
>>>
>>>
>>> int=3D00000000=C2=A0 err=3D00000000=C2=A0 efl=3D00010246
>>> eip=3D00008974
>>> eax=3D00000001=C2=A0 ebx=3D00000000=C2=A0 ecx=3D00000000
>>> edx=3D00000000
>>> esi=3D00000000=C2=A0 edi=3D00000000=C2=A0 ebp=3D0008de38
>>> esp=3D0008ddd0
>>> cs=3D002b=C2=A0 ds=3D0033=C2=A0 es=3D0033=C2=A0=C2=A0=C2=A0 fs=3D0033=
=C2=A0 gs=3D0033
>>> ss=3D0033
>>> cs:eip=3Df7 35 90 9d 00 00 85 f6-74 05 89 3e 89 5e 04
>>> 89
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 c2 e9 cc 00 00 00 66 c7-45 ea 00 0=
0 89 d8 c1
>>> e8
>>> ss:esp=3D00 00 00 00 00 00 00 00-00 00 00 00 00 00 00
>>> 00
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00 00 00 00 00 00 00 00-00 00 00 0=
0 00 00 00
>>> 00
>>> BTX
>>> halted
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 11/19/2020 1:36 PM, mike tancsa wrote:
>>>> Thanks, I forgot about those :) I will add them of course.=C2=A0=C2=A0=
 WRT to zfs
>>>> backups, I want to redo how that works to something more useful using
>>>> better incremental sends.=C2=A0 Something like zrepl works well. I wil=
l take
>>>> a look at that next week or so
>>>>
>>>> =C2=A0=C2=A0=C2=A0 ---Mike
>>>>
>>>> On 11/19/2020 1:23 PM, Bjoern A. Zeeb wrote:
>>>>> On 19 Nov 2020, at 17:38, George Neville-Neil wrote:
>>>>>
>>>>>> On 19 Nov 2020, at 10:57, mike tancsa wrote:
>>>>>>
>>>>>>> On 11/19/2020 8:31 AM, mike tancsa wrote:
>>>>>>>> To upgrade to r367842. I will also be upgrading the installed pkgs
>>>>>>>>
>>>>>>> Also, with the pkg upgrade as so many are so very stale, its
>>>>>>> probably
>>>>>>> best to uninstall them all and then install what everyone needs /
>>>>>>> uses ?
>>>>>>>
>>>>>>> Below is the list of what is currently installed. I will kill those
>>>>>>> and
>>>>>>> install to start
>>>>>>>
>>>>>>> bash,curl,conserver-com,git,gmake,ipmitools,megacli,perl,pdksh,pyth=
on3x,rsync,screen,storcli,subversion,sudo,tmux,vim,zsh
>>>>>>>
>>>>>>>
>>>>>>> Is there anything else people want / need ?
>>>>>> I think our best bet is to "just do it" and then fault in whatever w=
e
>>>>>> missed.
>>>>> Mike:
>>>>>
>>>>> - isc-dhcp=C2=A0=C2=A0 (or similar kind of flavour if you prefer some=
thing else
>>>>> these days) would be beneficial I think.
>>>>>
>>>>> - micro_proxy=C2=A0=C2=A0 is run from inted in order to allow test ma=
chines to
>>>>> reach package repositories, etc. (as per motd on zoo).
>>>>>
>>>>> - bind=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is running ser=
ving a local forward/reverse zone in
>>>>> addition to /etc/hosts; not sure if it is needed or helps or is stale=
?
>>>>>
>>>>> - pigz=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 for your zfs backups again=
?
>>>>>
>>>>> I didn=E2=80=99t notice anything else so far.
>>>>>
>>>>> - smartmontools=C2=A0=C2=A0=C2=A0 in case you are monitoring disks?
>>>>>
>>>>>
>>>>>
>>>>> /bz
>>>>>
>


--=20
Mateusz Guzik <mjguzik gmail.com>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHHNN8ZcgdkRSy0cSaPA6J9ZHVf%2BBQFiBcThrtQ0AMP%2BOw>