web-dev-qa-db-ja.com

Ubuntuがrootとして間違ったパーティションをマウントするのはなぜですか？

私は、Ubuntuが実際のディスクではなく/として別のディスクにあるルートパーティションのバックアップをマウントするという問題をいじっています。この問題は、ルートパーティションをddによるバックアップに複製することによって引き起こされるUUIDの衝突によって引き起こされたと思います（ LVMパーティションのUUIDを永続的にリセットするにはどうすればよいですか？ ） 。 UUIDの問題は解決したようですが、Ubuntuは/として間違ったパーティションで起動し続けます。

df出力の関連行（OSはデンマーク向けに構成されています）：

Filsystem                      1K-blocks     Brugt   Tilbage Brug% Monteret på
/dev/mapper/raidgroup-osbackup  51369596  31800880  16936168   66% /

問題は、/dev/sda1を/にマウントする必要があることです。さて、blkidは言います（関連する行だけが示されています）：

/dev/sda1: UUID="32579810-0388-416d-bb49-7031ac2c2975" TYPE="ext4" 
/dev/mapper/raidgroup-osbackup: UUID="7f36c980-8936-451c-b307-11d2678bb455" TYPE="ext4"

そしてfstabは言う（関連する行のみ）：

# / was on /dev/sda1 during installation
UUID=32579810-0388-416d-bb49-7031ac2c2975 /               ext4    errors=remount-ro 0       1

私が見る限り、現在の/dev/sda1は実際には/にマウントされているはずですが、mtabも確認しているように、そうではありません。

/dev/mapper/raidgroup-osbackup / ext4 rw,errors=remount-ro 0 0

これは私にはあまりにも進んでいます...fstabが正しく構成されているように見えるときに、間違ったパーティションがマウントされる原因は何ですか？

linuxubuntumountfstabuuid
3
Thomas Arildsen

起動時に間違ったファイルシステムがマウントされている場合は、grub構成を編集する必要があります。最初に次のことを試すことができます。

update-grub

生成された構成は、grubのバージョンに応じて、/boot/grub/menu.lstまたは/boot/grub/grub.cfgになります。私はあなたが後者（grub2の新しいバリエーション）を持っていると仮定しています。 --set=root uuid...のような行の構成を確認し、それらが正しいかどうかを確認します。そうでない場合は、ファイルを編集し（編集しないコメントは無視して）、再起動します。その後、正しいルートファイルシステムが正しくなり、update-grubを再度実行すると、構成が正しくなります。

3
wurtel