I seem to be getting mixed messages from savecore(8)

David Wolfskill david at catwhisker.org
Tue Dec 10 23:51:11 UTC 2019


In case anyone is interested, for the archives:

On Sun, Dec 08, 2019 at 02:47:12PM -0800, David Wolfskill wrote:
> ...
> So: If I understand correctly, "savecore -C" detacts that a dump exists
> on the cited device, but invoking savecore to actually ... save ... the
> dump does not actually do that.

The observed behavior is a result of attempting to implement encrypted
swap:  I had successfully arranged to swap to /dev/nda0p5.eli;
apparently performing a read-only open of /dev/nda0p5:

...
   1062 int
   1063 main(int argc, char **argv)
   1064 {
...
   1027         /*
   1028          * The fileargs capability does not currently provide a way to limit
   1029          * ioctls.
   1030          */
   1031         (void)cap_rights_init(&rights, CAP_PREAD, CAP_WRITE, CAP_IOCTL);
   1032         capfa = fileargs_init(argc, argv, checkfor || keep ? O_RDONLY : O_RDWR,
   1033             0, &rights, FA_OPEN);
   1034         if (capfa == NULL) {
   1035                 logmsg(LOG_ERR, "fileargs_init(): %m");
   1036                 exit(1);
   1037         }

...
    578 static void
    579 DoFile(const char *savedir, int savedirfd, const char *device)
    580 {
...
    618         if (verbose)
    619                 printf("checking for kernel dump on device %s\n", device);
    620 
    621         fddev = fileargs_open(capfa, device);
    622         if (fddev < 0) {
    623                 logmsg(LOG_ERR, "%s: %m", device);
    624                 return;
    625         }
....


is OK, but read/write ... is not.  (Which is not unreasonable.)

> Any suggestions for expressing my request in a way that savecore is a
> bit more likely to accept?

My revised appraoch is to run savecore before starting swapping on
the device (via swapon).  That appears to work, though I don't know
if that may cause a problem later on.

(In this environment, swapon is being invoked explicitly in an
/etc/rc.d script, rather than by virtue of /etc/fstab entrues (for
example).)

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
Some might think an oath of office is as meaningful as a marriage vow.

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20191210/3b105c22/attachment.sig>


More information about the freebsd-hackers mailing list