[lxc-devel] call to setup_dev_symlinks with lxc.autodev

[Michael H. Warfield]

On Thu, 2014-04-17 at 10:23 -0500, Serge Hallyn wrote:
> Quoting William Dauchy (wdauchy at gmail.com):
> > On Thu, Apr 17, 2014 at 5:07 PM, Michael H. Warfield <mhw at wittsend.com> wrote:
> > > Ok...  Now I see what you're doing.  Thank you.
> > >
> > > When your initial scripts create the system disk image and populate
> > > the /dev directory, why are they not creating those symlinks.  They are
> > > required per the kernel's Documentation/devices.txt doc.  They're listed
> > > in the "Compulsory" section meaning your custom image is not in
> > > compliance with the Linux kernel documentation (i.e. broken).
> > 
> > hm. I said in a previous post they are already created.
> > the symlink function is just not returning EEXIST unless I'm listing
> > the directory.

> That's the intriguing part :)

> So what does /dev look like on the physical media?

Hmmm...  I'm actually wondering if any of this has to do with /proc and
timing of when it's mounted (if it's mounted) in the container.  All of
those links are pointing to an absolute path in /proc/self/.  Could that
somehow have an impact on the error codes we're getting back?  If so,
why is the fact that it's read-only a factor (or maybe it isn't) and why
is doing an "ls" on /dev "fixing" the problem?

He's doing that ls in the mount hook which is in the host namespace and
the symlinks point at the hosts /proc/self/ but so is the call to
setup_dev_symlinks.

That code is calling SYSERR.  But I don't see where the exact error
messages that where printed out.  Just that "it would probably fail".  I
think we need to see an exact debug log output of the failure case to
evaluate it further.  I want to know what the exact error message
resulting from a failure is.

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw at WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20140417/25f7c15f/attachment-0001.sig>