Your message dated Wed, 28 Jan 2026 18:17:43 +0000
with message-id <aXpSx422PJlCR9nr@???>
and subject line Fixed in Debian #1106830
has caused the Devuan bug report #932,
regarding init scripts fail when /var is in a separate partition
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@???
immediately.)


--
932: https://bugs.devuan.org/cgi/bugreport.cgi?bug=932
Devuan Bug Tracking System
Contact owner@??? with problems
Package: sysv-rc
Version: 3.14

Resending this message after getting a automatic response rejecting my
message and complaining about not including the "Package:" pseudo
header. Seriously? I'm a human, not a machine. (I put sysv-rc just to
put something, I don't know if the problem is actually in this package.)

To the point.

Yesterday I installed Excalibur. I did something that I hadn't done in
a while on Linux, to create separate partitions for /usr and /var. But
this brought me a problem. The following messages appear at boot:

[...] Cannot persist initramfs fsck.log ... failed!
[...] Checking file systems...Cannot persist the following output on disc ... failed!

They are generated by /etc/init.d/checkroot.sh and
/etc/init.d/checkfs.sh. These scripts fail trying to save the fsck logs
to /var/log/fsck/*. Once the system booted, I check those files and I
get this:

$ cat /var/log/fsck/check*
(Nothing has been logged yet.)
(Nothing has been logged yet.)

I'll tell you what I investigated so far. In /etc/init.d/checkroot.sh
(line 17) you'll find this variable:

FSCK_LOGFILE=/var/log/fsck/checkroot

Further down in this same script, the following conditional:

    if [ -x /sbin/logsave ] && [ -e "${FSCK_LOGFILE}" ]; then
        logsave -s "${FSCK_LOGFILE}" >/dev/null \
            cat /run/initramfs/fsck.log
    else
        log_failure_msg "Cannot persist initramfs fsck.log"
    fi

What fails in that conditional is [ -e "${FSCK_LOGFILE}" ].
The same happens in /etc/init.d/checkfs.sh. In the line 16 you find
something similar:

FSCK_LOGFILE=/var/log/fsck/checkfs

That calls the function logsave_best_effort() in
/usr/lib/init/mount-functions.sh:

  logsave_best_effort() {
          if [ -x /sbin/logsave ] && [ -e "${FSCK_LOGFILE}" ]; then
                  logsave -s "${FSCK_LOGFILE}" "$@"
          else
                  log_failure_msg "Cannot persist the following output on disc"
                  "$@"
          fi
  }

Again, it fails this test in the conditional: [ -e "${FSCK_LOGFILE}" ].

If you remove that check from the conditionals in both scripts, the boot
error messages desapear and the logs are successfuly written to
/var/log/fsck/check* files. Besides, I tried the following. First I
created a directory in the root partition:

# mkdir /fsck
# touch /fsck/{checkroot,checkfs}

Then I changed the variables in both scripts to point to those files:

FSCK_LOGFILE=/fsck/checkroot
FSCK_LOGFILE=/fsck/checkfs

I rebooted and it worked. No failure messages at boot and, once the
system booted, I checked those files and the logs were successfully
saved. I did the same test now creating that directory on /usr
(remember that I also put /usr in a separate partition).

# mkdir /usr/fsck
# touch /usr/fsck/{checkroot,checkfs}


Considering all said (and from my limited knowledge of the init process
in Linux,) I think the error lies in that these scripts try to check the
existence of /var/log/fsck/check* files on what initramfs previously
mounted in read-only mode. Since initramfs only mounts the rootfs and
/usr, when /var is in a separate partition it's out of reach.

So far I ignore how to solve the issue.

At least, that those logs are not saved to disk doesn't imply much harm.
They are temporarily saved to /run/initramfs/fsck.log anyways.
Version: 3.15-4