On Sun, Dec 8, 2019 at 6:08 AM Antoine Jacoutot <[email protected]> wrote:
> > > 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. > > > > mfs:53614 on /var type mfs (asynchronous, local, nodev, nosuid, > size=524288 > > > 512-blocks) > > > /dev/wd0e on /var/syspatch type ffs (local, nodev, nosuid) > > > > Can work around it by modifying the check on line 98. Is it OK to > allow > > > mfs filesystems? > > > 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. Understood. I'm OK dealing with my non-supported choice of mounting /var as mfs. The checks in question are about disk space, if the (valid!) concern is about losing rollback files, I'd suggest an explicit check that /var/syspatch is sane (local, UFS, whatever else). Every previous syspatch on this system worked, only syspatch66-010_libcauth.tgz failed since it happened to include new files destined for /var. Regards, - Art
