12

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)

sourcejedi
  • 48,311
  • 17
  • 143
  • 296
Philippos
  • 13,237
  • 2
  • 37
  • 76
  • 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 `chroot`ing into the tmpfs, which would still leave the rootfs underneath and unable to be unmounted. – sourcejedi May 17 '18 at 09: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 '18 at 06: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](https://unix.stackexchange.com/questions/349849/mv-cannot-move-home-to-home-old-device-or-resource-busy/349859#349859) 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 '18 at 08: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 '18 at 08:57

1 Answers1

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.

Christian Fritz
  • 133
  • 6