[Bug 857662] Re: Should xenbus_probe_frontend be built-in?

[Colin Watson]

** Description changed:

+ Stable update justification:
+ 
+ Impact: When installing in a Xen domU, the installer fails to find any network interfaces.
+ Development branch: Fixed in hw-detect 1.81ubuntu3 by loading xenbus_probe_frontend if we seem to be running under the Xen hypervisor.  (It should not be catastrophic if we load this even under other conditions, but it should be a bit more efficient this way.)
+ Patch: http://bazaar.launchpad.net/~ubuntu-core-dev/hw-detect/natty-proposed/revision/1466
+ TEST CASE: Start up d-i in a Xen domU and run through to the point where it detects network interfaces.  Without this patch, it should fail; with this patch, it should work.
+ Regression potential: I think the worst thing that can plausibly happen here is an error message via debconf if the module fails to load.  The /sys/hypervisor/type and /sys/bus/xen checks around this code are mainly to defend against this possibility in non-Xen installations.
+ 
+ Original report follows:
+ 
  xenbus_probe_frontend is currently modular in several flavours, notably
  in the i386/generic-pae and amd64/generic flavours which we use to build
  d-i Xen netboot images.  The purpose of xenbus_probe_frontend appears to
  be to connect to the Xen bus and then emit uevents for any devices it
  finds there.  Once it's loaded, autoloading for such things as xen-
  netfront works fine, allowing the guest to find its network interface.
  I believe that xen-blkfront works in a similar way.
  
  However, with xenbus_probe_frontend modular, the early stages of the
  installer plus the early stages of normal system boot need to load
  xenbus_probe_frontend in order to find block and network devices.  If
  we're going to do this, it seems as though we might as well just build
  xenbus_probe_frontend into the kernel.  It seems to me that it should be
  pretty harmless on non-Xen systems, although of course somebody
  knowledgeable should verify that.
  
  Right now, it's built in for the -virtual flavours, but we aren't
  currently building installer images from that, and I think I'm happier
  building them directly from -generic-pae / -generic anyway.
  
  This is true in both Natty and Oneiric.  If you can't do this for
  Oneiric and/or are unwilling to do this in a stable update for Natty,
  then please let me know so that I can add a workaround to the installer
  in time.  Thanks!

** Description changed:

  Stable update justification:
  
  Impact: When installing in a Xen domU, the installer fails to find any network interfaces.
  Development branch: Fixed in hw-detect 1.81ubuntu3 by loading xenbus_probe_frontend if we seem to be running under the Xen hypervisor.  (It should not be catastrophic if we load this even under other conditions, but it should be a bit more efficient this way.)
  Patch: http://bazaar.launchpad.net/~ubuntu-core-dev/hw-detect/natty-proposed/revision/1466
- TEST CASE: Start up d-i in a Xen domU and run through to the point where it detects network interfaces.  Without this patch, it should fail; with this patch, it should work.
+ TEST CASE: Start up d-i in a Xen domU and run through to the point where it detects network interfaces.  Without this patch, it should fail; with this patch, it should work.  Note that for testing you will need to use a kernel/initrd from natty-proposed (which I'll need to upload separately after this patch is accepted), and in production after this upload is validated you'll need to use a kernel/initrd from natty-updates.
  Regression potential: I think the worst thing that can plausibly happen here is an error message via debconf if the module fails to load.  The /sys/hypervisor/type and /sys/bus/xen checks around this code are mainly to defend against this possibility in non-Xen installations.
  
  Original report follows:
  
  xenbus_probe_frontend is currently modular in several flavours, notably
  in the i386/generic-pae and amd64/generic flavours which we use to build
  d-i Xen netboot images.  The purpose of xenbus_probe_frontend appears to
  be to connect to the Xen bus and then emit uevents for any devices it
  finds there.  Once it's loaded, autoloading for such things as xen-
  netfront works fine, allowing the guest to find its network interface.
  I believe that xen-blkfront works in a similar way.
  
  However, with xenbus_probe_frontend modular, the early stages of the
  installer plus the early stages of normal system boot need to load
  xenbus_probe_frontend in order to find block and network devices.  If
  we're going to do this, it seems as though we might as well just build
  xenbus_probe_frontend into the kernel.  It seems to me that it should be
  pretty harmless on non-Xen systems, although of course somebody
  knowledgeable should verify that.
  
  Right now, it's built in for the -virtual flavours, but we aren't
  currently building installer images from that, and I think I'm happier
  building them directly from -generic-pae / -generic anyway.
  
  This is true in both Natty and Oneiric.  If you can't do this for
  Oneiric and/or are unwilling to do this in a stable update for Natty,
  then please let me know so that I can add a workaround to the installer
  in time.  Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to debian-installer in Ubuntu.
https://bugs.launchpad.net/bugs/857662

Title:
  Should xenbus_probe_frontend be built-in?

Status in “debian-installer” package in Ubuntu:
  Triaged
Status in “hw-detect” package in Ubuntu:
  Triaged
Status in “linux” package in Ubuntu:
  Invalid
Status in “debian-installer” source package in Natty:
  Won't Fix
Status in “hw-detect” source package in Natty:
  Triaged
Status in “linux” source package in Natty:
  Won't Fix
Status in “debian-installer” source package in Oneiric:
  Won't Fix
Status in “hw-detect” source package in Oneiric:
  Triaged
Status in “linux” source package in Oneiric:
  Won't Fix
Status in “debian-installer” source package in p-series:
  Triaged
Status in “hw-detect” source package in p-series:
  Invalid
Status in “linux” source package in p-series:
  Invalid

Bug description:
  Stable update justification:

  Impact: When installing in a Xen domU, the installer fails to find any network interfaces.
  Development branch: Fixed in hw-detect 1.81ubuntu3 by loading xenbus_probe_frontend if we seem to be running under the Xen hypervisor.  (It should not be catastrophic if we load this even under other conditions, but it should be a bit more efficient this way.)
  Patch: http://bazaar.launchpad.net/~ubuntu-core-dev/hw-detect/natty-proposed/revision/1466
  TEST CASE: Start up d-i in a Xen domU and run through to the point where it detects network interfaces.  Without this patch, it should fail; with this patch, it should work.  Note that for testing you will need to use a kernel/initrd from natty-proposed (which I'll need to upload separately after this patch is accepted), and in production after this upload is validated you'll need to use a kernel/initrd from natty-updates.
  Regression potential: I think the worst thing that can plausibly happen here is an error message via debconf if the module fails to load.  The /sys/hypervisor/type and /sys/bus/xen checks around this code are mainly to defend against this possibility in non-Xen installations.

  Original report follows:

  xenbus_probe_frontend is currently modular in several flavours,
  notably in the i386/generic-pae and amd64/generic flavours which we
  use to build d-i Xen netboot images.  The purpose of
  xenbus_probe_frontend appears to be to connect to the Xen bus and then
  emit uevents for any devices it finds there.  Once it's loaded,
  autoloading for such things as xen-netfront works fine, allowing the
  guest to find its network interface.  I believe that xen-blkfront
  works in a similar way.

  However, with xenbus_probe_frontend modular, the early stages of the
  installer plus the early stages of normal system boot need to load
  xenbus_probe_frontend in order to find block and network devices.  If
  we're going to do this, it seems as though we might as well just build
  xenbus_probe_frontend into the kernel.  It seems to me that it should
  be pretty harmless on non-Xen systems, although of course somebody
  knowledgeable should verify that.

  Right now, it's built in for the -virtual flavours, but we aren't
  currently building installer images from that, and I think I'm happier
  building them directly from -generic-pae / -generic anyway.

  This is true in both Natty and Oneiric.  If you can't do this for
  Oneiric and/or are unwilling to do this in a stable update for Natty,
  then please let me know so that I can add a workaround to the
  installer in time.  Thanks!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/857662/+subscriptions