This was fixed in package schroot 1.6.10-3 available in Ubuntu Artful
and later.
** No longer affects: click (Ubuntu)
** Also affects: schroot (Ubuntu Trusty)
Importance: Undecided
Status: New
** Also affects: schroot (Ubuntu Vivid)
Importance: Undecided
Status: New
**
schroot (1.6.10-3) unstable; urgency=medium
* By default mark all mounts done by schroot-mount as "private"
to avoid bad interactions caused by systemd's default of "shared"
that resulted in failure to unmount them.
--
You received this bug notification because you are a member of
** Changed in: schroot (Debian)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
Hi,
I have /home and /home/${USER}/Data on different partitions which are mounted
based on /etc/fstab specs.
When I had automatic updates of my kits in ubuntu sdk, every time it attempted
to update it umounted my two home related partitions. This problem was solved
by de-activating auto
Not fixed on wily.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
To manage notifications about this bug go to:
I am still seeing this on Wily.
$ dpkg -s schroot | grep Version
Version: 1.6.10-1ubuntu2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks
@edvice: If you look at duplicates, which are recent, you will see that
this problem is not fixed, at least on Wily.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs,
For me this bug fixed in schroot package version 1.6.8-1ubuntu1.1 by
https://bugs.launchpad.net/ubuntu/+source/schroot/+bug/1398523.
Can anyone else confirm that bug fixed?
** Tags added: verification-needed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
I have same error on Ubuntu 14.04 with ecryptfs. Change or comment /home in
/etc/schroot/click/fstab does not take effect.
Switching from kernel 3.19.0-29-generic to 3.16.0-50-generic or
3.13.0-64-generic solved the problem.
--
You received this bug notification because you are a member of
Once again wasted an hour for nothing downloading tons of packages, as
click very happily downloads the whole package set only to delete it and
fail afterall:
Processing triggers for ca-certificates (20141019ubuntu0.15.04.1) ...
Updating certificates in /etc/ssl/certs...
173 added, 0 removed;
I've submitted a proposed fix for this bug to schroot upstream/Debian
and linked the bug to this one.
** Bug watch added: Debian Bug tracker #786566
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786566
** Also affects: schroot (Debian) via
** Changed in: schroot (Debian)
Status: Unknown = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
To
Confirming that I got the same mount loop issue than Mitchell with the
line #15, (thousands of mounts). The worst is that as the sessions are
not cleaned up on a forced shutdown, the next login after reboot will
restart the schroots, and so the mount hell.
Has to do that either with another admin
Wow - this experience has been painful. Have just spent an hour or so
debugging my machine to work out why it froze each time I logged into my
main user account. No terminals worked, nothing, nada. Finally logged
into another user (not with admin rights), used the password from my
main account to
** Changed in: schroot (Ubuntu)
Assignee: (unassigned) = Tyler Hicks (tyhicks)
** Changed in: schroot (Ubuntu)
Status: Confirmed = In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Confirming the workaround in comment #15 works.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
To manage notifications
Does this also bite users who simply have their /home on a separate
partition? Disregarding encryption?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating
W dniu 13.05.2015 o 14:11, Kyle Fazzari pisze:
Does this also bite users who simply have their /home on a separate
partition? Disregarding encryption?
I'm on full-disk-encrypted btrfs with a separate @home and this works
fine AFAICT. Maybe it's mounting /home/$USER itself that's the issue?
--
On 2015-05-13 12:49:45, Michał Sawicz wrote:
W dniu 13.05.2015 o 14:11, Kyle Fazzari pisze:
Does this also bite users who simply have their /home on a separate
partition? Disregarding encryption?
I'm on full-disk-encrypted btrfs with a separate @home and this works
fine AFAICT. Maybe it's
Adding 'none /home none rslave 0 0' to /etc/schroot/click/fstab allowed
me to successfully create a new chroot.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating
Tyler, I got bit by this issue this morning (vivid). The rbind addition
outlined in #5 seems to have resolved it for me as well.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using
** Also affects: schroot (Ubuntu)
Importance: Undecided
Status: New
** Changed in: schroot (Ubuntu)
Importance: Undecided = High
** Changed in: schroot (Ubuntu)
Status: New = Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Hi Scott - The bug that you're experiencing is different than this bug.
I've opened bug #1438942 to track your issue. Please confirm what I
placed in the description and set the bug to confirmed. Thanks!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I've recreated this in a cloud image.
See the steps to do so here in this attachment.
** Attachment added: description of how to recreate in cloud image
https://bugs.launchpad.net/ubuntu/+source/click/+bug/1427264/+attachment/4353785/+files/notes.txt
--
You received this bug notification
Seems related to this, after using schroot with overlay on /dev/shm, I
end up with multiple /dev/shm mounts on top of one another.
I'll try and collect more data and will comment back here or file a new
bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
Hmm I take that back, a reboot solved my issues...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
To manage
I just noticed a mistake that I made a couple times in comment #5. I
said that the /home/ mount point inside the schroot needs to be made
recursively private (rprivate). However, what I meant to say is that the
/home/ mount point inside the schroot needs to recursively be made a
slave (rslave).
Hi Tyler,
yes since 15.04 switches to systemd which mounts everything as MS_SHARED
by default, I expect a few more such bugs. What you recommend sounds
right.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Note you use slave and private somewhat interchangeably above. Which
you want to use will depend on the behavior you want to see if the uesr
tries to umount something under /home. If there might be devices or
remotes which need to be freed, then you'll wan to use slave so that the
chroot can't
Serge - I've subscribed you to this bug in hopes that you could tell us
if you expect any problems with making the change suggested at the
bottom of comment #5 since I know you have a lot of experience in mount
namespaces.
To summarize the problem, schroot doesn't handle /home/$USER being a
mount
the fstab to change is /etc/schroot/click/fstab
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
To manage notifications
This bug seems to be caused by the way recursive bind mounting and
unmounting works:
foo@sec-vivid-amd64:~$ grep home\/foo /proc/mounts
/dev/loop0 /home/foo ext4 rw,relatime,data=ordered 0 0
foo@sec-vivid-amd64:~$ sudo mount -R /home /tmp/home
foo@sec-vivid-amd64:~$ grep home\/foo /proc/mounts
The issue is around mount propagation. The /home/ directory is being
recursively bound into the schroot tree. When the schroot tree is
recursively unmounted and SCHROOT_DIR/home/foo is unmounted, that
unmount event is being propagated to the original /home/foo mount point.
To prevent that from
This issue is not specific to eCryptfs. It is specific to a user's home
directory being a mount point. For example, I can reproduce this issue
with ext4:
foo@sec-vivid-amd64:~$ grep home\/foo /proc/mounts
/dev/loop0 /home/foo ext4 rw,relatime,data=ordered 0 0
foo@sec-vivid-amd64:~$ schroot -c
https://code.launchpad.net/~mvo/click/lp1319790-chroot-fstab might
address the issue?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind
35 matches
Mail list logo
