
Ubuntu日本語フォーラム
ログインしていません。
お世話になります。
ルートパーティションの容量が少なくなってきてバージョンのアップグレードができない状況に陥ったため、/usrを別の既存のパーティションにコピーし、/usrにはシンボリックリンクを置く形にすることを考えました。
ところが実際にやってみると、ブート時に/sbin/initの起動のところで
/sbin/init: error while loading shared libraries: libip4tc.so.0: cannot open shared object file: No such file or directory
というエラーでカーネルがパニックします。
調べてみると、このlibip4tc.so.0は/usr/libにあります。
さて、これはlibip4tc.so.0のパッケージのバグなのでバグ報告すべきでしょうか? それとも、Ubuntuでは/usrはルートに置かなければならない仕様なのでしょうか?
この点の仕様についてどなたかご存じではないでしょうか。
オフライン
ルートパーティションの容量が少なくなってきてバージョンのアップグレードができない状況に陥ったため、/usrを別の既存のパーティションにコピーし、/usrにはシンボリックリンクを置く形にすることを考えました。
私は /usr を別パーティションにしてそのデバイスを /usr にマウントしていますが、問題なく動いています。
/etc/fstab のエントリーは
UUID=ファルシステムのUUID /usr ext4 defaults 0 2
(「ファイルシステムのUUID」はそのパーティションにあるファイルシステムのUUIDを調べて記述します。)
詳しくは理解できていないのですが / と /usr は boot 時に特別扱いされて、その情報は /etc/fstab から採られます。(man bootup の BOOTUP IN THE INITIAL RAM DISK や man systemd.special の initrd-fs.target に sysroot-usr.mount が出てきますが内容が分かりません。)/usr を symbolic link にすると /usr/lib が使えるようになるのが一般のファイルシステムと同じタイミング(local-fs.target?)まで遅れるのでエラーになるのだと推測します。
オフライン
ありがとうございます。
私もその後/usrに直接マウントしたら別扱いされるのかなというところまでは辿り着いたのですが、使えるパーティションはすでに別のところにマウントしているのでその構成を採れませんでした。/etc/fstabのオプションのところにx-initrd.mountを追加したら何か変わるかも…というところまで調べてあきらめました。
とりあえず/varの方を移動して容量をあけました。AppArmorが有効なので/etc/apparmor.d/tunables/aliasにパスを追加しないとうまく動かないとかこれはこれですんなりとはいきませんでしたが。
オフライン