次のディスク構造があります。
sda1 : Windows
sda2 : an old Linux distribution
sda3 : a new Linux distribution
sda4 : data partition
grubをインストールし、起動時にシステムを選択しました。私は今sda3でのみ新しいLinuxディストリビューションを使用していますが、うまくいきます。私は起動時にCDROMとデータパーティションをマウントするように/ etc / fstabファイルを設定してきました。
私は最近、新しいLinuxシステム（sda3）の/ etc / fstabファイルが次のように見えました：
/dev/sda2 / ext4 errors=remount-ro 0 1 #NOTE THIS ENTRY HAS SDA2!
/dev/sda4 /media/me_user/datapart ext4 defaults 1 1
/dev/sr0 /media/cdrom0 auto ro,user,noauto,unhide 0 0
ルートエントリが間違っているようです。 /dev/sda3でなければなりません（誤って変更したことは間違いありません）。ただし、システムが正常に動作して起動すると、ホームフォルダはsda2ではなくsda3にのみあります。
/etc/fstabからルートエントリの行を削除してみました。その後、起動時にログインを要求する端末プロンプトが表示されます。それでもログインできますが、グラフィックは起動しません。
ルートエントリがsda3で動作するようにfstabファイルを変更しましたが、問題を明確にしたいと思います。私のシステムが正常に動作し、sda3のホームフォルダにアクセスしていますが、/etc/fstabのルートエントリがsda2用であるのはなぜですか？
答え1
最近同様の問題が発生し、調査を行いました。私の理解は、次の場所に正しいパーティションが設定されているので動作することです。
- カーネルコマンドライン
root=<UUID of />パラメータ。 Satwellはこれについてもっと書いた。 - ブートローダの設定。たとえば、
grub-gnulinux-simple-<UUID of />と--set=root <UUID /boot>（UUIDと同じでも同じでもない/）とします。
/etc/fstabファイルシステムが起動プロセスの一部として読み取られ、マウントされます（/書き込み可能な[ rw]が再マウントされています）。再インストールするには、/etc/fstab次のオプションを使用してください。 satwellが書いたように、これは/ファイルからマウントラインを削除するときに発生する問題を説明できます。間違ったパーティションのUUIDで動作するのはなぜですか？おそらく、mount()システムコールが再マウントするときに間違ったUUIDを無視し、すでに設定されている[正しい]UUIDを使用している可能性があります。
からman 2 mount：
既存のインストールを再インストール
および
sourceパラメータはfilesystemtype無視されます。
答え2
/etc/fstabルートとしてマウントされるファイルシステムを直接制御しません。 （つまり、ルートファイルシステムを読み取る前にマウントする必要があります/etc/fstab。）
ルートファイルシステムは通常、カーネルコマンドライン引数で指定されます。実行してcat /proc/cmdline確認すると、root=/dev/sda3またはが表示されることがありますroot=UUID=<uuid of /dev/sda3>。
これらのパラメータは通常、ブートローダ設定で設定されます。ここの詳細は、使用しているディストリビューションによって異なりますが、 grub を使用していると仮定すると、おそらくまたはで/boot/grub/grub.cfgその設定を見つけることができます/boot/grub2/grub.cfg。この設定が正しい場合は、正しいルートファイルシステムをマウントする必要があります。
/それでは、起動を取り除くと起動が失敗するのはなぜですか/etc/fstab？システム起動プロセスの一部/がに指定されたオプションで再インストールされます。/etc/fstabこれはエラーの原因になる可能性があります。