Bug 247618 - /etc/rc.d/savecore doesn't work if dumpdev is a GEOM name
Summary: /etc/rc.d/savecore doesn't work if dumpdev is a GEOM name
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 12.1-STABLE
Hardware: Any Any
: --- Affects Many People
Assignee: Alan Somers
URL: https://reviews.freebsd.org/D25500
Depends on:
Reported: 2020-06-28 15:18 UTC by Alan Somers
Modified: 2020-09-19 18:36 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Alan Somers freebsd_committer 2020-06-28 15:18:11 UTC
If in /etc/rc.conf you specify dumpdev as "auto" or an absolute path like "/dev/label/dump0", then everything is fine.  But if you specify it as a geom name like "label/dump0", then /etc/rc.d/savecore won't be able to find it.  The problem is not immediately apparent because /etc/rc.d/dumpon _does_ accept dumpdev in that format (added by smh in r291207).

I see two possible good solutions:
1) Modify /etc/rc.d/savecore to check "savecore -C /dev/${dev}" if "savecore -C ${dev}" fails.
2) Modify /etc/rc.d/savecore to check for /dev/dumpdev even if dumpdev is not set to "auto"
Comment 1 commit-hook freebsd_committer 2020-06-29 22:12:51 UTC
A commit references this bug:

Author: asomers
Date: Mon Jun 29 22:12:23 UTC 2020
New revision: 362790
URL: https://svnweb.freebsd.org/changeset/base/362790

  savecore: accept device names without the /dev/ prefix

  dumpon has accepted device names without the prefix ever since r291207.
  Since dumpon and savecore are always paired, they ought to accept the same
  arguments. Prior to this change, specifying 'dumpdev="da3"' in
  /etc/rc.conf, for example, would result in dumpon working just fine but
  savecore complaining that "Dump device does not exist".

  PR:		247618
  Reviewed by:	cem, bcr
  MFC after:	2 weeks
  Sponsored by:	Axcient
  Differential Revision:	https://reviews.freebsd.org/D25500

Comment 2 Alan Somers freebsd_committer 2020-09-19 18:36:40 UTC
Conflicts with r342699, so can't be MFCed.