| Summary: | Psplash fails to unmount /mnt/.psplash | ||
|---|---|---|---|
| Product: | [Runtime] System Startup | Reporter: | Diego <diego.ml> |
| Component: | system-startup | Assignee: | Saul Wold <sgw> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | kevin.tian, otavio, sgw |
| Version: | 1.5 | ||
| Target Milestone: | 1.5.1 | ||
| Hardware: | Other | ||
| OS: | arm | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
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. (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. 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. (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. |
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.