lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Missing system directories in chroot [Was: Creating a chroot f


From: Vadim Zeitlin
Subject: Re: [lmi] Missing system directories in chroot [Was: Creating a chroot for cross-building lmi]
Date: Fri, 23 Sep 2016 16:17:07 +0200

On Thu, 22 Sep 2016 22:14:05 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-09-16 23:22, Vadim Zeitlin wrote:
...
GC> >  The only possibility I see is that schroot bind-mounts /dev itself. This
GC> > would explain the above, but does it really do this?
GC> 
GC> Yes.

 Thanks for confirming this, I was starting to get really worried about my
understanding of how basic stuff works under Linux! Turns out I was just
misunderstanding how schroot worked.

GC> Anyway, in forthcoming updates to 'README.schroot' I plan to use a
GC> "plain" chroot as long as it works.

 FWIW this looks like a good idea to me.

GC> BTW, I tried making a "plain" debian 'sid' chroot in a similar way, but
GC> that seems not to work, at least not without further tweaking:

 Sorry, I'm not sure to understand if you managed to make it work, by
rerunning debootstrap several times, or still failed? Would you like me to
try creating a sid chroot (I already have one, but it was created a long
time ago)?

GC> Oh, and if .git/config contains
GC>   [remote "origin"]
GC>     url = git://git.savannah.nongnu.org/lmi.git
GC> instead of "address@hidden:/srv/git/lmi.git", and ~/.ssh/ contains only
GC> DSA keys that savannah no longer accepts, then every git command except
GC> 'push' will work, but 'push' will give "connection reset by peer".

 How nice. I understand there are good reasons for dropping support for DSA
keys but a better error message would have been really helpful.

GC> I don't want to say how much time I spent trying to get 'git push' to
GC> work, largely because I assumed it was an schroot problem.

 It's surely too late to be helpful, but the first thing I do in case of
problems with git network operations is to set GIT_SSH to "ssh-v" where

        % cat ~/bin/ssh-v
        #!/bin/sh
        exec /usr/bin/ssh -v "$@"

 This usually gives enough information to diagnose the problem.

 Regards,
VZ


reply via email to

[Prev in Thread] Current Thread [Next in Thread]