Open bdh1993 opened 1 year ago
Because using -l
doesn't actually unmount it. It removes the mount entry, but as long as the files remain open, it's still busy and the same as being mounted in the background. It's only when the last reference to all open files is dropped that the umount actually happens. I may be wrong, but that's my understanding, and without having evidence that it's 100% safe, I don't want to risk it.
It would be better to understand why umount
doesn't work int he first place. I haven't seen that problem in a while, so I assume it was an issue that has been resolved in an upstream package somewhere.
Thank you. I build it on my computer. When building, I opened another window or searched the website. In the process, you have to umount, but I think it's because there's a row hanging in the other process. Would this issue be more free if build from Docker?
When building, I opened another window or searched the website. In the process, you have to umount, but I think it's because there's a row hanging in the other process.
Sorry, I don't quite get what you mean there.
I build it on my computer.
Out of curiosity, what distro are you running?
Would this issue be more free if build from Docker?
I don't know, I don't use docker for my own builds.
Thank you.
I didn't just use the computer for build.
I was doing other things when the Raspberry Pi build script was running. For example, using package installation commands etc.
Another process meant this.
I guessed that umount did not work because another operation was in progress.
I build the Raspberry Pi arm64 version from the Linux mint distribution.
If you look at the unmount() function in the "script > common" path, no option is applied. Therefore, a lot of target is busy situations occur during the build.
You can solve this problem by attaching the "-lf" option when you do umount.
It worked in the local build. (I don't know if it's build from Docker.)
There was no problem when using the generated image. Is there any other problem I don't know?