VMでパフォーマンスの問題が発生した後、システムをbtrfsからext4に移行しています。使用するラップトップに2つのハードドライブがあります。ホームパーティションを正常に移動しましたが、ルートと同じ手順を実行しても機能しません。
これまでの進展:
ルートパーティションを/dev/sda3
から/dev/sdb3
にdd
しました。 /etc/fstab
を次のように変更しました。
$ cat /etc/fstab
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
# UUID=95f13c34-96ca-49e3-bcb2-ff594df31506
/dev/sdb3 / btrfs rw,noatime,ssd,space_cache,discard 0 0
# UUID=0fe04f59-599f-41e2-ac30-2ad0f17a9727
/dev/sda2 /boot ext2 rw,relatime 0 2
# UUID=44741e0f-924a-4841-80ef-2132bef84182
/dev/sda4 /home ext4 rw,noatime,discard 0 0
Sudo mkinitcpio -p linux
を実行します。動作するようです。 2つ目のディスクにパーティションをマウントすることで起動できます。 df
は以下を示します:
$ df
Filesystem Size Used Avail Use% Mounted on
/dev/sdb3 28G 18G 9.8G 65% /
したがって、明らかに、sdb3
ではなくsda3
がマウントされます。これが問題のあるステップです。未使用の可能性があるsda3
をフォーマットしようとすると、次のようになります。
$ Sudo mkfs.ext4 /dev/sda3
[Sudo] password for stew:
mke2fs 1.42.11 (09-Jul-2014)
/dev/sda3 contains a btrfs file system
Proceed anyway? (y,n) y
/dev/sda3 is apparently in use by the system; will not make a filesystem here!
sda3
は使用中です。どのようにそしてなぜそれがおそらく使用されているのでしょうか?
mount | grep sd
/dev/sdb3 on / type btrfs (rw,noatime,ssd,discard,space_cache)
/dev/sda4 on /home type ext4 (rw,noatime,discard,data=ordered)
/dev/sda2 on /boot type ext2 (rw,relatime)
$ Sudo umount /dev/sda3
umount: /dev/sda3: not mounted
Sda3を別の場所にマウントおよびアンマウントしても問題なく機能しますが、何も変わりません。
$ mount | grep sd
/dev/sdb3 on / type btrfs (rw,noatime,ssd,discard,space_cache)
/dev/sda4 on /home type ext4 (rw,noatime,discard,data=ordered)
/dev/sda2 on /boot type ext2 (rw,relatime)
$ Sudo mount /dev/sda3 mnt
[Sudo] password for stew:
$ mount | grep sd
/dev/sda3 on / type btrfs (rw,noatime,ssd,discard,space_cache)
/dev/sda4 on /home type ext4 (rw,noatime,discard,data=ordered)
/dev/sda2 on /boot type ext2 (rw,relatime)
/dev/sda3 on /home/stew/mnt type btrfs (rw,relatime,ssd,discard,space_cache)
Sda3をマウントすると、sdb3はマウンターではなくなります。変だよね?
$ rmmod btrfs
rmmod: ERROR: Module btrfs is in use
Sdb3はbtrfsであり、ルートにマウントされることになっているため、これは非常に期待されています。私のmkinitcpio.confファイルから:
MODULES=""
HOOKS="base udev autodetect modconf block filesystems keyboard fsck"
私はそれを考え出した。ブートローダーが正しく設定されていません。明白に聞こえますよね? fstabを変更しても、ブートローダーを構成することはできません。正しいブートパーティションを参照するには、/boot/syslinux/syslinux.cgf
の行を変更する必要がありました。
とはいえ、そもそも2番目のディスクから起動する必要はありませんでした。ライブ環境でプロセス全体を完了し、chrootしてmkinitcpio
を実行することで、この問題を回避できたはずです。