Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #63930 > unrolled thread
| Started by | Steve McIntyre <steve@einval.com> |
|---|---|
| First post | 2019-04-26 03:20 +0200 |
| Last post | 2019-04-27 03:10 +0200 |
| Articles | 6 — 2 participants |
Back to article view | Back to linux.debian.kernel
Missing virtio/scsi modules for arm64? Steve McIntyre <steve@einval.com> - 2019-04-26 03:20 +0200
Re: Missing virtio/scsi modules for arm64? Ben Hutchings <ben@decadent.org.uk> - 2019-04-26 20:10 +0200
Re: Missing virtio/scsi modules for arm64? Steve McIntyre <steve@einval.com> - 2019-04-26 23:50 +0200
Re: Missing virtio/scsi modules for arm64? Ben Hutchings <ben@decadent.org.uk> - 2019-04-27 01:10 +0200
Re: Missing virtio/scsi modules for arm64? Steve McIntyre <steve@einval.com> - 2019-04-27 01:50 +0200
Re: Missing virtio/scsi modules for arm64? Steve McIntyre <steve@einval.com> - 2019-04-27 03:10 +0200
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2019-04-26 03:20 +0200 |
| Subject | Missing virtio/scsi modules for arm64? |
| Message-ID | <xQXGV-4SQ-1@gated-at.bofh.it> |
Hey folks,
I;m just trying to do a buster install of arm64 (using buster d-i RC1)
in a qemu VM, and it's failing to find the virtio cdrom. Checking into
this, it looks like we're missing some modules in the installer
environment. Going back to alpha 5 (kernel 4.19.12-1), we get the
following modules loaded:
Module Size Used by
efivars 20480 0
nls_utf8 16384 1
isofs 49152 1
sr_mod 32768 1
cdrom 61440 1 sr_mod
virtio_scsi 20480 1
scsi_mod 233472 2 virtio_scsi,sr_mod
virtio_net 49152 0
virtio_blk 20480 0
net_failover 20480 1 virtio_net
failover 16384 1 net_failover
gpio_keys 20480 0
virtio_pci 28672 0
virtio_mmio 20480 0
virtio_ring 28672 5 virtio_mmio,virtio_scsi,virtio_pci,virtio_blk,virtio_net
virtio 16384 5 virtio_mmio,virtio_scsi,virtio_pci,virtio_blk,virtio_net
In RC1 (4.19.28-2), we only get:
Module Size Used by
gpio_keys 20480 0
virtio_pci 28672 0
virtio_mmio 20480 0
virtio_ring 28672 2 virtio_mmio,virtio_pci
virtio 16384 2 virtio_mmio,virtio_pci
and if I look for things like virtio_scsi or sr_mod they're just not
in the initramfs any more which will explain what's going on. Ben, I
can see that in d-i you've changed the package lists recently (i.e. in
between the 2 d-i releases):
commit 5b3bcf67a7d8ba7745612a449cede24afeb97015
Author: Ben Hutchings <ben@decadent.org.uk>
Date: Tue Feb 12 21:18:40 2019 +0000
build/pkg-lists: Make {hyperv,virtio}-modules packages optional
I intend to remove these udebs in a later upload of linux, moving
the drivers into per-driver-class packages.
and I'm guessing these changes are related to what I'm seeing. Can you
suggest what we should be doing to fix things up, please? I'm at a
total loss to see where amd64 is gettting d-i modules from nowadays,
and arm64 should be reasonably similar in terms of things like block
device support modules here.
Cheers,
Steve
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich
[toc] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2019-04-26 20:10 +0200 |
| Message-ID | <xRdsl-6bY-1@gated-at.bofh.it> |
| In reply to | #63930 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 2019-04-26 at 02:17 +0100, Steve McIntyre wrote:
> Hey folks,
>
> I;m just trying to do a buster install of arm64 (using buster d-i RC1)
> in a qemu VM, and it's failing to find the virtio cdrom. Checking into
> this, it looks like we're missing some modules in the installer
> environment.
[...]
> commit 5b3bcf67a7d8ba7745612a449cede24afeb97015
> Author: Ben Hutchings <ben@decadent.org.uk>
> Date: Tue Feb 12 21:18:40 2019 +0000
>
> build/pkg-lists: Make {hyperv,virtio}-modules packages optional
>
> I intend to remove these udebs in a later upload of linux, moving
> the drivers into per-driver-class packages.
>
> and I'm guessing these changes are related to what I'm seeing. Can you
> suggest what we should be doing to fix things up, please? I'm at a
> total loss to see where amd64 is gettting d-i modules from nowadays,
> and arm64 should be reasonably similar in terms of things like block
> device support modules here.
For amd64 CD-ROMs, the package list for CD-ROMs is split between
build/pkg-lists/cdrom/amd64.cfg and
build/pkg-lists/cdrom/isolinux/amd64.cfg. The latter is where, for
example, ata-modules is listed.
In general, installer builds that include(d) virtio-modules, and aren't
meant for netboot, should include scsi-modules. (scsi-{common,extra}-
modules are also mentioned in some lists, but they no longer exist.)
I think this patch will fix arm64:
--- a/build/pkg-lists/cdrom/arm64.cfg
+++ b/build/pkg-lists/cdrom/arm64.cfg
@@ -13,6 +13,8 @@ virtio-modules-${kernel:Version} ?
usb-storage-modules-${kernel:Version}
# USB and firewire cdroms both need this.
scsi-core-modules-${kernel:Version}
+# Support for SCSI cdroms.
+scsi-modules-${kernel:Version}
# Real ATA hardware needs this.
sata-modules-${kernel:Version}
--- END ---
There are two other lists that look like they might be for netboot-ish
builds, but I'm not sure:
build/pkg-lists/generic/s390.cfg
build/pkg-lists/generic/s390x.cfg
Ben.
--
Ben Hutchings
It is impossible to make anything foolproof
because fools are so ingenious.
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2019-04-26 23:50 +0200 |
| Message-ID | <xRgTf-88a-1@gated-at.bofh.it> |
| In reply to | #63932 |
On Fri, Apr 26, 2019 at 07:00:39PM +0100, Ben Hutchings wrote:
>On Fri, 2019-04-26 at 02:17 +0100, Steve McIntyre wrote:
>> Hey folks,
>>
>> I;m just trying to do a buster install of arm64 (using buster d-i RC1)
>> in a qemu VM, and it's failing to find the virtio cdrom. Checking into
>> this, it looks like we're missing some modules in the installer
>> environment.
>[...]
>> commit 5b3bcf67a7d8ba7745612a449cede24afeb97015
>> Author: Ben Hutchings <ben@decadent.org.uk>
>> Date: Tue Feb 12 21:18:40 2019 +0000
>>
>> build/pkg-lists: Make {hyperv,virtio}-modules packages optional
>>
>> I intend to remove these udebs in a later upload of linux, moving
>> the drivers into per-driver-class packages.
>>
>> and I'm guessing these changes are related to what I'm seeing. Can you
>> suggest what we should be doing to fix things up, please? I'm at a
>> total loss to see where amd64 is gettting d-i modules from nowadays,
>> and arm64 should be reasonably similar in terms of things like block
>> device support modules here.
>
>For amd64 CD-ROMs, the package list for CD-ROMs is split between
>build/pkg-lists/cdrom/amd64.cfg and
>build/pkg-lists/cdrom/isolinux/amd64.cfg. The latter is where, for
>example, ata-modules is listed.
>
>In general, installer builds that include(d) virtio-modules, and aren't
>meant for netboot, should include scsi-modules. (scsi-{common,extra}-
>modules are also mentioned in some lists, but they no longer exist.)
Cool, thanks.
>I think this patch will fix arm64:
>
>--- a/build/pkg-lists/cdrom/arm64.cfg
>+++ b/build/pkg-lists/cdrom/arm64.cfg
>@@ -13,6 +13,8 @@ virtio-modules-${kernel:Version} ?
> usb-storage-modules-${kernel:Version}
> # USB and firewire cdroms both need this.
> scsi-core-modules-${kernel:Version}
>+# Support for SCSI cdroms.
>+scsi-modules-${kernel:Version}
> # Real ATA hardware needs this.
> sata-modules-${kernel:Version}
>
>--- END ---
Hmmm, looking at my local mirror, I think there's another problem
then. I don't see scsi-modules-4.19* for arm64. Looks like we're
missing kernel config for arm64 here. Could you add that too please?
>There are two other lists that look like they might be for netboot-ish
>builds, but I'm not sure:
>
>build/pkg-lists/generic/s390.cfg
>build/pkg-lists/generic/s390x.cfg
Pass - I know ~nothing about s390/x.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"Because heaters aren't purple!" -- Catherine Pitt
[toc] | [prev] | [next] | [standalone]
| From | Ben Hutchings <ben@decadent.org.uk> |
|---|---|
| Date | 2019-04-27 01:10 +0200 |
| Message-ID | <xRi8F-BQ-3@gated-at.bofh.it> |
| In reply to | #63935 |
[Multipart message — attachments visible in raw view] — view raw
On Fri, 2019-04-26 at 22:40 +0100, Steve McIntyre wrote: [...] > Hmmm, looking at my local mirror, I think there's another problem > then. I don't see scsi-modules-4.19* for arm64. Looks like we're > missing kernel config for arm64 here. Could you add that too please? [...] We are building it, but remember that it's built from the linux-signed-arm64 source package now. Ben. -- Ben Hutchings Teamwork is essential - it allows you to blame someone else.
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2019-04-27 01:50 +0200 |
| Message-ID | <xRiLn-P0-3@gated-at.bofh.it> |
| In reply to | #63936 |
On Sat, Apr 27, 2019 at 12:07:05AM +0100, Ben Hutchings wrote: >On Fri, 2019-04-26 at 22:40 +0100, Steve McIntyre wrote: >[...] >> Hmmm, looking at my local mirror, I think there's another problem >> then. I don't see scsi-modules-4.19* for arm64. Looks like we're >> missing kernel config for arm64 here. Could you add that too please? >[...] > >We are building it, but remember that it's built from the >linux-signed-arm64 source package now. Gah, of course! I'd forgotten that. :-) -- Steve McIntyre, Cambridge, UK. steve@einval.com "This dress doesn't reverse." -- Alden Spiess
[toc] | [prev] | [next] | [standalone]
| From | Steve McIntyre <steve@einval.com> |
|---|---|
| Date | 2019-04-27 03:10 +0200 |
| Message-ID | <xRk0N-1IK-5@gated-at.bofh.it> |
| In reply to | #63937 |
On Sat, Apr 27, 2019 at 12:39:31AM +0100, Steve McIntyre wrote: >On Sat, Apr 27, 2019 at 12:07:05AM +0100, Ben Hutchings wrote: >>On Fri, 2019-04-26 at 22:40 +0100, Steve McIntyre wrote: >>[...] >>> Hmmm, looking at my local mirror, I think there's another problem >>> then. I don't see scsi-modules-4.19* for arm64. Looks like we're >>> missing kernel config for arm64 here. Could you add that too please? >>[...] >> >>We are building it, but remember that it's built from the >>linux-signed-arm64 source package now. > >Gah, of course! I'd forgotten that. :-) Build testing locally suggests this does fix the problem, so I've pushed that change (and a similar one for armhf). Thanks Ben! -- Steve McIntyre, Cambridge, UK. steve@einval.com Who needs computer imagery when you've got Brian Blessed?
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web