Much like the system/bootenv/default/usr does not contain /usr issue I recently wrote about, I found the same issue with system/bootenv/default/var
For this post, I have booted my FreeBSD 9.3 system from mfsBSD thumb drive.
I will import the pool, but not mount it.
# zpool import -N system
I mounted the filesystem in question, and confirm that there is just one ZFS thing mounted:
# mount -t zfs system/bootenv/default/var /mnt # mount -t zfs system/bootenv/default/var /mnt root@mfsbsd:~ # zfs mount system/bootenv/default/var /mnt
Let’s look in there:
# cd /mnt # ls -l total 0 # ls -lat total 18 drwxr-xr-x 18 root wheel 512 Mar 13 19:07 .. drwxr-xr-x 2 root wheel 2 May 3 2013 . # zfs
Nothing in there. Let’s look at system/bootenv/default:
# cd # umount /mnt # mount -t zfs system/bootenv/default /mnt # cd /mnt # ls -lat total 391 drwxr-xr-x 18 root wheel 512 Mar 13 19:07 .. -rw------- 1 root wheel 4096 Mar 13 19:02 entropy drwxr-xr-x 22 root wheel 28 Mar 13 19:02 . drwxr-xr-x 22 root wheel 149 Mar 12 18:13 etc drwxr-xr-x 26 root wheel 26 Mar 12 18:13 var drwxr-xr-x 17 root wheel 17 Mar 11 21:44 usr drwxr-xr-x 8 root wheel 44 Mar 9 02:10 boot drwxr-xr-x 2 root wheel 2 Mar 9 00:37 data drwxr-xr-x 2 root wheel 2 Mar 8 23:56 tmp drwxr-xr-x 2 root wheel 144 Feb 25 21:52 rescue drwxr-xr-x 3 root wheel 49 Feb 25 21:52 lib drwxr-xr-x 2 root wheel 2 Dec 25 15:27 ssd drwxr-xr-x 2 root wheel 132 Oct 26 14:50 sbin drwxr-xr-x 3 root wheel 4 Aug 11 2014 libexec drwxr-xr-x 2 root wheel 46 Aug 11 2014 bin -r--r--r-- 1 root wheel 6197 Aug 11 2014 COPYRIGHT -rw-r--r-- 1 root wheel 253 Aug 11 2014 .profile -rw-r--r-- 1 root wheel 965 Aug 11 2014 .cshrc drwxr-xr-x 2 root wheel 2 May 2 2014 backups drwxr-xr-x 2 root wheel 2 Sep 9 2013 mnt lrwxr-xr-x 1 root wheel 8 May 3 2013 home -> usr/home lrwxr-xr-x 1 root wheel 11 Dec 4 2012 sys -> usr/src/sys drwxr-xr-x 2 root wheel 6 Dec 4 2012 root dr-xr-xr-x 2 root wheel 2 Dec 4 2012 dev drwxr-xr-x 2 root wheel 2 Dec 4 2012 media dr-xr-xr-x 2 root wheel 2 Dec 4 2012 proc #
Yes, there’s /var. How big is it?
# du -ch -d 1 var 692M var/cache 17K var/account 59K var/cron 17K var/rwho 284K var/run 1.8M var/spool 17K var/authpf 17K var/preserve 188M var/named 17K var/empty 33K var/lib 17K var/games 66K var/munin 50K var/at 17K var/audit 22K var/mail 33K var/tmp 51M var/backups 25K var/msgs 50K var/yp 25K var/crash 17K var/heimdal 2.7G var/db 17K var/log 3.6G var 3.6G total
That var/db is big. What’s in there?
# du -ch -d 1 var/db 797M var/db/mysql 105M var/db/pkg 4.7M var/db/etcupdate 1.3M var/db/ports 284M var/db/portsnap 25K var/db/postfix 59K var/db/logcheck 34K var/db/bacula 1.4G var/db/freebsd-update 203K var/db/sudo 230K var/db/fontconfig 17K var/db/ipf 85K var/db/entropy 2.7G var/db 2.7G total
That looks sane.
OK, let’s do this
This will copy things over:
tar clf - -C /mnt/var . | tar xpvf - -C /DEST/
After the copy, we have:
# cd /DEST # ls -l total 396 drwxr-xr-x 2 root wheel 2 Dec 4 2012 account drwxr-xr-x 4 root wheel 4 Dec 4 2012 at drwxr-xr-x 2 root wheel 2 Mar 8 23:56 audit drwxrwx--- 2 root authpf 2 Nov 8 2013 authpf drwxr-x--- 2 root wheel 13 Mar 13 05:17 backups drwxr-xr-x 3 root wheel 3 Nov 14 2013 cache drwxr-x--- 2 root wheel 3 Dec 4 2012 crash drwxr-x--- 3 root wheel 3 Dec 4 2012 cron drwxr-xr-x 15 root wheel 20 Mar 13 16:02 db dr-xr-xr-x 2 root wheel 2 Dec 4 2012 empty drwxrwxr-x 2 root games 2 Dec 4 2012 games drwx------ 2 root wheel 2 Dec 4 2012 heimdal drwxr-xr-x 3 root wheel 3 Jun 10 2014 lib drwxr-xr-x 2 root wheel 3 Dec 4 2012 log drwxrwxr-x 2 root mail 13 Feb 24 18:17 mail drwxr-xr-x 2 daemon wheel 3 May 3 2013 msgs drwxr-xr-x 3 842 842 3 Jun 10 2014 munin drwxr-xr-x 6 root wheel 6 Jun 5 2013 named drwxr-xr-x 2 root wheel 2 Dec 4 2012 preserve drwxr-xr-x 10 root wheel 19 Mar 13 16:02 run drwxrwxr-x 2 root daemon 2 Dec 4 2012 rwho drwxr-xr-x 11 root wheel 11 Dec 9 20:09 spool drwxrwxrwt 3 root wheel 3 Dec 4 2012 tmp drwxr-xr-x 2 root wheel 4 Aug 11 2014 yp #
Note that /DEST does not contain a /var. That is because our mountpoint is /var and I can prove that with this:
# zfs mount system/bootenv/default /mnt system/bootenv/default/var /DEST # zfs get mountpoint system/bootenv/default/var NAME PROPERTY VALUE SOURCE system/bootenv/default/var mountpoint /var inherited from system/bootenv/default
Rename the old var
I renamed the old /span class=”file”>/var directory on the system/bootenv/default dataset:
# cd /mnt # mv var zzz-DELETE-me-OLD-var
This allows me to keep the old /var. I’m pretty sure the old /var would be overwritten by the new /var when it was mounted from system/bootenv/default/var, but renaming allows:
- Proof that the old /var is not mounted.
- Reminds me to delete the old /var later.
- Keeps the old /var accessible should I want to grab something from it.
This is the important bit
Do not forget this:
zfs set canmount=yes system/bootenv/default/var
Thoughts
I have been thinking that it might be better to not do what I’ve been doing. That it’s better to have the top level mountpoint be empty. Time will tell.
Reboot time.
After the reboot
After the reboot, I was able to proceed with the freebsd-update process. You can read about that in my next post.