/usr が大きくなりすぎたため別のディスクに移動しましたが、システムが起動しなくなりました。

/usr が大きくなりすぎたため別のディスクに移動しましたが、システムが起動しなくなりました。

現在、私はarchインストール(純粋なarch + hyprland)をインストールしているので、/(ルート)はNVME SSD(Windowsデュアルブートのためスペースが少ない)にありますが、/homeディレクトリはSSHD(SSDとHDDのハイブリッドですが、HDDとして考えても大丈夫です)にあります。これは、はるかに多くのストレージスペースがあるためです。しかし、より多くのパッケージ、ドライバーなどをインストールしたため、SSDに収まらないほど大きくなってきたので、いくつかのガイドに従いました。アスクブントゥスーパーユーザーそして、基本的に同じことを言っている他のサイトもありました。それに従って、ライブディスクを起動し、両方のドライブをマウントしました。ここにシステム上のすべてのドライブとパーティション参考までに(ルートはnvme0n1p8、ホームはsda5、usrのターゲットはsda6)を実行しrsync -avh "/mnt/usr/" "sda6mnt/"、etc/fstabを編集して再起動しました。しかし、再起動後にこの画面

これを修正するために、ライブディスクに戻りましたが、今回はすべてのドライブをマウントしましたこのような(つまり、すべてが完了した後にはどうなっているか)。そしてgenfstab -U /mnt >> /mnt/etc/fstab、実行してvimfstabを編集し、以前の設定を削除して、次のようになりました。これ問題ないように見えたので再起動しましたが、以前と同じエラーが発生しました。

それで、パーティション分割中または fstab の作成中に何か間違いを犯したかどうか、ここで何が間違っているのかを誰かが解明するのを手伝ってくれることを願っています。よろしくお願いします!

Ps 写真については申し訳ありませんが、キャプチャカードを持っていないので、Arch リカバリ シェルでスクリーンショットを撮ることができませんでした :)

答え1

/usrにはメインOSの大部分が格納されているため、実際にはマウントできない。による同じ OS の場合 (たとえば、/usr/bin/mount がまだない場合)、代わりにブート プロセスの初期段階で initramfs によってマウントする必要があります。ディストリビューションでは、通常の fstab を介して後で /usr をマウントすることがサポートされていましたが、Arch (または Debian、Gentoo、Fedora) ではそうではありません。

通常のArch mkinitcpioでは、フック/etc/mkinitcpio.confを有効にするように編集しusr、を使用してinitramfsを再構築しますmkinitcpio -P記事(ただし、Btrfs を使用しているため、通常は initramfs 全体を 'systemd' に切り替えることをお勧めします。)

(ただし、現実的には、/ の残りを SSD に保存してもあまり意味がないと思います。/usr がなければ、SSD に残るのは /var と /etc だけですが、どちらも小さくてあまり使用されません。デスクトップ PC では、/var を最速のディスクに保存するのは無駄に思えます。基本的に、そこにあるのはログだけです。私なら、より大きな NVMe SSD に投資するか (今では同じ価格で 2TB がほぼ手に入ります)、Windows インストールを縮小して /usr 用のスペースを確保します。)

すべてのメタデータがコピーされるわけではないことにも注意してくださいrsync -a。ハード リンク、ファイル ACL、拡張属性も保持する必要があります-HAX。(たとえば、ファイル機能が割り当てられている「setuid のような」バイナリがいくつかあります。)

関連情報