Bug 190152

Summary: [patch] [rc] gmirror savecore support
Product: Base System Reporter: Paul J Murphy <paul>
Component: confAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed DUPLICATE    
Severity: Affects Only Me CC: christian.baltini
Priority: Normal    
Version: 10.0-RELEASE   
Hardware: Any   
OS: Any   
See Also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178818
Attachments:
Description Flags
savecore.patch none

Description Paul J Murphy 2014-05-23 20:10:00 UTC 
(Calling this a sw-bug, rather than change-request, as I consider it a bug that savecore is basically broken on a very common setup.)

Adding long-overdue basic gmirror savecore support.  In a perfect world, it would support AUTO for simple configurations, but I've left that as a TODO for now, and think that it's better to get this basic support into the OS, and someone can figure out a nice AUTO implementation later.  RC-wizards, please feel free to decide that the gmirror commands would be better executed inside the savecore_start() instead of pre/post.

Also fixes doc-bugs in gmirror(8), which suggested addressing the issue through the removed rc.early/rc.late scripts, and removes mention of not being able to change priority of gmirror components (seems to work just fine on 10.0-RELEASE, not sure when it was fixed).
Small section on boot on gmirror added to the NOTES section of gmirror(8), since there really should be some mention of that in there.

Fix: Proposed for CURRENT & 10-STABLE.  It should probably also go into older -STABLE too.  This patch was developed and tested on 10.0-RELEASE, but can probably be easily applied to just about any recent-ish release.

Is this simple and low-risk enough that it should go into existing releng branches as well?  There's a possible small benefit in security terms, in that any attacks or exploits which end up causing a panic might be more detectable/diagnosable with this patch installed.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2014-05-24 18:13:19 UTC 
Responsible Changed
From-To: freebsd-bugs->freebsd-rc

Over to maintainer(s).
Comment 2 Lawrence Chen 2014-05-27 23:13:55 UTC 
This sounds/looks similar to an issue I had reported as:

docs/178818: gmirror(8) says to use rc.early which is no longer available

Where there was a suggestion to handle it through the dumpon script, which I 
more recently found that the savecore script should have a corresponding mod 
as well.

The timestamp on my current savecore is May 12th.  And, my system 
successfully saved crash dumps from May 11th and May 13th.

The problem after the May 11th savecore, was that it didn't restore my 
balance setting.  I didn't look at the May 13th one....since I'm without a 
mirror now.  No panics since, perhaps that was the reason.

-- 
   Name: Lawrence "The Dreamer" Chen    Call: W0LKC
  Snail: 1530 College Ave, A5          Email: beastie@tardisi.com
         Manhattan, KS 66502-2768       Blog: http://lawrencechen.net
Comment 3 Paul J Murphy 2014-05-28 12:11:56 UTC 
On Tue, May 27, 2014 at 05:13:55PM -0500, The BSD Dreamer wrote:
> This sounds/looks similar to an issue I had reported as:
> 
> docs/178818: gmirror(8) says to use rc.early which is no longer available
> 
> Where there was a suggestion to handle it through the dumpon script, which I 
> more recently found that the savecore script should have a corresponding mod 
> as well.
> 
> The timestamp on my current savecore is May 12th.  And, my system 
> successfully saved crash dumps from May 11th and May 13th.
> 
> The problem after the May 11th savecore, was that it didn't restore my 
> balance setting.  I didn't look at the May 13th one....since I'm without a 
> mirror now.  No panics since, perhaps that was the reason.

Yes, it's basically the same problem as docs/178818.  I didn't spot
that PR when submitting this one, as I wasn't thinking "docs".  As far
as I'm aware, the problem doesn't actually need any changes to the
dumpon script, as the kernel will always deterministically pick 1
physical device within the mirror when dumping.  The problem comes
when savecore tries to read the saved dump, and needs the dump device
to give the same deterministic behaviour when reading from it.

It's quite possible that there is a configuration where changes are
needed to dumpon as well as savecore, but I don't know what that
configuration is.  If you know of a configuration which needs special
handling there (as well as during savecore), please provide any
details that you can.  I believe that my patch here is sufficient for
the 2 most obvious cases with a simple pair of simple drives
(i.e. JBOD, with no complex RAID hardware involved): 1) entire-disk
gmirror; 2) single-partition gmirror.

There's also a problem with the fix suggested in docs/178818, I think,
where it will fail on entire-disk gmirrors (i.e. where the mirror is
/dev/mirror/gm0, with dump on a partition inside the mirror at, e.g.,
/dev/mirror/gm0b or /dev/mirror/gm0s1b).  That is why I provided a
"savecore_gmirror_name" conf var in my patch here, and avoided
implementing AUTO for now.  It's certainly possible for someone to
implement AUTO in the future, which is why I left a TODO stub for it
in my patch, but it's more complex to reliably determine the mirror
name from the dump device than the simple stripping of "/dev/mirror"
attempted in docs/178818.


Regards,

Paul.
Comment 4 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:09 UTC 
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 5 Christian Baltini 2019-06-11 05:37:57 UTC 
I have provided my own workaround of sorts here: 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=178818#c5
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2019-06-11 07:40:58 UTC 
@Paul (or someone else), can we please get all/any proposed patches into bug 178818 please

*** This bug has been marked as a duplicate of bug 178818 ***