| 2011-09-23 19:04:50 |
Colin Watson |
bug |
|
|
added bug |
| 2011-09-23 19:05:30 |
Brad Figg |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2011-09-23 19:07:22 |
Colin Watson |
description |
xenbus_probe_frontend is currently modular in several flavours, notably in the i386/generic-pae and amd64/server 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 that isn't set up such that we can build installer images from it, and I think I'm happier building those 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! |
xenbus_probe_frontend is currently modular in several flavours, notably in the i386/generic-pae and amd64/server 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! |
|
| 2011-09-23 19:07:59 |
Colin Watson |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2011-09-23 19:08:01 |
Tim Gardner |
nominated for series |
|
Ubuntu Natty |
|
| 2011-09-23 19:08:01 |
Tim Gardner |
bug task added |
|
linux (Ubuntu Natty) |
|
| 2011-09-23 19:08:01 |
Tim Gardner |
nominated for series |
|
Ubuntu Oneiric |
|
| 2011-09-23 19:08:01 |
Tim Gardner |
bug task added |
|
linux (Ubuntu Oneiric) |
|
| 2011-09-23 19:08:09 |
Colin Watson |
bug task added |
|
hw-detect (Ubuntu) |
|
| 2011-09-23 19:08:11 |
Tim Gardner |
linux (Ubuntu Natty): status |
New |
Confirmed |
|
| 2011-09-23 19:08:19 |
Colin Watson |
hw-detect (Ubuntu Oneiric): status |
New |
Triaged |
|
| 2011-09-23 19:08:22 |
Colin Watson |
hw-detect (Ubuntu Oneiric): importance |
Undecided |
High |
|
| 2011-09-23 19:09:06 |
Colin Watson |
description |
xenbus_probe_frontend is currently modular in several flavours, notably in the i386/generic-pae and amd64/server 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! |
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! |
|
| 2011-09-23 19:09:43 |
Colin Watson |
hw-detect (Ubuntu Natty): status |
New |
Triaged |
|
| 2011-09-23 19:09:46 |
Colin Watson |
hw-detect (Ubuntu Natty): importance |
Undecided |
High |
|
| 2011-09-23 19:23:24 |
Tim Gardner |
linux (Ubuntu Natty): assignee |
|
Tim Gardner (timg-tpi) |
|
| 2011-09-23 19:23:30 |
Tim Gardner |
linux (Ubuntu Oneiric): assignee |
|
Tim Gardner (timg-tpi) |
|
| 2011-09-23 19:55:20 |
Colin Watson |
bug task added |
|
debian-installer (Ubuntu) |
|
| 2011-09-23 19:55:36 |
Colin Watson |
nominated for series |
|
Ubuntu P-series |
|
| 2011-09-23 19:55:36 |
Colin Watson |
bug task added |
|
debian-installer (Ubuntu P-series) |
|
| 2011-09-23 19:55:36 |
Colin Watson |
bug task added |
|
hw-detect (Ubuntu P-series) |
|
| 2011-09-23 19:55:36 |
Colin Watson |
bug task added |
|
linux (Ubuntu P-series) |
|
| 2011-09-23 19:55:51 |
Colin Watson |
linux (Ubuntu P-series): status |
New |
Invalid |
|
| 2011-09-23 19:56:13 |
Colin Watson |
hw-detect (Ubuntu P-series): status |
New |
Invalid |
|
| 2011-09-23 19:56:39 |
Colin Watson |
debian-installer (Ubuntu Natty): status |
New |
Won't Fix |
|
| 2011-09-23 19:56:51 |
Colin Watson |
debian-installer (Ubuntu Oneiric): status |
New |
Won't Fix |
|
| 2011-09-23 19:57:17 |
Colin Watson |
debian-installer (Ubuntu): importance |
Undecided |
Medium |
|
| 2011-09-23 19:57:17 |
Colin Watson |
debian-installer (Ubuntu): status |
New |
Triaged |
|
| 2011-09-23 19:57:32 |
Colin Watson |
debian-installer (Ubuntu P-series): importance |
Undecided |
Medium |
|
| 2011-09-23 19:57:32 |
Colin Watson |
debian-installer (Ubuntu P-series): status |
New |
Triaged |
|
| 2011-09-23 20:33:01 |
Tim Gardner |
linux (Ubuntu Natty): status |
Confirmed |
Won't Fix |
|
| 2011-09-23 20:33:14 |
Tim Gardner |
linux (Ubuntu Oneiric): status |
Confirmed |
Won't Fix |
|
| 2011-09-23 20:33:28 |
Tim Gardner |
linux (Ubuntu): status |
Confirmed |
Invalid |
|
| 2011-09-23 22:15:40 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/hw-detect/ubuntu |
|
| 2011-09-23 22:29:28 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/hw-detect/natty-proposed |
|
| 2011-09-23 22:42:43 |
Colin Watson |
description |
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! |
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! |
|
| 2011-09-23 22:44:00 |
Colin Watson |
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.
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! |
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! |
|
| 2011-09-24 05:48:39 |
Launchpad Janitor |
hw-detect (Ubuntu Oneiric): status |
Triaged |
Fix Released |
|
| 2011-09-24 06:08:36 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/hw-detect |
|
| 2011-09-26 15:44:15 |
Martin Pitt |
hw-detect (Ubuntu Natty): status |
Triaged |
Fix Committed |
|
| 2011-09-26 15:44:21 |
Martin Pitt |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2011-09-26 15:44:25 |
Martin Pitt |
bug |
|
|
added subscriber SRU Verification |
| 2011-09-26 15:44:30 |
Martin Pitt |
tags |
|
verification-needed |
|
| 2011-09-26 16:24:29 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/natty-proposed/hw-detect |
|
| 2011-09-27 14:00:40 |
Colin Watson |
tags |
verification-needed |
verification-done |
|
| 2011-10-03 17:07:54 |
Launchpad Janitor |
hw-detect (Ubuntu Natty): status |
Fix Committed |
Fix Released |
|
| 2011-10-07 19:05:54 |
Simon Déziel |
bug |
|
|
added subscriber Simon Déziel |
| 2011-11-20 11:16:27 |
Launchpad Janitor |
branch linked |
|
lp:~ubuntu-core-dev/debian-installer/ubuntu |
|
| 2011-11-20 11:20:14 |
Launchpad Janitor |
debian-installer (Ubuntu Precise): status |
Triaged |
Fix Released |
|
| 2013-09-07 10:23:19 |
Launchpad Janitor |
branch linked |
|
lp:debian/hw-detect |
|
