Bug #188

[libremkchroot] doesn't always umount when exiting with error

lluvia - over 10 years ago - . Updated over 9 years ago.

% Done:



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.



Updated by lukeshu about 10 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 about 10 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 about 10 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 10 years ago

Once I merge changes from upstream devtools, this will be fixed with certainty; it will be handled by nspawn.


Updated by lukeshu over 9 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.

Also available in: Atom PDF