On Sat 15 Jul 2023, at 17:52, David Mehler <dave.meh...@gmail.com> wrote: [...] > Regarding the original issue of the systemd upgrade and the invalid > attributes [...] here is the output that I've got: > [...] > Cannot set file attributes for '/var/log/journal', maybe due to > incompatibility in specified attributes, previous=0x00080000, > current=0x00080000, expected=0x00880000, ignoring. > Cannot set file attributes for > '/var/log/journal/390b00d843d3401094a8fd44f1b7de82', maybe due to > incompatibility in specified attributes, previous=0x00080000, > current=0x00080000, expected=0x00880000, ignoring. > Obsolete conffile /etc/systemd/resolved.conf has been modified by you. > Saving as /etc/systemd/resolved.conf.dpkg-bak ...
User "seth" at https://bbs.archlinux.org/viewtopic.php?id=272893 suggests "The error itself is harmless; systemd tries to set an attribute on a filesystem that doesn't support it" which seems to go along with it being ignored. and later: "0x00800000 is FS_NOCOW_FL - what is not a thing on directories. Edit except for apparently btrfs - what also seems the only supported FS here. Otherwise you get an error [...]" User j1simon suggests in https://bbs.archlinux.org/viewtopic.php?pid=2013787#p2013787 that the errors are present at boot. (I presume journalctl -b is how that output was obtained) I use ZFS and can't find any similar errors in boot log $ sudo journalctl -b|grep incompat $ so I wonder if ZFS supports it on directories too. man ioctl_iflags: "FS_NOCOW_FL 'C' (since Linux 2.6.39) The *file* will not be subject to copy-on-write updates. This flag has an effect only on filesystems that support copy-on-write semantics, such as Btrfs. See chattr(1) and btrfs(5)." https://man7.org/linux/man-pages/man2/ioctl_iflags.2.html The reporter in the first link above is asked if the bug has been reported to systemd developers. In another bug report re the same error (if in a slightly different context) on F2FS, systemd developer Lennart Poettering says "[...] this is a bug in the filesystem - They should not just eat up requests to set flags, but return an error. Please ping the f2fs maintainers." https://github.com/systemd/systemd/issues/26318 It looks like the same bug/issue on ext4 to me, and I imagine safe to ignore. Best wishes, Gareth