5244 2013-09-20 09:56:37 +0000 Psplash fails to unmount /mnt/.psplash 2013-11-18 22:16:29 +0000 1 1 11 Runtime System Startup system-startup 1.5 Other arm RESOLVED FIXED Medium normal 1.5.1 1 diego.ml sgw kevin.tian otavio sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 37013 0 diego.ml 2013-09-20 09:56:37 +0000 I'm on a core-image-base image on a i.MX6Q Boundary Devices Nitrogen6x. One of the last things I get at boot, just before login, is: umount: /mnt/.psplash: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) and the same at shutdown: Disabling non-boot CPUs ... CPU1: shutdown CPU2: shutdown CPU3: shutdown Power down. umount: /mnt/.psplash: target is busy. (In some cases useful info about processes that use the device is found by lsof(8) or fuser(1)) If I try to "umount /mnt/.psplash" after login I can unmount it correctly, so it's probably just trying to umount it too early. 37147 1 sgw 2013-09-24 21:58:46 +0000 Is this reproducible after the first boot? I was able to reproduce the first failure during boot once, but not on subsequent boot ups. Can you add an "fuser /mnt/.psplash to your /etc/init.d/rc I think there is a race condition and the psplash is not finishing before the umount occurs. 37157 2 diego.ml 2013-09-25 08:03:59 +0000 (In reply to comment #1) > Is this reproducible after the first boot? I was able to reproduce the first > failure during boot once, but not on subsequent boot ups. > > Can you add an "fuser /mnt/.psplash to your /etc/init.d/rc I think there is > a > race condition and the psplash is not finishing before > the umount occurs. Yeah, it's just a matter of istants, because I've added hacky line to rc: fuser /mnt/.psplash cat /proc/$(fuser /mnt/.psplash | cut -d" " -f1)/comm and sometimes I get: 73 psplash while sometimes I get: 73 cat: /proc/73/comm: No such file or directory and then I get no error from umount. So yeah, umount should wait for psplash to finish, not just hope it finished. 37955 3 sgw 2013-10-15 22:30:24 +0000 Since you can get consistent failure, can you try to following. Since we know psplash is exiting, it's safe to umount regardless of the state of the process, so I wonder if the -l (lazy option) would help and if not that, the -f (force), again just edit the /etc/init.d/rc file and add that option to the umount and reboot. Please report the results here. 38192 4 diego.ml 2013-10-28 09:52:38 +0000 (In reply to comment #3) > Since you can get consistent failure, can you try to following. > > Since we know psplash is exiting, it's safe to umount regardless of the > state > of the process, so I wonder if the -l (lazy option) would help and if not > that, > the -f (force), again just edit the /etc/init.d/rc file and add that option > to > the umount and reboot. > > Please report the results here. Adding the "-l" option to umount seems to fix the problem. Tried 10 reboots and I did not encounter the error anymore. 38887 5 sgw 2013-11-18 22:16:29 +0000 http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=f9729f473d60d126723f212f289c8e553f4dfa02