3

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

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
    Commented Mar 8, 2022 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
    Commented Mar 8, 2022 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
    Commented Mar 9, 2022 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
    Commented Mar 9, 2022 at 11:25

2 Answers 2

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.

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
    Commented Mar 9, 2022 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
    Commented Mar 9, 2022 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
    Commented Mar 9, 2022 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
    Commented Mar 10, 2022 at 8:56
0

How is it a bind-mount can be busy?

Probably there is a background process still running which has a busy causing reference to the /dev mount from within the chroot. Check with lsof.

Is there a workaround?

Terminate the processes that holds such /dev references.


I had exactly the same problem scenario. I booted from a live cd and mounted the root fs partition from the hard disk in order to run a dnf command under chroot. After that was done I exited the chroot and unmounted all the bind mounts (/dev /proc /sys /run), but the dev bind mount refused to umount.

(root) localhost-live: /media>dmesg | grep devtmpfs
[    0.592936] devtmpfs: initialized
(root) localhost-live: /media>mount | grep devtmpfs
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=4089246,mode=755,inode64)
devtmpfs on /media/luks_sda4/dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=4089246,mode=755,inode64)
(root) localhost-live: /media>umount /media/luks_sda4/dev
umount: /media/luks_sda4/dev: target is busy.
(root) localhost-live: /media>umount --force /media/luks_sda4/dev
umount: /media/luks_sda4/dev: target is busy.
(root) localhost-live: /media>fuser /media/luks_sda4/dev
/media/luks_sda4/dev:    25rc
(root) localhost-live: /media>ps aux | sed -n '1p; / 25 /p'
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root          25  0.0  0.0      0     0 ?        S    05:44   0:00 [kdevtmpfs]
root        7984  0.0  0.0 222560  2304 pts/1    S+   07:58   0:00 sed -n 1p; / 25 /p
(root) localhost-live: /media>

While searching for a solution I came over this blog post which suggested running lsof on the directory, and that gave a super clear hint on what the problem was:

(root) localhost-live: /media>lsof luks_sda4
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ssh-agent 4007 root  cwd    DIR  253,2     4096    2 luks_sda4
ssh-agent 4007 root  rtd    DIR  253,2     4096    2 luks_sda4
(root) localhost-live: /media>

I have keychain installed and when starting the chroot I was asked to provide password for the ssh key (as normal). Obviously as part of that a ssh-agent instance was started in the background, but it was not terminated by exiting the chroot.

With that knowledge, unmounting the dev bind mount was straight forward:

(root) localhost-live: /media>kill -HUP 4007
(root) localhost-live: /media>lsof luks_sda4
(root) localhost-live: /media>umount /media/luks_sda4/dev 
(root) localhost-live: /media>mount | grep devtmpfs
devtmpfs on /dev type devtmpfs (rw,nosuid,seclabel,size=4096k,nr_inodes=4089246,mode=755,inode64)
(root) localhost-live: /media>

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .