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
** Chang
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 Ubun
** 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
T
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 update.
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:
https://b
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 fa
@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, crea
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 is
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 Ubun
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; do
** 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 man
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
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug
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 g
** 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.
https://bugs.launchpad.net/bu
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. May
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?
--
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 framewor
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 ab
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 e
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 subsc
** 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
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
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 notifications
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
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.
https://bugs.launchpad.net
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 pin
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). The
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 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 happ
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
/de
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 clic
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 ab
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 mo
35 matches
Mail list logo