New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Net modules are not loaded in VMs when using the 2.6.38 kernel #263

Closed
marmarek opened this Issue Mar 8, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@marmarek
Member

marmarek commented Mar 8, 2015

Reported by joanna on 2 Jul 2011 20:29 UTC
When I log into a VM and manually do modprobe iwlagn it works. But not automatically as it was with previous kernel...

This applies not only to the default netvm, but also to all other VMs -- so they do not get eth0 interface by default -- one needs to manually load xennet to get the eth0 interface, even though the corresponding vifX.Y interfaces are created on the corresponding backend domain right from the beginning.

Migrated-From: https://wiki.qubes-os.org/ticket/263

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by joanna on 2 Jul 2011 20:41 UTC
This might also be a race-condition -- e.g. the kernel's udev scripts might be executing before the actual virtual device gets connected? (In case of netvm: before the pcifront starts seeing the pci device?)

Member

marmarek commented Mar 8, 2015

Comment by joanna on 2 Jul 2011 20:41 UTC
This might also be a race-condition -- e.g. the kernel's udev scripts might be executing before the actual virtual device gets connected? (In case of netvm: before the pcifront starts seeing the pci device?)

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 2 Jul 2011 20:51 UTC
Probably this is race condition between udev and mounting /lib/modules...

Member

marmarek commented Mar 8, 2015

Comment by marmarek on 2 Jul 2011 20:51 UTC
Probably this is race condition between udev and mounting /lib/modules...

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by rafal on 4 Jul 2011 10:57 UTC
In fact, udev is started before mounting local filesystems (and now /lib/modules is on local filesystem) - so it is a race likely to end fatally.
Perhaps enabling udev-post init script will retry search for failed modules ? I am not sure it is what it is meant for.

Member

marmarek commented Mar 8, 2015

Comment by rafal on 4 Jul 2011 10:57 UTC
In fact, udev is started before mounting local filesystems (and now /lib/modules is on local filesystem) - so it is a race likely to end fatally.
Perhaps enabling udev-post init script will retry search for failed modules ? I am not sure it is what it is meant for.

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 4 Jul 2011 11:10 UTC
Actually I've fixed it by mounting /lib/modules in initramfs (pre-pivot). But not tested yet...

Member

marmarek commented Mar 8, 2015

Comment by marmarek on 4 Jul 2011 11:10 UTC
Actually I've fixed it by mounting /lib/modules in initramfs (pre-pivot). But not tested yet...

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Mar 8, 2015

Member

Comment by marmarek on 9 Jul 2011 18:17 UTC
fixed in rel 4

Member

marmarek commented Mar 8, 2015

Comment by marmarek on 9 Jul 2011 18:17 UTC
fixed in rel 4

@marmarek marmarek closed this Mar 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment