On Wed, Dec 20, 2023 at 10:57:41AM -0500, Nick Holland wrote: > the ROOTBACKUP process is making an image of a live file system; fsck > grumblings ARE expected. It's just one of those things you aren't supposed > to do (but I do it regularly, because normally, you can get away with it). > > Why the files it is grumbling about are owned by you ... that is a puzzle. > Is your /tmp on a separate partition? If so, it shouldn't be being backed > up by the ROOTBACKUP process. Same for "home" or any other file system you > have access write to.
Interesting ... unexpectedly /tmp _is_ part of the root filesystem. I have an entry in fstab to mount it as a seperate mfs filesystem but that has failed for some reason. Probably then this is the reason that the fsck errors are now occurring, being reported, and that I noticed them. Previously, when /tmp was transient, the root filesystem and the altroot fsck process were not affected by content in /tmp. Just tried the mount of /tmp manually from the command line at got: mount_mfs: mmap: Cannot allocate memory When I halved the size (memory) allocated (-s=2097152) it mounts successfully: mjoelnir:robb 20.12 19:50:02 # df -h /tmp Filesystem Size Used Avail Capacity Mounted on mfs:75507 1.9G 1.0K 1.8G 1% /tmp Strange that it used to work. One day (!) I'll re-partition and allocate a partition/slice of "real" storage to /tmp instead of using mfs. > I also see this: > > Backing up root=/dev/rsd1a to /dev/rsd0a: > is sd1a actually your root, and sd0a actually your altroot? > > Second question: Also after an upgrade, the "daily insecurity output" > > contains a huge amount of setuid changes e.g. > > ... > > What actually changed then? > > The files. Aha! - I see. I had in my head somehow understood "Setuid changes:" to mean "changes to the setuid flags/bits of these files ...", not "these files are suid and their content has changed". Maybe that is a better description. > (and yes, I have seen events where a major upgrade caused a lot of noise in > a "something changed" file...which unfortunately hid something we needed to > know about ALSO happened, and was dismissed as "part of the upgrade noise". > This wasn't OpenBSD nor was it a "security event", but it did delay the > detection and repair of a redundancy failure issue because one line was > missed in a sea of thousands of lines of "yeah, that's expected" noise.) It is a fair bit of noise in this case ... even more so with the following "Block device changes" and the even longer "rpki" related section. Thanks! Cheers, Robb.
