[05:52] <cpaelzer> good morning
[06:07] <cpaelzer> squid openssl3 fix migrated to -release \o/
[07:28] <mirespace> good morning
[09:01] <athos> good morning!
[09:09] <cpaelzer> hi athos
[09:09] <athos> \o
[09:14] <mirespace> hi athos
[09:36] <utkarsh2102> hey
[09:37] <utkarsh2102> is mysql-server installed by default?
[09:37] <utkarsh2102> that's very weird if it is
[09:39] <mirespace> ahasenack: it seems all test passed for rsync :)
[17:36] <Odd_Bloke> ahasenack: Artifactory's Debian repo type handles generating the indices for the debs you upload: it needs to read the debs for (at least) name and version to do so.
[17:37] <Odd_Bloke> So if you're mirroring zstd debs or uploading your own debs built with a dpkg that uses zstd by default, they'll never show up in your repositories from apt's POV.
[17:38] <ahasenack> ah, it generates a repo
[17:38] <ahasenack> ok
[17:39] <ahasenack> Odd_Bloke: and is there an update for artifactory? Or this repo type is dead in the water regarding debs that use zstd?
[17:39] <Odd_Bloke> There's been no public communication about them doing anything to support zstd.
[17:40] <Odd_Bloke> (And it's closed-source, so no way of knowing if they're working on it or what. ¬.¬)
[17:40] <sdeziel> there must be more than just the name and version that is extract because otherwise, that's doable simply by looking at the filename
[17:41] <Odd_Bloke> Epochs, e.g., are not represented in the filename.
[17:42] <sdeziel> right :)
[17:43] <Odd_Bloke> Yeah, I had some naive code to parse name/version and ended up having to bin it because of things like that.
[17:43] <Odd_Bloke> So I'm only a couple of weeks ahead of you on discovering that. ;)
[17:44] <Odd_Bloke> (And, also, there's no restriction on naming in Artifactory, and anyone with upload perms can PUT.  So it can't assume that the filename will match a pattern, or is even accurate to the actual contents.)
[20:17] <znf> so, dumb question
[20:18] <znf> I have 2 x Ubuntu 20.04 machines
[20:18] <znf> I'm having an issue where one of them only recognizes 2 x DVB cards (with 4 installed), while the other one has 3 installed and they are all working
[20:18] <znf> first I thought it was the hardware itself, as it's a low-end Ryzen 
[20:19] <znf> we swapped mobo/cpu, had the ame issue 
[20:19] <znf> I wanted to rule out the OS, so I booted up Windows, all DVB cards were present and accounted for
[20:20] <znf> The 'new' machine with 4 cards was throwing up an error about not being able to register cards 
[20:20] <znf> so out of 16 adapters (4 cards x 4 inputs each), it was only registering 8 
[20:21] <znf> the 'new' machine was running 5.13, the 'old' one is running 5.8.0-40-generic #45~20.04.1-Ubuntu
[20:22] <znf> so, obviously, because all multimedia stuff is picky, I just install the same kernel that I have running 
[20:23] <znf> I reboot, boot into the same kernel, same issue
[20:23] <znf> can't register adapters 
[20:23] <znf> I go on and compare modules with modinfo
[20:23] <znf> and, surprise, the same path has different sigvers
[20:24] <shibboleth> cards or dongles?
[20:24] <znf> shibboleth, cards
[20:24] <znf> https://i.imgur.com/7DPyeVH.png
[20:24] <znf> left side was modinfo from the 'working' one, right side was the one with issues
[20:25] <znf> better screenshot: https://i.imgur.com/qir9fuM.png
[20:26] <shibboleth> dunno, how many pcie lanes (not slots, pcie lanes between the cpu and mobo) do each of the systems have?
[20:26] <znf> not relevant, let me finish, sorry for the long story telling
[20:27] <shibboleth> also, the cards show up in windows but are missing in action with linux on the same hw? missing from lspci -vn and lshw?
[20:27] <shibboleth> not relevant?
[20:27] <shibboleth> wrong
[20:27] <znf> let me finish :)
[20:28] <znf> so, at this point, because I'm otherwise out of ideas, I say screw it, I rsync the module tree from the 'old' working machine to the 'new' one 
[20:28] <znf> reboot
[20:28] <znf> works
[20:28] <znf> all 16 adapters are registered
[20:31] <shibboleth> as in /lib/modules? are the cards supported by the mainline kernel or built manually?
[20:31] <znf> they're supported by the mainline kernel 
[20:31] <znf> yes, I rsync'd /lib/modules/5.8.0-40-generic/
[20:32] <shibboleth> did you keep the old folder?
[20:32] <znf> no
[20:32] <shibboleth> well, it'd be i interesting to compare hashes
[20:32] <znf> or, well, kinda yes 
[20:32] <znf> I mean, I just rsync'd over
[20:33] <shibboleth> which wouldn't have actually done anything if the folders/files had the same timestamps and checksums
[20:33] <znf> yeah, but they didn't
[20:33] <znf> hence why I'm even more baffled
[20:33] <znf> the driver for the tuner is cx23885.ko 
[20:34] <znf> https://www.kernel.org/doc/html/v4.9/media/v4l-drivers/cx23885-cardlist.html
[20:34] <znf> the cards are Hauppauge WinTV-QuadHD-DVB
[20:34] <shibboleth> well, obviously one instance was corrupt
[20:34] <znf> the "new" instance... I just installed today 
[20:34] <shibboleth> instance of the module tree
[20:34] <znf> ye
[20:34] <znf> the 'old' one has been installed months ago
[20:35] <shibboleth> rsync wouldn't have done anything if the contents were identical
[20:35] <znf> I usually apt mark hold these kind of systems (the kernel modules/versions), because of their fragile nature
[20:35] <shibboleth> was to how, maybe fs/drive corruption. can't really do anything but speculate
[20:35] <shibboleth> as to
[20:35] <znf> it's probably not -- here's what puzzles me:
[20:36] <znf> why do the /new/ modules downloaded/installed today have a signature?
[20:36] <znf> but the old ones don't?
[20:37] <shibboleth> secureboot
[20:38] <shibboleth> won't load tampered or otherwise non-signed/corrupted modules
[20:39] <znf> hm
[20:39] <znf> shouldn't the kernel package be different then?
[20:40] <bryceh> utkarsh2102, we have php-psr-cache 3 from experimental, and php-psr-container 2 also from experimental, but for php-psr-log we have version 1 from unstable.  Thinking maybe we want php-psr-log 3 from experimental, to go with the others.
[20:40] <shibboleth> no, if secureboot is enabled grub must be signed by microsoft and the kernel must be signed by whoever had microsoft sign that grub
[20:41] <bryceh> we've got a bunch of psr-related migration issues, e.g. https://launchpad.net/ubuntu/+source/php-doctrine-data-fixtures/1.5.2-1/+build/23092515, and wonder if it might fix that.  WDYT?
[20:41] <shibboleth> and the modules must be signed by whoever signed the kernel or enrolled their own keys in uefi
[20:41] <znf> the 'old' box is running in Legacy/BIOS mode
[20:42] <shibboleth> which is the one that was already working?
[20:42] <znf> the 'new' box is running in EFI mode, but mokutil --sb-state says it's running with SecureBoot disabled
[20:42] <znf> the Legacy/BIOS one
[20:42] <znf> also, /boot/vmlinuz-5.8* has the same md5sum
[20:43] <znf> only the modules downloaded by the 'new' box are different 
[20:44] <shibboleth> ok, install a previous kernel on both boxes, content of lib/modules for that version should match
[20:44] <znf> here's another fun part
[20:45] <znf> root@dtv1:~/kernel# md5sum /lib/modules/5.8.0-40-generic/kernel/drivers/media/pci/cx23885/cx23885.ko ./lib/modules/5.8.0-40-generic/kernel/drivers/media/pci/cx23885/cx23885.ko
[20:45] <znf> e82697446b9a7eaf113719a23bc0ac6f  /lib/modules/5.8.0-40-generic/kernel/drivers/media/pci/cx23885/cx23885.ko
[20:45] <znf> c310f5cdda50394e0778270e0fde7328  ./lib/modules/5.8.0-40-generic/kernel/drivers/media/pci/cx23885/cx23885.ko
[20:45] <znf> 'dtv1' is the "old" one running in legacy
[20:45] <znf> it has "linux-modules-extra-5.8.0-40" installed already
[20:46] <znf> I apt download linux-modules-extra-5.8.0-40 -> unpack -> md5sums are different
[20:46] <shibboleth> same arch?
[20:46] <znf> yes
[20:46] <shibboleth> also linux-signed-generic and linux-generic will have diff contents
[20:47] <shibboleth> since one will have signed components
[20:47] <znf> both my systems report:
[20:47] <znf> ii  linux-modules-extra-5.8.0-40-generic                        5.8.0-40.45~20.04.1                   amd64        Linux kernel extra modules for version 5.8.0 on 64 bit x86 SMP
[20:47] <znf> ii  linux-modules-extra-5.8.0-40-generic   5.8.0-40.45~20.04.1                   amd64        Linux kernel extra modules for version 5.8.0 on 64 bit x86 SMP
[20:48] <znf> unless I'm incredibly blind, I don't see any actual version or any hint that one is signed, the other is not 
[20:48] <shibboleth> some of the modules are embedded in the kernel image
[20:49] <shibboleth> hence linux-modules-extra
[20:49] <znf> cx23885.ko is in -extra
[20:49] <znf> but the no-extra package is also the same:
[20:49] <znf> ii  linux-modules-5.8.0-40-generic                              5.8.0-40.45~20.04.1                   amd64        Linux kernel extra modules for version 5.8.0 on 64 bit x86 SMP
[20:49] <znf> ii  linux-modules-5.8.0-40-generic         5.8.0-40.45~20.04.1                   amd64        Linux kernel extra modules for version 5.8.0 on 64 bit x86 SMP
[20:50] <shibboleth> still, some are extracted from the kernel image
[20:50] <znf> https://pastie.dev/ff6UIV.yaml
[20:50] <znf> new one on top, old one at the bottom
[20:50] <shibboleth> try deleting /lib/modules/foo and reboot, some of it will still... " be there"
[20:51] <znf> the only difference is the virtual package linux-image-generic-hwe-20.04 
[20:51] <znf> or, rather, not a virtual, but dpkg -S only reports that it has a changelog.gz and a copyright 
[20:52] <shibboleth> and where do you suppose vmlinuz-foo comes frome?
[20:53] <shibboleth> anyway, you wanna do your thing, don't let me stop you
[20:53] <znf> /boot/vmlinuz* comes from linux-image-5.8.0-40-generic 
[20:54] <znf> root@dtv1:~# dpkg -S /boot/vmlinuz-5.8.0-40-generic
[20:54] <znf> linux-image-5.8.0-40-generic: /boot/vmlinuz-5.8.0-40-generic
[20:54] <shibboleth> yes?
[20:55] <shibboleth> dpkg -l | grep linux
[20:55] <shibboleth> lemme guess, one box has -signed, the other doesn't?
[20:55] <znf> I'm just trying to find an explanation as to why the same package -- linux-modules-extra-5.8.0-40-generic -- has different checksums on 2 different sistems
[20:56] <znf> they both have "linux-image-5.8.0-40-generic" 
[20:56] <znf> which claims to be signed
[20:56] <znf> and both have the same md5sum 
[20:56] <znf> so that package is identical on both systems 
[20:57] <shibboleth> ok, unpack the .deb from /var/cache/apt/archives/
[20:57] <znf> for which? :)
[20:57] <shibboleth> both
[20:57] <znf> I obviously no longer have the cache on the old system 
[20:58] <shibboleth> the .deb is signed, otherwise apt would've refused to process it
[20:58] <sarnold> I think apt only checks that when *saving* the download
[20:58] <sarnold> dpkg doesn't re-check the package is fine when it reads it from disk to unpack it
[20:58] <znf> 5.8.0-40.45 is from January 2021, so there's 0 chances I'd have that cache anymore :P
[20:59] <shibboleth> doesn't mean you still can't get it
[20:59] <shibboleth> anyway, this is going off on oh so many tangents
[20:59] <sarnold> so a package that is corrupted between the download and the time that dpkg reads it back again won't be caught by signatures; if you're lucky you'll trip an error in the decompression routines and get an error message there. I think we see one or two of these bugs in launchpad every year
[21:00] <sarnold> but I have to imagine some disk somewhere, or bad memory, could flip things in a way that it'd just decompress garbage
[21:00] <znf> shibboleth, apt download on the OLD system brought me the same package that the NEW system also downloaded
[21:01] <shibboleth> sarnold, apt won't hand it over to dpkg if corrupted
[21:01] <shibboleth> but yes, you can manually dpkg a corrupted/tampered package
[21:01] <sarnold> shibboleth: that's the thing, though, I think apt only checks what it gets over the wire, it doesn't check the file from cache again..