Bug #188
[libremkchroot] doesn't always umount when exiting with error
100%
Description
For example, I failed my previous command for libremkchroot, and I tried it a second time with the correct arguments, but it wanted to overwrite the mounted system, reporting errors.
Also, I didn't understand what was happening and I tried to remove the jail directory, without checking that my system was mounted in that directory!
It would be a good and simple behavour to unmount if reporting error.
History
Updated by lukeshu over 11 years ago
The relevent place to fix that is in "mkarchroot" (in devtools/chroottools), which currently does this. I assume that it was a bug in a past version of devtools (there have been several releases since this was filed). I'm filing it as "fixed".
Updated by lukeshu over 11 years ago
This is a bug in chroottools' "archroot". Sometimes it doesn't umount, sometimes it does. I have no idea, but it is current.
Updated by lukeshu over 11 years ago
I re-did how signals are handled while the umount function is running. Now I think the only reason it might not umount them is if they were mounted prior to entering the chroot (left by a previous, buggy, version of the script, perhaps?).
I'm marking this at 50%, and will monitor their behavior for a while. If I don't see the scripts leaving mounts as we get closer to releasing "don't break and confuse parabolers", I'll close this.
Updated by lukeshu almost 11 years ago
Once I merge changes from upstream devtools, this will be fixed with certainty; it will be handled by nspawn.
Updated by lukeshu almost 11 years ago
With the version now in git, instead of a literal bind mount, it used `systemd-nspawn --bind`, which means that they won't exist once the process exits. Done.