systemdでのvbox共有フォルダ自動マウント方法について

　一寸前にvirtualboxで運用してるdebianのunstableで、
dist-upgradeで最新に環境を更新したらしたら
起動デーモンがinitからsystemdに切り替わった模様。

　そのためvboxの共有フォルダがマウントできなくて四苦八苦したので
以下に記事にして解決方法を纏めておいた＾＾；

　結局私の環境ではマウント出来ない問題はvbox3.8.10同梱のguest additionディスクのバグと
systemdに切り替わったことによる/etc/rc.localのタイミング不具合の二つが有ったようだ。

　guest additionの不具合は次のリリースで直っているだろうから
systemdの稚拙な記事についてちょっと補足*1。

initからsystemdへの切り替わりの検出

　これは自分でもどうして気づいたか良く解らない。
まあdebian勉強会で「最近systemdに切り替わってservice書き直している」的な話を聞いていたので
なんとなくdist-upgradeしたし、systemdに変わっているかもとプロセスみてみたって感じだったと思う。

　たぶんinitからsystemdに切り替わってもほとんど問題起きないから気づかないと思う。
ってか普通は運用途中で切り替わらずに、ディストロのVersionUpで阿鼻叫喚になって*2情報氾濫するだろうし＞＜

/etc/rc.localについて

　systemdのserviceでrc.localが呼ばれているので、
initデーモン用に書いた/etc/rc.localは基本そのまま使用できる。

　が、今回の共有フォルダマウントは以下 "After=vboxadd.service" の制約があるので、
mount.vboxsfの読み込み前にrc.local実行して失敗している模様。

　全てのserviceの起動が終わった後なら、手動で普通にmount出来るのでタイミングが怪しい*3のだろうと判断した。

After=vboxadd.service

　mount.vboxsfは上記serviceで読み込まれているので、自動マウントはそれ以降でないと実行出来ない。
でadditionのvboxsf関連のバグと混ざって原因特定に難儀した＞＜

*1:英語で以下ニュアンスを書くのは難しいし、動作させるうえで本質的で無いので省いた＞＜

*2:ubuntu13.10のiBus1.5がそんな感じだったし

*3:ってかsystemd関連でググルとその辺りについて記載してる記事が結構ある。依存関係を記載して起動高速化はsystemdの開発目的でもあるので皆さん言及してる＾＾