Ludovic Courtès <l...@gnu.org> writes:
> Ouch. Could you check what /var/log/messages reports? > > Once you’ve reproduced the hang, could you attach GDB to shepherd and > get a backtrace? > > gdb -p 1 > bt > > (I recommend doing that in a VM rather than on your main machine!) > I have unfortunately been unable to reproduce the full shepherd hang, even though I have followed the exact same procedure as before. I still experience that the command `herd restart networking` hangs indefinitely the first time after adding a VLAN, but now this has not triggered the whole shepherd to hang afterwards anymore. The basic error 17 still comes any time I try to start networking service while having a VLAN configured. > > You mentioned in your other message that the example from the manual > works fine. Could you try and reduce your config until you find which > bit makes it fail? The configuration I have already attached is as minimal as it is possible. It only includes the mandatory OS fields and a minimal static-networking-configuration. I have already found which bit makes it fail. It is the use of VLAN for any normal network link. VLANs seem to only work for bond devices as in the example. The reproduction steps are maybe a little over-complicated however, and are only necessary in order to reproduce the full "shepherd hangs" bug, which I now am unable to reproduce anyway. But what I believe is the root of the problem is the error 17 on starting the networking service. This can be reproduced much more simply and reliably by just starting a VM the normal way with the static-networking snippet already enabled when building it. So here are the new simplified reproduction steps for reproducing only the error 17 and unfunctional VLAN networking: Use the OS config from my first post, but uncomment the static networking block. Build and run the VM with `$(guix system vm minimal.scm)`. That's it. > Cc’ing Alexey and Julien who may know more. > > Thanks, > Ludo’. Alexey Abramov <leven...@mmer.org> writes: > Hi Lars, > > I see, Could you please, replace the device name to "myvlan" and not > "myvlan@eth0" in the network-address. > > Even though ip link (iproute2) shows you 'myvlan@eth0' this is not an > actual name of the interfaces. > I have tried with your suggestion, but everything behaves exactly the same.