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

[Michael H. Warfield]

On Mon, 2014-04-21 at 10:57 -0400, Dwight Engen wrote:
> On Thu, 17 Apr 2014 10:23:00 -0500
> Serge Hallyn <serge.hallyn at ubuntu.com> 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 :)

> Sorry I'm late to the party, was out last week. FWIW I agree with Mike
> that its not really related to autodev, so using that option doesn't make
> sense.

I think it's Serge's turn to be out of pocket for the next few days.

> We could allow the container to start if the symlinks can't be created
> (just return 0 instead of -1), or check for both EROFS and EEXIST
> (if indeed EROFS is what is being returned in this case). This would
> revert us to our old behavior since we didn't used to insist the
> symlinks were there. It seems a little dangerous however, since as Mike
> pointed out Harald's case was a pretty simple shell redirection. I'm
> not sure what else might rely on them.

> Better would be figuring out why we don't see EEXIST until an ls is
> done, which seems quite strange.

Ok...  So, late last week, I posted back and experimental patch that
initially does a stat to check if the link exists and, if it doesn't,
then tries to create it and ignores EEXIST and EROFS.  It's also
overloaded with printouts to tell us more about what's going on.  I'm
waiting on the OP to get back with those results.

The patch doesn't do any harm and implements the symlink process a
little more formally.  But it is instrumented a bit more than I would
stick into production.  If I don't hear anything back by the time Serge
gets back, I'll probably propose a version of that as a formal patch.

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

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/20140422/8e81e149/attachment.sig>