A note on virtio blk and net modules
Bug #1533382 reported by
Dimitri John Ledkov
This bug affects 1 person
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| debian-installer (Ubuntu) |
New
|
Undecided
|
Unassigned | ||
| Xenial |
New
|
Undecided
|
Unassigned | ||
| linux (Ubuntu) |
Fix Released
|
Medium
|
Tim Gardner | ||
| Xenial |
Fix Released
|
Medium
|
Tim Gardner | ||
Bug Description
If VIRTIO_BLK and VIRTIO_NET become =m, instead of current =y the following should happen:
VIRTIO_NET should be in the nic-modules udeb, and seeded into the d-i builds.
VIRTIO_BLK can stay in block-modules-udeb, and in general is not needed in the d-i build, as it can be fetched over the VIRTIO_NET provided network.
VIRTIO_BLK needs to be available (e.g. server udebs pool, for offline s390x installations)
on the kernel side
virtio-blk and virtio-nic most certainly need to be the in the "main" package of a flavor, and not in -extra.
Revision history for this message
| Dimitri John Ledkov (xnox) wrote | #1 |
Revision history for this message
| Brad Figg (brad-figg) wrote Missing required logs. | #2 |
| Changed in linux (Ubuntu): | |
| status: | New → Incomplete |
| Changed in linux (Ubuntu): | |
| importance: | Undecided → Medium |
| tags: | added: bot-stop-nagging kernel-da-key |
| Changed in linux (Ubuntu): | |
| status: | Incomplete → Triaged |
Revision history for this message
| Tim Gardner (timg-tpi) wrote | #3 |
| Changed in linux (Ubuntu Xenial): | |
| assignee: | nobody → Tim Gardner (timg-tpi) |
| status: | Triaged → Fix Committed |
Revision history for this message
| Launchpad Janitor (janitor) wrote | #4 |
Download full text (17.3 KiB)
| Changed in linux (Ubuntu Xenial): | |
| status: | Fix Committed → Fix Released |
To post a comment you must log in.
<infinity> xnox: Why did you add block-modules to generic/s390x.cfg?
<infinity> xnox: "Add block-modules (depends on virtio-modules) for s390x" seems pointless with the kernel change to make those builtin. I think I'll revert that commit.
<infinity> xnox: Or was there some other reason?
* infinity shrugs and leaves it there for now.
* mwenning has quit (Quit: Leaving)
* foka_ (~foka@
<xnox> infinity, so apw wanted to make it a module on all platforms, rather than changing it to =y on s390x.
<xnox> infinity, so i made the change, just in case. The net difference now is adding nbd module to the installer.
<xnox> infinity, i don't know if apw will revert it to a =m everywhere. If he does, we will need block-modules in all/most d-i flavours.
<infinity> xnox: It should still be in virtio-modules anyway (if it's =m), I'd say it's a bug that it was in block-modules.
<infinity> xnox: But this works for now, I won't be too picky (already uploaded your change).
<xnox> ok.
<xnox> infinity, let me point that virtio-blk was in the wrong package to apw. cause we were slightly dilusional about it.
<xnox> infinity, the whole bug was i went to boot cloud images, and virtio-blk was not in the initramfs, and was only in the -extra image....
<infinity> xnox: Err, surely this was about virtio-net anyway?
<xnox> anyway all good now.
<infinity> xnox: virtio-blk shouldn't be needed to boot the installer, it should be fetched over the network.
<xnox> virtio-net and virtio-blk. Both were =m in -extra package and in block/virtio-udebs split
<xnox> and i do need virtio-net and virtio-blk in the cloud-images initramfs.
<xnox> virtio-blk can be fetched over the network true, in the d-i case.
<infinity> Right, moving them to -virtual (either in image or =y) is correct, and yes, you need them in the cloud-init initrd, but that has nothing to do with d-i.
<infinity> So, we probably should revert your change before we forget this conversation. :P
<xnox> right. and apw wants to drop them from =y -> =m everywhere, as otherwise they are always loaded, and never unloaded.
<infinity> And then make sure the kernel debs/udebs are correct if they go =m
<xnox> right.
<xnox> let me copy the irc log into a bug with actions to be done.
<infinity> I'm not convinced virtio-modules needs to exist at all, except maybe as a dep of block-modules and nic-modules, if it has some common bits.
<infinity> virtio-net should be in nic- and virtio-blk should be in block-, the more I think about it.
<infinity> There's nothing about those drivers that make them any more "special" than any other block or nic device.
<xnox> there is virtio-scsi and virtio-something else.
<xnox> in virtio-udebs.
<xnox> but yeah vitio-nic should be in nic-modules