¿Por qué el sistema usaría una partición si no está montada?

He estado migrando mi sistema de btrfs a ext4 después de tener problemas de rendimiento con máquinas virtuales. Tengo dos discos duros en mi computadora portátil para trabajar. He movido con éxito mi partición de inicio, pero los mismos pasos que utilicé no funcionan para root.

Progreso hasta ahora:

Tenía ddmi partición raíz desde /dev/sda3adentro /dev/sdb3. Modifiqué /etc/fstablo siguiente:

$ 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

y ejecutar sudo mkinitcpio -p linux. Parece funcionar. Puedo arrancar montando la partición en el segundo disco. dfmuestra:

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

Entonces, claramente, sdb3está montado, no sda3. Aquí está el paso problemático: cuando trato de formatear sda3, que supuestamente no se usa, obtengo lo siguiente:

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

sda3Está en uso. ¿Cómo y por qué podría estar en uso?

Según el comentario de casey, la salida de 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)

Según el comentario de Warwick, desmontando:

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

Montar y desmontar sda3 en otro lugar funciona con éxito, pero no cambia nada.

Actualización: comportamiento más sospechoso:

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

Después de montar sda3, sdb3 ya no está montado. Extraño, ¿eh?

Según mikeserv:

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

Esto es muy esperado, ya que sdb3 es btrfs y se supone que está montado en la raíz. Desde mi archivo mkinitcpio.conf:

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

Me lo imaginé. Mi gestor de arranque no se configuró correctamente. Suena obvio, ¿verdad? Modificar fstab no califica como configurar el gestor de arranque. Tuve que cambiar una línea /boot/syslinux/syslinux.cgfpara referirme a la partición de arranque correcta.

Dicho esto, no había necesidad de arrancar desde el segundo disco en primer lugar. Podría haber evitado este problema completando todo el proceso en un entorno en vivo y trabajando para ejecutarlo mkinitcpio.