Date: Fri, 20 Nov 2020 09:28:47 -0500 From: mike tancsa <mike@sentex.net> To: "Bjoern A. Zeeb" <bz@FreeBSD.org> Cc: netperf-admin@FreeBSD.org, netperf-users@FreeBSD.org, Mateusz Guzik <mjguzik@gmail.com> Subject: Re: zoo reboot Friday Nov 20 14:00 UTC Message-ID: <dc8fed75-0262-c614-3292-6b8ce5addcfc@sentex.net> In-Reply-To: <d2ffd0f1-1dd8-dc6b-9975-93f20d7974a4@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 :( At 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 ? ---Mike On 11/20/2020 9:09 AM, mike tancsa wrote: > Hmm, not off to a good start. 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=00000000 err=00000000 efl=00010246 > eip=00008974 > eax=00000001 ebx=00000000 ecx=00000000 > edx=00000000 > esi=00000000 edi=00000000 ebp=0008de38 > esp=0008ddd0 > cs=002b ds=0033 es=0033 fs=0033 gs=0033 > ss=0033 > cs:eip=f7 35 90 9d 00 00 85 f6-74 05 89 3e 89 5e 04 > 89 > c2 e9 cc 00 00 00 66 c7-45 ea 00 00 89 d8 c1 > e8 > ss:esp=00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 > 00 > 00 00 00 00 00 00 00 00-00 00 00 00 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. WRT to zfs >> backups, I want to redo how that works to something more useful using >> better incremental sends. Something like zrepl works well. I will take >> a look at that next week or so >> >> ---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,python3x,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 we >>>> missed. >>> Mike: >>> >>> - isc-dhcp (or similar kind of flavour if you prefer something else >>> these days) would be beneficial I think. >>> >>> - micro_proxy is run from inted in order to allow test machines to >>> reach package repositories, etc. (as per motd on zoo). >>> >>> - bind is running serving a local forward/reverse zone in >>> addition to /etc/hosts; not sure if it is needed or helps or is stale? >>> >>> - pigz for your zfs backups again? >>> >>> I didn’t notice anything else so far. >>> >>> - smartmontools in case you are monitoring disks? >>> >>> >>> >>> /bz >>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?dc8fed75-0262-c614-3292-6b8ce5addcfc>