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
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
Touch seeded p
@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
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Tit
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
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecrypt
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
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
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using e
** 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
Touch seeded packages, which is subscribed to click in Ubuntu.
htt
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
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
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
** Changed in: schroot (Debian)
Status: Unknown => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to
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
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
** 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
Touch seeded pa
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
Touch seeded package
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
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating
the fstab to change is /etc/schroot/click/fstab
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
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
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
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
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
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
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
Touch seeded packages, which is subscribed to click in 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 pin
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
Touch seeded pa
Hmm I take that back, a reboot solved my issues...
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issue
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
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs
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
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
Confirming the workaround in comment #15 works.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
** Changed in: schroot (Debian)
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fa
Not fixed on wily.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to click in Ubuntu.
https://bugs.launchpad.net/bugs/1427264
Title:
using ecryptfs, creating frameworks fail to bind mount issues
Status in click package in Ub
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.
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. May
34 matches
Mail list logo