I have a machine with a single SSD and 3 partitions. I want to unmount the entire SSD while staying live so that I can run a firmware upgrade tool on the SSD. I know that unmounting your only disk is not recommended but I figure this is okay in my case since my rootfs is a squashfs which loaded into memory during boot, and the kernel, theoretically, is also mounted in memory. That's why I believe we can unmount all partitions, run the firmware upgrade, and then reboot the system to get back to normal state.

My problem: I cannot unmount sda1

I am able to unmount sda2 (storage space) and sda3 (where some log files are stashed) after repeatedly running the following 2-3 times:

fuser -mv /dev/sda1 -k -9
fuser -mv /dev/sda2 -k -9
fuser -mv /dev/sda3 -k -9

umount -f /dev/sda1
umount -f /dev/sda2
umount -f /dev/sda3

At that point, running

fuser -mv /dev/sda1
fuser -mv /dev/sda2
fuser -mv /dev/sda3

produces the output

                    USER        PID ACCESS COMMAND
/dev/sda1:           root     kernel mount /boot

That tells me that the sda2 and sda3 unmounted successfully but that kernel does not want to let go of the sda1. No matter what I try, sda1 does not unmount

I have also tried to kill the only process linked to sda1 through:

$ ps -ef | grep sda
root       423     2  0 00:19 ?        00:00:00 [jbd2/sda1-8]
$ kill -9 423

but no luck there either.

Note: I can't use any other hardware like a USB stick to help throughout the process.

Update: lsblk produces the following

sda      8:0    0   3.8G  0 disk 
|-sda2   8:2    0   1.9G  0 part 
|-sda3   8:3    0 949.2M  0 part 
`-sda1   8:1    0   957M  0 part /boot 
  • Jbd is the journaling block device. On what is sda1 mounted? The output of lsblk could help clarifying that. You could also try umount -l. If it's only jdb that is blocking the device, it may work because jdb should be running periodically and umount -l should "trigger" at the right time between the executions. It may take some time though.
    – rudib
    Oct 5 '18 at 2:52
  • 1
    Need to double check this, but I believe squashfs decompresses the filesystem on the fly rather rather than at mount time, so it still needs read access to the SSD. If you want a filesystem that works entirely from memory, you might want to try ramdisk or ramfs (via initrd or initramfs, or by doing a chroot/pivot_root into it) rather than squashfs
    – Lie Ryan
    Oct 5 '18 at 2:56
  • @rudib, I update my question to include lsblk output. I also have tried to use umount -l in the past but the jbd2 process still hangs on to sda1.
    – Frankie
    Oct 5 '18 at 15:50
  • @LieRyan, squashfs does decompress on the fly and when squashfs is mounted, the squashfs file is loaded into memory. So linux decompresses on the fly using the copy of the squashfs file that had been loaded to memory at the time of mounting. I ran a test by mounting a squashfs file on a loop device. I then deleted the original squashfs and I could still navigate and view files in the mounted file system. I also noticed that memory usage increased exactly by size of the squashfs file.
    – Frankie
    Oct 5 '18 at 15:55
  • This might not be a perfect solution and may cause damage to the partition: you could open two terminals and do umount -l and then kill -9 in the other. This should trigger the unmount after the kill...
    – rudib
    Oct 5 '18 at 15:56

Thanks, Lie Ryan. The reason why I could not unmount the SSD is beacause rootfs was still using the squashfs file from the SSD. The squashfs file is not loaded in to memory as I had believed but instead it's decompressed on the fly from the original file on the SSD.

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.