FATAL "imjournal.state" error?

new laptop: 5.15.4-101.fc34.x86_64 at time of bkup, AMD ryzen 7
old laptop: 5:14.18-100.fc33.x86_64 Intel Core i7

I’m on new laptop for 1 month and ran my usual backup cmd:

# restic -r ./nitroII -verbose backup / --exclude-file=nitroII.txt

Had crash during full backup while restic was in root file system.
I ran same cmd again but put root partition in exlcude file and bkup completed on /home partition with no error.

I connected bkup drv to old laptop and ran full bkup (incld. root fs) and it finished, no errors.
Re-connected to new laptop ran restic ‘check --read-data’ on repo (no errors) and then tried full bkup again. Again it crashed in while working in the root fs. Ran again and hit ctrl-c when it got to
root fs and before it crash. Here is output from screen:

   error: open /sys/bus/pnp/drivers/rtc_cmos/uevent: permission denied
   error: open /sys/bus/pnp/drivers/rtc_cmos/unbind: permission denied
   error: open /sys/bus/pnp/drivers/serial/bind: permission denied
   error: open /sys/bus/pnp/drivers/serial/uevent: permission denied
   error: open /sys/bus/pnp/drivers/serial/unbind: permission denied
   error: open /sys/bus/pnp/drivers/system/bind: permission denied```

… and many 100’s more, all seemed to come from dirs in /sys/???

and from I think /var/log/messages:

 grep: kernel/tracing/per_cpu/cpu4/trace_pipe: Resource temporarily unavailable
 grep: kernel/tracing/per_cpu/cpu3/snapshot_raw: Resource temporarily unavailable
 grep: kernel/tracing/per_cpu/cpu3/trace_pipe_raw: Resource temporarily unavailable
 grep: kernel/tracing/per_cpu/cpu3/trace_pipe: Resource temporarily unavailable
 grep: kernel/tracing/per_cpu/cpu2/snapshot_raw: Resource temporarily unavailable```
...
[root@nitroII sys]# cd ./kernel/debug/ieee80211/phy0/keys/0/
[root@nitroII 0]# ll
total 0
-r--------. 1 root root 0 Dec  3 00:53 algorithm
-r--------. 1 root root 0 Dec  3 00:53 flags
-r--------. 1 root root 0 Dec  3 00:53 hw_key_idx
-r--------. 1 root root 0 Dec  3 00:53 icverrors

… and many more, all with only one root perm set, sometimes its only -w

Did something change in the kernel from 5.14 to 5.15 that would cause the denial of
root to files?

Could this be related to btrfs?

I searched the forum for imjournal.state and didn’t come up with anything.
Is this a restic error or from the system:

Fatal: unable to save snapshot: node "imjournal.state" already present errors ETA 0:31

I did get restic to bkup root but I had to deleted the ‘imjournal.state’ from /var/lib/rsyslog
so it work. Now the listing of /var/lib/rsyslog / is like it not mounted:

-????????? ? ? ? ?            ? imjournal.state
-????????? ? ? ? ?            ? imjournal.state
-????????? ? ? ? ?            ? imjournal.state

any help/thoughts apprectiated

Maybe you have a newer Linux distribution or newer kernel now on your New machine which uses more pseudo filesystems like /sys than your old system. Trying to backup these directories will only produce garbage and errors.

However, you should either always exclude pseudo filesystems like /proc and /sys in your restic command or, if your backup source is on one filesystem only, take a look at the - -one-file-system option.

betatester77 thanks for the quick suggestion. I just checked and it looks like my /home is btrfs and my / is ext4. I put /sys in exclude file. I’m starting to think my problem may be related to rsyslogd, looking into disable that and using imuxsock to see if it fixes problem.
thanks

I apologise to forum as I now see my question has little to do with restic.
I misunderstood the error msg:

Fatal: unable to save snapshot: node "imjournal.state" already present errors ETA 0:31

to be a restic error, and it is not…I think???

I apologise to waste your time

betatester77, sorry I didn’t mark your post as solution, it wasn’t till I muddled around and
finally realized my problem had little to do with restic that I finally understood that your advice
to look at --one-file-system option was indeed spot on.

1 Like