Date: Sun, 06 Oct 2019 12:37:08 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 241097] freebsd-update(8) archives NFS mounts (and maybe other stuff) Message-ID: <bug-241097-227@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D241097 Bug ID: 241097 Summary: freebsd-update(8) archives NFS mounts (and maybe other stuff) Product: Base System Version: 12.0-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: bin Assignee: bugs@FreeBSD.org Reporter: kjift14@posteo.at FreeBSD 12.0-RELEASE with UFS root here (with /boot on the / volume), but I have witnessed this behaviour before on older releases as well. I have an NFS mount at the (FreeBSD non-standard) location /opt/XYZ When running `freebsd-update install`, the kernel backup copies the file sy= stem into /boot/kernel.old , and also wants to copy contents of NFS mounts there. This alone is wrong (and dangerous, think about full disks), as far as I understand what the kernel backup should do and what it should not. But even this copy fails with seemingly infinite errors of the form: cp: ///boot/kernel.old/./opt/XYZ/svn/[=E2=80=A6]/.svn/pristine/[=E2=80=A6]:= Cross-device link Probably many (all?) files on NFS are affected; the SVN internals were just= the ones for which I could see this. As a short-term mitigation, I interrupted the update, unmounted the NFS sha= res, deleted /boot/kernel.old (which took remarkably long for a SSD), and reissu= ed `freebsd-update install`. I don't think it is intentional that the kernel backup black-/whitelists ca= n be confused so easily. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-241097-227>