# Backup of boot partition content: file not found



## lifepillar (Nov 23, 2021)

I have recently set up a FreeBSD 13 server with mirrored ZFS. The daily mail reports this message:


```
Backup of boot partition content:
ada0p2
mv: rename /var/backups/boot.ada0p2.tmp to /var/backups/boot.ada0p2.bak: No such file or directory
ada1p2
mv: rename /var/backups/boot.ada1p2.tmp to /var/backups/boot.ada1p2.bak: No such file or directory
```

I haven't tweaked the system much, so I am wondering what the cause of the error is and what I should do to fix it.


----------



## _martin (Nov 23, 2021)

There's a scheduled daily cronjob (/etc/crontab), the script /etc/periodic/daily/221.backup-gpart. Try to run manually to see if the backup gets through. Maybe it fails within the script for some reason (dd of the boot part failing?).


----------



## covacat (Nov 23, 2021)

dd stderr is sent to /dev/null (probably to shut up the stats)
you need to copy the script to tmp, remove 2>/dev/null from the dd lines and see what really happens


----------



## lifepillar (Nov 26, 2021)

I have followed your suggestions, but when I execute the script manually, it goes through just fine and exits with code 0. That's the output:


```
$ /tmp/221.backup-gpart                                          
                                                                
Dump of kern.geom.conftxt:                                      
                                                                
Backup of partitions information for:                           
ada0                                                            
ada1                                                            
ada2                                                            
                                                                
Backup of boot partition content:                               
ada0p2                                                          
1024+0 records in                                               
1024+0 records out                                              
524288 bytes transferred in 0.117460 secs (4463549 bytes/sec)   
ada1p2                                                          
1024+0 records in                                               
1024+0 records out                                              
524288 bytes transferred in 0.092269 secs (5682153 bytes/sec)
```

What I have seen with further debugging is that `rotate()` executes the `then` branch and just removes the `.tmp` file. It seems, however, that when executed as a cron job, the script runs the `else` part of the function, trying to rename the `.tmp` file. I don't know why.


----------



## covacat (Nov 26, 2021)

no idea, like the cron script has no /var/backups or somehow dd fails from whatever reason
best idea to put the modified version in /etc/periodic/daily
you also may add a "set -x" at the top of the file (after "#!/bin/sh"


----------



## SirDice (Nov 26, 2021)

Please post the output from `ls -al /var/backups` too.


----------



## lifepillar (Nov 26, 2021)

There it is:


```
$ ls -al /var/backups 
total 5690
drwxr-x---   2 root  wheel      27 Nov 26 14:12 .
drwxr-xr-x  24 root  wheel      24 Nov 11 18:51 ..
-rw-r--r--   1 root  wheel    1624 Apr  9  2021 aliases.bak
-rw-r--r--   1 root  wheel  524288 Oct 26 03:01 boot.ada0p2.bak
-rw-r--r--   1 root  wheel  524288 Oct 26 03:01 boot.ada1p2.bak
-rw-r--r--   1 root  wheel     512 Oct 26 03:01 boot.ada2.bak
-rw-r--r--   1 root  wheel     208 Oct 27 03:01 gpart.ada0.bak
-rw-r--r--   1 root  wheel     197 Oct 26 03:01 gpart.ada0.bak2
-rw-r--r--   1 root  wheel     208 Oct 27 03:01 gpart.ada1.bak
-rw-r--r--   1 root  wheel     197 Oct 26 03:01 gpart.ada1.bak2
-rw-r--r--   1 root  wheel      63 Oct 27 03:01 gpart.ada2.bak
-rw-r--r--   1 root  wheel       6 Oct 26 03:01 gpart.ada2.bak2
-rw-r--r--   1 root  wheel      47 Nov 21 03:01 gpart.da0.bak
-rw-r--r--   1 root  wheel     495 Oct 26 12:54 group.bak
-rw-r--r--   1 root  wheel     477 Oct 24 17:18 group.bak2
-rw-r--r--   1 root  wheel    1246 Nov 22 03:01 kern.geom.conftxt.bak
-rw-r--r--   1 root  wheel    1394 Nov 21 03:01 kern.geom.conftxt.bak2
-rw-------   1 root  wheel    2149 Nov  6 16:13 master.passwd.bak
-rw-------   1 root  wheel    2139 Oct 26 15:16 master.passwd.bak2
-rw-r--r--   1 root  wheel  731248 Nov 26 03:01 pkg.sql.xz
-rw-r--r--   1 root  wheel  731248 Nov 25 03:19 pkg.sql.xz.1
-rw-r--r--   1 root  wheel  731248 Nov 24 03:03 pkg.sql.xz.2
-rw-r--r--   1 root  wheel  731292 Nov 23 03:01 pkg.sql.xz.3
-rw-r--r--   1 root  wheel  731292 Nov 22 03:26 pkg.sql.xz.4
-rw-r--r--   1 root  wheel  731292 Nov 21 03:07 pkg.sql.xz.5
-rw-r--r--   1 root  wheel  499672 Nov 20 03:02 pkg.sql.xz.6
-rw-r--r--   1 root  wheel  499644 Nov 19 03:43 pkg.sql.xz.7
```

/var/backups itself is 750, root:wheel.


----------



## _martin (Nov 26, 2021)

Just to be sure can you verify that by some sort of mistake you don't have this script scheduled more times ?


----------



## SirDice (Nov 26, 2021)

Alright, those permissions look good. Can you show the output from `gpart show ada0` and/or `gpart show ada1`?


----------



## lifepillar (Nov 26, 2021)

I think everything is in order there:


```
$ gpart show ada0
=>        40  7814037088  ada0  GPT  (3.6T)
          40      532480     1  efi  (260M)
      532520        1024     2  freebsd-boot  (512K)
      533544         984        - free -  (492K)
      534528     4194304     3  freebsd-swap  (2.0G)
     4728832  7809306624     4  freebsd-zfs  (3.6T)
  7814035456        1672        - free -  (836K)
```



> can you verify that by some sort of mistake you don't have this script scheduled more times ?


May it be that the script is triggered from within some jail? How do I check whether it is scheduled more than once?


----------



## covacat (Nov 26, 2021)

it's quite  possible


----------



## SirDice (Nov 26, 2021)

lifepillar said:


> May it be that the script is triggered from within some jail?


Then root in the jail would get that email, not root on the host. In a jail you can turn this off by adding `daily_backup_gpart_enable="NO"` to /etc/periodic.conf.


----------



## lifepillar (Nov 26, 2021)

> Then root in the jail would get that email, not root on the host.


Ah, bingo! I get periodic emails from each jail. I got confused because (a) each jail reports the same error, and (b) I have forgotten to set up email forwarding _for the host _. So, I was believing that the error is in the host while, in fact, the problem is in each and every jail I have set up.

In fact, I can reproduce it in a jail by running the cron script manually. I am going to re-apply your suggestions to figure out why.


----------



## SirDice (Nov 26, 2021)

Yes, it's going to fail in a jail because it doesn't have access to the disk directly. Just turn off that check in /etc/periodic.conf on each jail. It's pointless to do this in a jail anyway, the host is already making those backups.


----------



## lifepillar (Nov 26, 2021)

Done, thanks. Is there any reference describing which cron jobs should be turned off in jails? AFAIK, the handbook just recommends turning off adjkerntz.


----------



## covacat (Nov 26, 2021)

well this is kind of a bug
the script should check itself if it jailed and exit because it can't possibly work in a jail


----------



## _martin (Nov 26, 2021)

covacat said:


> it can't possibly work in a jail


Not true - you can expose disk(s) to a jail via dev rulesets and it can be a legit reason (even so when it's probably a corner case and you don't want to have system disks exposed to jail).


----------



## SirDice (Nov 26, 2021)

lifepillar said:


> Is there any reference describing which cron jobs should be turned off in jails?


Not really, jails can be set up in various different ways. You're going to have to check which scripts apply to your situation and which don't.


----------

