13

I need to resize2fs the root partition of an embedded device. Since it doesn't have an alternate boot option, I used an tmpfs, moved and restated everything until I finally was able to umount /dev/mmcblk0p1. But bad luck:

$ umount /dev/mmcblk0p1 
umount: /dev/mmcblk0p1: not mounted
$ resize2fs /dev/mmcblk0p1 
resize2fs 1.42.12 (29-Aug-2014)
resize2fs: Device or resource busy while trying to open /dev/mmcblk0p1
Couldn't find valid filesystem superblock.
$ fsck /dev/mmcblk0p1 
fsck from util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
/dev/mmcblk0p1 is in use.
e2fsck: Cannot continue, aborting.

Strange! A busy unmounted file system. It seems to me, that the journal still has it's hands on the device:

root       112  0.0  0.0      0     0 ?        S    14:13   0:00 [jbd2/mmcblk0p1-]

Turn journaling off, you say? Here comes the hen-and-egg-game:

$ tune2fs -O ^has_journal /dev/mmcblk0p1 
tune2fs 1.42.12 (29-Aug-2014)
The needs_recovery flag is set.  Please run e2fsck before clearing
the has_journal flag.

So how to stop that? It's still running in rescue mode, can't be kill -9ed. How to get rid of it? (I'm on Debian Jessie)

4
  • Note that umount /dev/foo is not how the underlying system call works. Myself I would use umount /path/to/mount. I would find your question somewhat clearer if you did so instead. For example it would prove that you had used pivot_root to pivot your rootfs where it can be unmounted, as opposed to chrooting into the tmpfs, which would still leave the rootfs underneath and unable to be unmounted.
    – sourcejedi
    May 17, 2018 at 9:24
  • Yes, I did use /path/to/mount to unmount it, this umount /dev/mmcblk0p1 was just to clarify that this file system is not mounted somewhere else.
    – Philippos
    May 18, 2018 at 6:49
  • 1
    I really expect, if the FS is marked as dirty (mounted), and JBD is still running... that's because it's still mounted. E.g. what does /proc/self/mountinfo show? I wonder if you can pinky-swear you're not using mount namespaces... see here for suggestions on how to find and inspect other mount namespaces. It assumes you are in the initial PID namespace, i.e. you're not running inside a sandbox where you can't see all the processes on the system.
    – sourcejedi
    May 18, 2018 at 8:55
  • If you think the kernel has left kernel threads still holding the device after you have unmounted it everywhere, that would be a kernel bug, so it means you should post the specific kernel version.
    – sourcejedi
    May 18, 2018 at 8:57

1 Answer 1

Reset to default
0

What worked for me was fuser -km MOUNTPOINT. This will kill any process still using files in that mount point. Be careful though! In my case this logged me out from Gnome.

You must log in to answer this question.

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