zfs crash on FreeBSD 10.3
julian at freebsd.org
Tue Oct 18 06:06:07 UTC 2016
On 14/10/2016 6:31 PM, Trond Endrestøl wrote:
> On Fri, 14 Oct 2016 00:19-0700, Julian Elischer wrote:
>> I attempted to add a second partition to an existing FS pool in FreeBSD 10.3
>> and the result was a crash..
>> is there anyone out there with a scratch system (10.3) (or two spare drives)
>> who can show me this working?
>> Does it look familiar to anyone?
>> The drive 'boot0' is being used as the root drive, but we are in single user
>> mode, so its' read-only at this stage.
>> =============== cut-n-paste =============
>> [boot -s]
>> Trying to mount root from zfs:p8/image1 ...
>> Enter full pathname of shell or RETURN for /bin/sh:
>> PS1="# "
>> # ls /dev/gpt
>> boot0 boot1
>> # zpool attach -f p8 gpt/boot0 gpt/boot1
> Do you really need to force zpool to attach the second partition?
> What happens if you omit the -f flag?
from memory, it does nothing
I can't test it now but I know the example I saw on the internet gave
'-f , and when I tried to leave it out,
it didn't work. I vaguely remember that it complained about the
filesystem being in use.
I will try it again some time when I have the setup running and get
back to you.
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 1; apic id = 01
>> fault virtual address = 0x50
>> fault code = supervisor read data, page not present
>> instruction pointer = 0x20:0xffffffff81717063
>> stack pointer = 0x28:0xfffffe0169bfc640
>> frame pointer = 0x28:0xfffffe0169bfc9a0
>> code segment = base 0x0, limit 0xfffff, type 0x1b
>> = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process = 3 (txg_thread_enter)
>> trap number = 12
>> Panic:Thought about setting the watchdog to 10 Minutes
>> panic: page fault
>> cpuid = 1
>> KDB: stack backtrace:
>> stack1 db_trace_self_wrapper+0x2a
>> kdb_backtrace+0x37 vpanic+0xf7
>> panic+0x67 trap_fatal+0x264
>> KDB: enter: panic
>> [ thread pid 3 tid 100328 ]
>> Stopped at kdb_enter+0x50: movq $0,0x6bd5cd(%rip)
>> db> reboot
>> I will add that after this, every boot hits this problem. (same stack trace).
>> the box is effectively bricked
>> (or would be if it weren't just a bhyve image)
More information about the freebsd-fs