On Sun, Dec 08, 2019 at 12:01:37PM +0100, Antoine Jacoutot wrote: > On Fri, 2019-12-06 at 09:26 -0500, Art Manion wrote: > > Environment: > > System : OpenBSD 6.6 > > Details : OpenBSD 6.6 (GENERIC) #3: Thu Nov 21 00:59:03 MST 2019 > > [email protected]:/usr/src/sys/arch/i386/compile/GENERIC > > Architecture: OpenBSD.i386 > > > > Description: > > > > syspatch adds up the sizes of existing files to be replaced and collects > > the device names: > > > > 91 stat -qf "_dev=\"\${_dev} %Sd\"; > > 92 local %Sd=\"\${%Sd:+\${%Sd}\+}%Uz\"" ${_files}) > > \ > > 93 2>/dev/null || _rc=$? > > > > then checks that devices are mounted and are not read-only: > > > > 97 for _d in $(printf '%s\n' ${_dev} | sort -u); do > > 98 mount | grep -v read-only | grep -q "^/dev/${_d} " || > > 99 sp_err "Read-only filesystem, aborting" > > > > I have a system with /var and /tmp mounted as mfs. The stat string > > format returns '??' for mfs devices: > > > > $ stat -f %Sd /bin/cat > > wd0a > > > > $ stat -f %Sd /var/db/libc.tags > > ?? > > > > The 'grep -q ^/dev/??' on line 98 fails causing syspatch to error out > > reporting a read-only filesystem, which is not correct. > > > > I noticed this with syspatch66-010_libcauth.tgz which looks to be the > > first patch that changes files in /var (like /var/db/libc.tags). > > > > $ syspatch > > Get/Verify syspatch66-010_libcaut... 100% |*************| 17685 KB 00:03 > > > > Installing patch 010_libcauth > > Read-only filesystem, aborting > > > > $ mount > > /dev/wd0a on / type ffs (local) > > /dev/wd0g on /home type ffs (local, nodev, nosuid) > > /dev/wd0f on /usr type ffs (local, nodev, wxallowed) > > /dev/wd0d on /mfs type ffs (local, nodev, nosuid) > > mfs:37162 on /tmp type mfs (asynchronous, local, nodev, nosuid, size=524288 > > 512-blocks) > > mfs:53614 on /var type mfs (asynchronous, local, nodev, nosuid, size=524288 > > 512-blocks) > > mfs:40334 on /dev type mfs (asynchronous, local, noexec, nosuid, size=8192 > > 512-blocks) > > /dev/wd0e on /var/syspatch type ffs (local, nodev, nosuid) > > _a_host_:/some/nfs/export on /mnt/_an_nfs_mount_ type nfs (noexec, v3, udp, > > timeo=100, retrans=101) > > > > Can work around it by modifying the check on line 98. Is it OK to allow > > mfs filesystems? > > > > Is the major number for mfs uniquely 255? > > > > $ stat -f %Hd /var/db/libc.tags > > 255 > > > > $ stat -f %Hd /mnt/_an_nfs_mount_ > > 22 > > Thanks for the report. > It is expected yes. > Actually having /var mounted over MFS is absolutely not supported (because > this > is where we store rollback tarballs and where syspatch checks to see whether a > particular patch has been installed). > I will make that check stronger so that syspatch fails right away on > MFS-mounted > /var.
Ah I misread that you have /var/syspatch on UFS. Ok then the behavior you are seeing is to be expected; we don't want to install updated files to an ephemeral fs. That said, the error message could be more useful. -- Antoine
