Joachim Worringen wrote:
> But as I said, a real kernel panic says it dumps to /dev/dsk/c1t0d0s4 as
> well, but savecore doesn't do anything on reboot.
>
> Any idea what's wrong? I tried different kinds of panics already...
'reboot -d' is a nice "controlled" panic which should always work.
If the dump completes to the dump device ok (ie it gets to 100%
done) then we shoule be able to process it on the reboot.
On boot your dedicated dump device is appointed (as per dumpadm.conf)
when the filesystem/usr service comes online (for zfs root)
or in the dumpadm service (for ufs root). Either way
your dedicated dump device should have been appointed
before savecore is run - that's run in the latter half
of the startup method for the dumpadm service.
So start by checking that the dumpadm service comes online
after reboot, and check the SMF log file for that service.
Also check syslog messages for any complaints from
savecore.
Assuming that service has come online and you did not
obtain a crash dump (and remembering that savecore
runs in the background from that service - so
pgrep savecore to be sure it is not still running)
you can try the following ideas:
- # savecore -v /export/home/crash
That's what the startup method should have run
(without the -v).
- # savecore -dv /export/home/crash
The -d says to disregard any flag in the dump header
which says "this dump has already been processed".
Is any crash so obtained the one you just triggered,
or is it an old dump?
- how/when is /export/home/crash mounted? Could it be that
we're savecore'ing and are then overlaying the mountpoint?
Is /export/home/crash ufs, zfs, nfs?
If all that fails we can look around the dump device directly
to see the state of the headers etc, but let's try the
easier stuff first.
Cheers
Gavin
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
