☰

/etc/fstabの無効なルートエントリにもかかわらず、システムは正常に起動します。

tag-icon • tag-icon boot fstab
/etc/fstabの無効なルートエントリにもかかわらず、システムは正常に起動します。

次のディスク構造があります。

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無視されます。

おすすめ記事