If you have a zfs based swap device, this doesn't work.

From the bug report, what happens is that there is a trapdoor effect
when running from the LiveCD (or any other installation image);
once the zpool has been created and configured, it is no longer
possible to unconfigure the dump device and destroy the zpool.
This makes re-invoking the installer impossible; instead a
reboot from media is required if the customer changes his mind.

The requirement to always have a dump device is a good one.
We also should make the installer restartable, if only for
testing purposes.  It has been a useful debugging aid to have
dumps configured by default when running the installer as we've
hit a few kernel bugs during installation, so we'd like to
continue configuring dumps during installation.

When we boot from the liveCD, we have swap configured in
the /etc/dumpadm.conf file; since there is no swap configured
at boot the kernel disables dumps.  Is there anyway we can
return to this configuration?

- Bart

I don't fully understand the context of the liveCD installer you're referring to, but for the installer for the 7000 series we have debugging and restartability and don't require any such generic change. But I am not familiar with the liveCD implementation.

Anyway, this sounds like an entirely different problem from "we need some generic way to disable dumps" which is just broken in my view and the view of the ARC when we created dumpadm in the first place. And this probably isn't the place to discuss it i.e. to walk me through the exact sequence of devices and pools created/consumed by the piece of software you're referring to.

I'd suggest withdrawing this case and discussing with me and someone on the ZFS team offline what problem you're having, and then you can resubmit a future case explaining the actual context for what problem is being solved, if indeed any change to dumpadm is required.

-Mike

---
Mike Shapiro, Sun+Oracle Open Storage / Fishworks. blogs.sun.com/mws/

_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org

Reply via email to