Massimiliano Ghilardi

`rm -rf` does not complain about attempts to remove non-existing files, so your ``` cd /tmp rm -rf fstransform.loop.* ``` probably did nothing: those files were either inside the sub-directory...

Ok, now it starts to make sense :) The `efi` subdirectory is visible and all those ` .fstransform.loop.*` files are still there too. Step 1: check what's inside the `efi`...

So, that's the key issue: for some reason, that `efi` subdirectory cannot be removed even if it's empty. The most common reason is having another partition mounted under it, see...

This is getting weirder. I am trying to guess the reason for this issue. Maybe some daemon automatically mounts the EFI partition inside that `efi` subdirectory as soon as `/dev/sda1`...

This is expected, it's the `/dev/sda1` mounted on `/mnt` that I instructed you to do. But nothing mounted on `/mnt/efi`. So there's still no evidence of *why* `/mnt/efi` cannot be...

As expected. I have run out of ideas and (almost) out of diagnostic tools at this point. Maybe a file system check could help, but if there was some corruption...

This is even more strange. Then where else is `/dev/sda1` mounted? Try ``` mount | grep /dev/sda1 ```

Ok, at least it's a clue. That `/dev/sda1` must be mounted somewhere else, and probably its subdirectory `efi` is used as mount point too. But finding *where* depends on the...

Yes, definitely. Both `fstransform` and `xfs_repair` need exclusive access to the partition they use, and otherwise give errors - this explains most of the errors above. One last thing to...

It means the process ID 11409 has `/mnt/efi` as current directory. The command `ps -aux | grep 11409` should tell what is it.