trace for zfs panic mounting fs after crash with RC2

[Gerrit Kühn]

On Thu, 12 Nov 2009 09:26:30 +0100 Gerrit Kühn
<gerrit at pmp.uni-hannover.de> wrote about Re: trace for zfs panic mounting
fs after crash with RC2:

AB> Perhaps some of the links on the following post on zfs-discuss may
AB> help:
AB> http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg26704.html

GK> Interesting stuff, thanks.
GK> At a first glance I do not see an easy way to roll back my pool to a
GK> slightly previous (consistent) state, but all the posts state that it
GK> is possible. I guess I have to dive into this a bit deeper. "zpool
GK> clear -F" definitely would be the easier-to-use solution.

AB> Another option would be to boot from OpenSolaris LiveCD that
AB> contains latest zfs changes, import your pool there, fix, export
AB> and then re-import it on FreeBSD. Make sure you don't upgrade your
AB> pool while running OpenSolaris.

GK> Uh, yes, not really an option in this case, I guess. Unless I buy an
GK> additional external CD drive and stuff. But thanks for the hint,
GK> anyway. I will have a look around how difficult it is to get recent
GK> OpenSolaris on a USB stick...

Just to get this documented:
I was not able to get OSL on a USB medium since you need a special tool
for putting an image on a stick that rungs under Solaris ->
checken-egg-problem.
I borrowed an external usb cd drive and downloaded the latest osl (131)
from grunix. grub came up fine, selecting Solaris led to some dots on the
screen (obviously the kernel being loaded), then there was a block screen
with a blinking cursor, after some time the system rebooted.
I added -v to boot the kernel and got as far as Sun's Copyright, then it
hang again, rebooting some time later.
I added -k -d to activate the kernel debugger and managed to follow what
it is actually doing... well, after coming up with the cpu, OSL tried to
activate hyperthreading, which is not supported by the cpu, and bang...
After knowing what is going wrong, it was relatively easy to find the
problem on the web. My system has a VIA NANO processor, which supports
64bit, but no HT. OSL obviously supposes that any cpu not being and AMD
and having 64bit can support ht, too. The bug is there as long as the nano
processor exists (first reports in 2008), but obviously unfixed. :-(
I changed grub's boot line to load the 32bit OSL instead. This comes up
fine. I could only boot textmode or vesa, otherwise the system does not
recognize my onboard graphics. After googleing the default login and
default root account (why don't they display this on the login prompt?) I
could login, hat my zpool recognized and could import/export it without
any hassle.
After this the pool worked fine in FreeBSD again. One thing I noted is
that the first disk changed its name from label/disk-0 back to da0 in the
pool, although there still is a glabel on it. I don't know why this
happened nor how to get back do use the glabel on this disk, but it seems
to work anyway.
The whole issue took me several attempts and at least 4 hours of work
altogether (that's why I want to document it here to save other people
this time :-). I would really love to see these fixing features imported in
FreeBSD as soon as possible.
BTW: I did not even have to specify the -F option when importing the pool.
So maybe OSL is also more clever about what to do with inconsistent ZIL
states...


cu
  Gerrit