[05:52] good morning [06:07] squid openssl3 fix migrated to -release \o/ [07:28] good morning === kmt_ is now known as hornbill [09:01] good morning! [09:09] hi athos [09:09] \o [09:14] hi athos [09:36] hey [09:37] is mysql-server installed by default? [09:37] that's very weird if it is [09:39] ahasenack: it seems all test passed for rsync :) === MJCD is now known as MJCDbbl === MJCDbbl is now known as ErrMurrJurrCurrD === genii-core is now known as genii === ErrMurrJurrCurrD is now known as ErrantEg0 [17:36] 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] 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] ah, it generates a repo [17:38] ok [17:39] 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] There's been no public communication about them doing anything to support zstd. [17:40] (And it's closed-source, so no way of knowing if they're working on it or what. ¬.¬) [17:40] 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] Epochs, e.g., are not represented in the filename. [17:42] right :) [17:43] Yeah, I had some naive code to parse name/version and ended up having to bin it because of things like that. [17:43] So I'm only a couple of weeks ahead of you on discovering that. ;) [17:44] (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.) === ErrantEg0 is now known as MJCD [20:17] so, dumb question [20:18] I have 2 x Ubuntu 20.04 machines [20:18] 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] first I thought it was the hardware itself, as it's a low-end Ryzen [20:19] we swapped mobo/cpu, had the ame issue [20:19] I wanted to rule out the OS, so I booted up Windows, all DVB cards were present and accounted for [20:20] The 'new' machine with 4 cards was throwing up an error about not being able to register cards [20:20] so out of 16 adapters (4 cards x 4 inputs each), it was only registering 8 [20:21] the 'new' machine was running 5.13, the 'old' one is running 5.8.0-40-generic #45~20.04.1-Ubuntu [20:22] so, obviously, because all multimedia stuff is picky, I just install the same kernel that I have running [20:23] I reboot, boot into the same kernel, same issue [20:23] can't register adapters [20:23] I go on and compare modules with modinfo === pizza is now known as pizzaiolo [20:23] and, surprise, the same path has different sigvers [20:24] cards or dongles? [20:24] shibboleth, cards [20:24] https://i.imgur.com/7DPyeVH.png [20:24] left side was modinfo from the 'working' one, right side was the one with issues [20:25] better screenshot: https://i.imgur.com/qir9fuM.png [20:26] dunno, how many pcie lanes (not slots, pcie lanes between the cpu and mobo) do each of the systems have? [20:26] not relevant, let me finish, sorry for the long story telling [20:27] 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] not relevant? [20:27] wrong [20:27] let me finish :) [20:28] 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] reboot [20:28] works [20:28] all 16 adapters are registered [20:31] as in /lib/modules? are the cards supported by the mainline kernel or built manually? [20:31] they're supported by the mainline kernel [20:31] yes, I rsync'd /lib/modules/5.8.0-40-generic/ [20:32] did you keep the old folder? [20:32] no [20:32] well, it'd be i interesting to compare hashes [20:32] or, well, kinda yes [20:32] I mean, I just rsync'd over [20:33] which wouldn't have actually done anything if the folders/files had the same timestamps and checksums [20:33] yeah, but they didn't [20:33] hence why I'm even more baffled [20:33] the driver for the tuner is cx23885.ko === pizzaiolo is now known as piz [20:34] https://www.kernel.org/doc/html/v4.9/media/v4l-drivers/cx23885-cardlist.html [20:34] the cards are Hauppauge WinTV-QuadHD-DVB [20:34] well, obviously one instance was corrupt [20:34] the "new" instance... I just installed today [20:34] instance of the module tree [20:34] ye [20:34] the 'old' one has been installed months ago [20:35] rsync wouldn't have done anything if the contents were identical [20:35] I usually apt mark hold these kind of systems (the kernel modules/versions), because of their fragile nature [20:35] was to how, maybe fs/drive corruption. can't really do anything but speculate [20:35] as to [20:35] it's probably not -- here's what puzzles me: [20:36] why do the /new/ modules downloaded/installed today have a signature? [20:36] but the old ones don't? [20:37] secureboot [20:38] won't load tampered or otherwise non-signed/corrupted modules [20:39] hm [20:39] shouldn't the kernel package be different then? [20:40] 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] 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] 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] and the modules must be signed by whoever signed the kernel or enrolled their own keys in uefi [20:41] the 'old' box is running in Legacy/BIOS mode [20:42] which is the one that was already working? [20:42] the 'new' box is running in EFI mode, but mokutil --sb-state says it's running with SecureBoot disabled [20:42] the Legacy/BIOS one [20:42] also, /boot/vmlinuz-5.8* has the same md5sum [20:43] only the modules downloaded by the 'new' box are different [20:44] ok, install a previous kernel on both boxes, content of lib/modules for that version should match [20:44] here's another fun part [20:45] 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] e82697446b9a7eaf113719a23bc0ac6f /lib/modules/5.8.0-40-generic/kernel/drivers/media/pci/cx23885/cx23885.ko [20:45] c310f5cdda50394e0778270e0fde7328 ./lib/modules/5.8.0-40-generic/kernel/drivers/media/pci/cx23885/cx23885.ko [20:45] 'dtv1' is the "old" one running in legacy [20:45] it has "linux-modules-extra-5.8.0-40" installed already [20:46] I apt download linux-modules-extra-5.8.0-40 -> unpack -> md5sums are different [20:46] same arch? [20:46] yes [20:46] also linux-signed-generic and linux-generic will have diff contents [20:47] since one will have signed components [20:47] both my systems report: [20:47] 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] 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] 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] some of the modules are embedded in the kernel image [20:49] hence linux-modules-extra [20:49] cx23885.ko is in -extra [20:49] but the no-extra package is also the same: [20:49] 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] 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] still, some are extracted from the kernel image [20:50] https://pastie.dev/ff6UIV.yaml [20:50] new one on top, old one at the bottom [20:50] try deleting /lib/modules/foo and reboot, some of it will still... " be there" [20:51] the only difference is the virtual package linux-image-generic-hwe-20.04 [20:51] or, rather, not a virtual, but dpkg -S only reports that it has a changelog.gz and a copyright [20:52] and where do you suppose vmlinuz-foo comes frome? [20:53] anyway, you wanna do your thing, don't let me stop you [20:53] /boot/vmlinuz* comes from linux-image-5.8.0-40-generic [20:54] root@dtv1:~# dpkg -S /boot/vmlinuz-5.8.0-40-generic [20:54] linux-image-5.8.0-40-generic: /boot/vmlinuz-5.8.0-40-generic [20:54] yes? [20:55] dpkg -l | grep linux [20:55] lemme guess, one box has -signed, the other doesn't? [20:55] 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] they both have "linux-image-5.8.0-40-generic" [20:56] which claims to be signed [20:56] and both have the same md5sum [20:56] so that package is identical on both systems [20:57] ok, unpack the .deb from /var/cache/apt/archives/ [20:57] for which? :) [20:57] both [20:57] I obviously no longer have the cache on the old system [20:58] the .deb is signed, otherwise apt would've refused to process it [20:58] I think apt only checks that when *saving* the download [20:58] dpkg doesn't re-check the package is fine when it reads it from disk to unpack it [20:58] 5.8.0-40.45 is from January 2021, so there's 0 chances I'd have that cache anymore :P [20:59] doesn't mean you still can't get it [20:59] anyway, this is going off on oh so many tangents [20:59] 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] 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] shibboleth, apt download on the OLD system brought me the same package that the NEW system also downloaded [21:01] sarnold, apt won't hand it over to dpkg if corrupted [21:01] but yes, you can manually dpkg a corrupted/tampered package [21:01] 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..