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
> r...@syspatch-66-i386.openbsd.org:/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.



-- 
Antoine

Reply via email to