Project

General

Profile

Bug #188

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

lluvia - almost 7 years ago - . Updated about 6 years ago.

Status:
fixed
Priority:
bug
Category:
-
Assignee:
-
% Done:

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

#2

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

#3

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

#4

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

#6

Updated by lukeshu about 6 years ago

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

#7

Updated by lukeshu about 6 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