Dlaczego partycja ma być używana przez system, jeśli nie jest zamontowana?

Przeprowadziłem migrację systemu z btrfs na ext4 po napotkaniu problemów z wydajnością maszyn wirtualnych. Mam dwa dyski twarde w moim laptopie do pracy. Udało mi się przenieść partycję domową, ale te same kroki, których użyłem, nie działają dla roota.

Dotychczasowe postępy:

Mam dd„d moja partycja od /dev/sda3do /dev/sdb3. Zmieniłem /etc/fstabna następujące:

$ 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

i biegnij sudo mkinitcpio -p linux. Wydaje się, że działa. Jestem w stanie uruchomić się, instalując partycję na drugim dysku. dfprzedstawia:

$ df
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb3        28G   18G  9.8G  65% /

Oczywiście sdb3jest zamontowany, a nie sda3. Oto problematyczny krok: kiedy próbuję sformatować sda3, który podobno jest nieużywany, otrzymuję:

$ 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!

sda3jest w użyciu. Jak i dlaczego może być w użyciu?

Zgodnie z komentarzem Casey, wyjście mount:

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)

Zgodnie z komentarzem Warwicka odmontowanie:

$ sudo umount /dev/sda3
umount: /dev/sda3: not mounted

Montowanie i podłączanie sda3 w innym miejscu działa pomyślnie, ale niczego nie zmienia.

Aktualizacja: bardziej rybie zachowanie:

$ 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)

Po zamontowaniu sda3, sdb3 nie jest już monterem. Dziwne, co?

Zgodnie z Mikeserv:

$ rmmod btrfs
rmmod: ERROR: Module btrfs is in use

Jest to bardzo oczekiwane, ponieważ sdb3 jest btrfs i powinien być zamontowany do roota. Z mojego pliku mkinitcpio.conf:

MODULES=""
HOOKS="base udev autodetect modconf block filesystems keyboard fsck"

Rozgryzłem to. Mój program ładujący nie został poprawnie skonfigurowany. Brzmi oczywisto, prawda? Modyfikacja fstab nie kwalifikuje się jako konfiguracja bootloadera. Musiałem zmienić wiersz, /boot/syslinux/syslinux.cgfaby odnosił się do poprawnej partycji rozruchowej.

To powiedziawszy, nie było potrzeby uruchamiania drugiego dysku w pierwszej kolejności. Mógłbym uniknąć tego problemu, wykonując cały proces w środowisku na żywo i uruchamiając chroot mkinitcpio.