Date: Fri, 2 Aug 2013 19:34:14 +0200 (CEST) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: J David <j.david.lists@gmail.com> Cc: freebsd-stable@freebsd.org Subject: Re: Problem with zfsloader on 9.2-BETA2 Message-ID: <alpine.BSF.2.00.1308021850420.90799@mail.fig.ol.no> In-Reply-To: <CABXB=RQWU2MkTDduJNFxgou3P6Jxy4PCThZ1-PnG=o9168uNHg@mail.gmail.com> References: <CABXB=RRhVDdKCidwnrji1qR41Rx7uvs2Lx1ZPF1FREOHcnm5bg@mail.gmail.com> <alpine.BSF.2.00.1307311107240.1327@mail.fig.ol.no> <CABXB=RR7E2s5GU29ZgU1hBk4MqkvrO95-RBg4TE6ahozP6KmCg@mail.gmail.com> <alpine.BSF.2.00.1308020803090.90799@mail.fig.ol.no> <CABXB=RQWU2MkTDduJNFxgou3P6Jxy4PCThZ1-PnG=o9168uNHg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --2055831798-2028791881-1375462410=:90799 Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT Content-ID: <alpine.BSF.2.00.1308021857121.90799@mail.fig.ol.no> On Fri, 2 Aug 2013 11:31-0400, J David wrote: > On Fri, Aug 2, 2013 at 2:36 AM, Trond Endrestøl <Trond.Endrestol@fagskolen.gjovik.no> wrote: > > > I'll try the 8.4-R -> 9.2-BETA2 route later this afternoon, and avoid > > updating the boot blocks with the ones from 9.2-BETA2. That leaves the > > raidz2 configuration unexplored. I figured the easiest way would be to copy the boot blocks from the 8.4-R BE to da0p1 and da1p1, and let the bootfs property remain pointing to the 9.2-BETA2 BE. The 8.4-R stuff showed no problems booting the 9.2-BETA stuff. > Thanks for looking into this. Is there anything you can think of that > I can do to help establish what is happening on this system? > > If there is a way to e.g. debug zfsloader to see what exactly it is > doing and where it goes awry, I sadly do not know what it is. :( You could put the line verbose_loading="YES" in /boot/loader.conf or in /boot/loader.conf.local if zfsloader is lucky enough to read those files. You can get the pool's guid by running: zpool get guid data If you manage to get to zfsloader's OK prompt, you can use the show command and see what zfsloader has gathered so far. If you are lucky, vfs.zfs.boot.primary_pool should be the same value as shown by the zpool get command above. You could also try verbose booting of the kernel. Maybe that can give some clues. Try these suggestions with the currently working/booting system. It would be a good thing to run smartctl on your drives if you haven't already done so. Maybe the S.M.A.R.T. statistics will be helpful. Install sysutils/smartmontools to get smartctl (and smartd). In another thread it was suggested to try zpool scrub from the lastest illumos or nexenta releases. Maybe it's possible to scrub a read-only pool, if only to find out what's wrong. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ --2055831798-2028791881-1375462410=:90799--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1308021850420.90799>