26

I'm using a rescue-live-system (similar to a live-cd) to fix some issues with my Debian server, like that:

# mkdir -p /mnt/rescue
# mount /dev/md2 /mnt/rescue
# mount --bind /dev /mnt/rescue/dev/
# mount --bind /proc /mnt/rescue/proc/
# mount --bind /sys /mnt/rescue/sys/

Now I can chroot to /mnt/rescue - but after I'm done, how to unmount the filesystem again?

umount: /mnt/rescue: target is busy.
    (In some cases useful info about processes that use
     the device is found by lsof(8) or fuser(1))

I guess it's because dev, proc and sys are bound to the mounted file system. But it's not possible to unmount them either...

3
  • What happens when you try to unmount /mnt/rescue/proc? Are you sure you don't still have processes running in that chroot?
    – Mat
    Commented Jan 20, 2013 at 9:20
  • 2
    Try lsof /mnt/rescue to see what process is using that folder.
    – lmcanavals
    Commented Jan 20, 2013 at 9:22
  • You need to leave the chrooted shell before shutting down.
    – vonbrand
    Commented Jan 21, 2013 at 17:22

5 Answers 5

23
  1. You have to first exit the chroot session, usually a simple exit will do:

    exit
    
  2. Then umount ALL binded directories:

    umount /mnt/rescue/dev/
    umount /mnt/rescue/proc/
    umount /mnt/rescue/sys/
    
  3. Then:

    umount /mnt/rescue
    

In case you were worried that sync isn't used here, note that it has no influence on whether unmounting is possible. Unmounting flushes pending writes anyway (it has to, because there'd be nowhere for them to go after the unmounting). The presence of a chrooted process is irrelevant (except in that it prevents unmounting). In normal system operation, sync has no observable effect. sync only makes a difference if a device is physically disconnected without having been unmounted or if the system crashes while the device is mounted.

5
  • 1
    thanks, that's it... my mistake was trying to unmount /sys/ instead of /mnt/rescue/sys/ ...
    – q9f
    Commented Jan 20, 2013 at 17:21
  • 2
    The sync is totally useless. Commented Jan 20, 2013 at 22:54
  • 2
    @Gilles Can you elaborate abit more why sync is useless? Does it become useless in current kernel? Or only in this case(rescue mode)? I put it there just in case there are huge pending write to disk that will prevent umount after exiting chroot.
    – John Siu
    Commented Jan 21, 2013 at 2:44
  • 5
    @JohnSiu sync has no influence on whether unmounting is possible. Unmounting flushes pending writes anyway (it has to, because there'd be nowhere for them to go after the unmounting). The presence of a chrooted process is irrelevant (except in that it prevents unmounting). In normal system operation, sync has no observable effect. sync only makes a difference if a device is physically disconnected without having been unmounted or if the system crashes while the device is mounted. Commented Jan 21, 2013 at 10:35
  • @Gilles I understand your point now. Thank you!!
    – John Siu
    Commented Jan 21, 2013 at 10:50
20

Execute the below command to force and Detach the filesystem from the filesystem hierarchy, and cleanup all references to the filesystem as soon as it is not busy anymore.

umount -lf /mnt/rescue
2
  • there's no comment here regarding the nested mounts. does this clean them up safely? can you unmount a filesystem contianing a chroot after this, if all processes have terminated?
    – fuzzyTew
    Commented Oct 31, 2020 at 10:40
  • Be careful with this one when using recursive mounts, e.g: --rbind. Subsequent recursive mounts of /sys and /dev don't mount the entire tree!
    – Saad Malik
    Commented Feb 14, 2021 at 16:58
4

The reason why you get the 'target is busy.' message is because the mount point (/mnt/rescue) is open in a file browser or in a terminal session, and also the order of unmounting process (here I mean dev/pts should be umounted before dev/ )

Well, in order to successfully umount all fs there :

  • Make sure the mountpoint isn't open in a file browser!
  • After exiting chroot change directory out of chroot dir (cd)!
  • Umount fs respecting the order dev/pts => dev/ => proc/ => sys/ :

    sudo umount /mnt/rescue/dev/pts
    sudo umount /mnt/rescue/dev
    sudo umount /mnt/rescue/proc
    sudo umount /mnt/rescue/sys
    sudo umount /mnt/rescue

3

This is how I do with schroot command on Ubuntu version 10.04 upward:

# list all sessions:
schroot --list --all-sessions
# if the above command does not work, just type `mount`. The bind mount
# points with something like this in the mount path is the session name you want to get:
precise-a4aac8e0-663c-4fec-8fb2-16e4b06557e3 (<chroot_name>-<id>)

# now run this to properly end the session:
schroot -e -c precise-ca6c72e4-0e9f-4721-8a0e-cca359e2c2fd
5
  • perfect thx! on the schroot --help "-c [ --chroot ] arg Use specified chroot" it should actually read: "-c [ --chroot ] arg Use specified chroot SESSION"! ubuntu 20.04 here Commented Dec 2, 2020 at 20:46
  • @AquariusPower in 2020, wonder why docker doesn’t work for you :-? Commented Dec 2, 2020 at 20:50
  • do you think docker could work for a i386 install that can be integrated on the running X server? askubuntu.com/questions/1274951/… Commented Dec 2, 2020 at 22:03
  • @AquariusPower I don’t know how far you want to go with schroot and docker, but this might be helpful: x11docker Commented Dec 2, 2020 at 22:18
  • cool thx! I would have to read more but it seems to run a new X server (inside current one?) but the main point would be security. What I am doing I dont really know if it is as safe as x11docker approach, but what I am doing looks more integrated (like the app looks to be running not from a chroot at all). The whole point, in the end, will be if the applications I want to run will properly run on x11docker as well as I believe they will with schroot (as I havent been able to fully test it yet xD). Commented Dec 2, 2020 at 22:58
0

Exit chroot. In the host system, the command 'mount' will show all the mounted path. (Includes those path which are mounted in chroot.) For example:

binfmt_misc on /home/user/projects/jsroot/proc/sys/fs/binfmt_misc

Then enter chroot environment. In chroot environment run unmount to unmount all path in order. (Sub path must be unmount before parent path.)

unmount /proc/sys/fs/binfmt_misc
unmount /proc/sys
unmount /proc
1
  • ...and if they refuse to unmount, and you're not in the directory... ?
    – Owl
    Commented May 19, 2022 at 13:14

You must log in to answer this question.

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