1

I made a script which (tries to) duplicate my live disk /dev/sdb to a second disk /dev/sda, one rsync per partition (full script).

Last step is to install grub on /dev/sda. The method I use is something like :

  1. mount /dev/sda root partition on /mnt/root1
  2. bind-mount {/dev,/sys/,/proc} on /mnt/root1 :
# mount -o bind /sys  /mnt/root1/sys
# mount -o bind /proc /mnt/root1/proc
# mount -o bind /dev  /mnt/root1/dev
  1. run chrooted update-grub and grub-install on /dev/sda :
chroot /mnt/root1 update-grub
chroot /mnt/root1 grub-install /dev/sda
  1. umount the 3 bind-mounts :
# umount /mnt/root1/sys
# umount /mnt/root1/proc
# umount /mnt/root1/dev

However, the /mnt/root1/dev umount fails :

# umount  /mnt/root1/dev 
umount: /mnt/root1/dev: target is busy.

Note: the mount command gives for /dev and /mnt/root1/dev :

udev on /dev type devtmpfs (rw,nosuid,relatime,size=8131896k,nr_inodes=2032974,mode=755,inode64)
udev on /mnt/root1/dev type devtmpfs (rw,nosuid,relatime,size=8131896k,nr_inodes=2032974,mode=755,inode64)

My questions are : How is it a bind-mount can be busy ? Is there a workaround ?

Edit: I was able to umount (in fact hiding the fact it is mounted, if I understand the man page) /mnt/root1/dev with umount --lazy, but it looks incorrect to me.

Related question : https://stackoverflow.com/questions/7878707/how-to-unmount-a-busy-device

Improve this question
4
  • Could be because of some left over resource and/or an other mount done. You should provide the result of this command: findmnt -R -o +PROPAGATION /mnt/root1/dev
    – A.B
    Mar 8 at 8:52
  • @A.B, I will try when it happens again (I cannot reproduce the problem since I used the umount --lazy as a temporary fix).
    – Bruno
    Mar 8 at 8:59
  • BTW, congrats for your script. I won't use it anyway since… I get separate boot partition and use… lilo. Question : why do you worry particularly about mariadb ? Considering there are just an appreciable number of things that should be stopped prior to backing up, I personally prefer… not to start them and therefore always achieve this kind of backups in single user mode.
    – MC68020
    Mar 9 at 0:10
  • @MC68020, my point is not to stop my machine, nor being in single-user mode. This is imperfect (there are some binary data in software like Firefox, etc...), but I had no issue so far. For MariaDB, stopping it allows to simply copy the bases as "binary", it will just start on second disk with old/wrong data, but no fail. Note: I have a daily backup independent from this script; This script is more a matter of having a way of booting with "nearly no errors and nearly everything working", would something happen on my first disk - like some Ubuntu upgrade which messes up everything ;-)
    – Bruno
    Mar 9 at 11:25

1 Answer 1

Reset to default
1

Starting with misc considerations :

When achieving a similar purpose, I prefer mounting :

  • mount --types proc /proc /mnt/root1/proc This because proc is a special sort of filesystem and I'm not sure it will always be recognized automagically. BTW, because of its purpose and nature, it does not need to (should not ?) be bound to /proc

  • For /sys and /dev, I prefer :

A : mount --rbind /sys /mnt/root1/sys (mount --rbind /dev /mnt/root1/dev)
Because I need the mount to be recursive (subdirs of /sys and /dev should also feel concerned)

B : mount --make-rslave /mnt/root1/sys (mount --make-rslave /mnt/root1/dev)
This, regarding your problem, being the key point.

Because a slave mount receives propagation from its master, but any not vice-versa, mount and umount events will only propagate towards it.

This keypoint being guaranteed, you should then be able to umount -R /mnt/root1/dev.

Improve this answer
4
  • Thanks, I did read a little yesterday about these options when looking for my error; I will try to adapt my script when I understand the basics, starting with the difference between bind and slave (I did not know about slave mount before yesterday).
    – Bruno
    Mar 9 at 11:31
  • My main issue here is in fact that I cannot reproduce the problem (it happened once only, and I used the script quite often - 50-100 times ?). I think I will have to close this issue later today if I cannot get more information on what could have happened. Also, for these kind of devices, maybe I could simply use -t umount option if the first umount fails, I don't see any risk on this kind of filesystem.
    – Bruno
    Mar 9 at 11:46
  • @Bruno : (cf comment #1) These (bind and slave) are two different things. You do need to bind, then, unless accepting default, specify the type of the mount (shared / slave / private mount / unbindable) I separated the two steps because that is what I do, it is possible that the two actions can be mixed into a single mount instruction, I did not check.
    – MC68020
    Mar 9 at 13:13
  • looking again at documentation, I don't see how using a slave mount could solve the issue, because the binded mount itself could not be unmounted. It is not a question of propagating anything to the "master" (/dev). Imagine that something makes this binded device busy for some reason (like a magic process doing a cd in the mount dir), being a slave or not will not change anything. Or do I miss something ?
    – Bruno
    Mar 10 at 8:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.