| cpaelzer | good morning | 05:52 |
|---|---|---|
| cpaelzer | squid openssl3 fix migrated to -release \o/ | 06:07 |
| mirespace | good morning | 07:28 |
| === kmt_ is now known as hornbill | ||
| athos | good morning! | 09:01 |
| cpaelzer | hi athos | 09:09 |
| athos | \o | 09:09 |
| mirespace | hi athos | 09:14 |
| utkarsh2102 | hey | 09:36 |
| utkarsh2102 | is mysql-server installed by default? | 09:37 |
| utkarsh2102 | that's very weird if it is | 09:37 |
| mirespace | ahasenack: it seems all test passed for rsync :) | 09:39 |
| === 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 | ||
| 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:36 |
| 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:37 |
| ahasenack | ah, it generates a repo | 17:38 |
| ahasenack | ok | 17:38 |
| 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:39 |
| 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:40 |
| Odd_Bloke | Epochs, e.g., are not represented in the filename. | 17:41 |
| sdeziel | right :) | 17:42 |
| 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:43 |
| 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.) | 17:44 |
| === ErrantEg0 is now known as MJCD | ||
| znf | so, dumb question | 20:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| znf | the 'new' machine was running 5.13, the 'old' one is running 5.8.0-40-generic #45~20.04.1-Ubuntu | 20:21 |
| znf | so, obviously, because all multimedia stuff is picky, I just install the same kernel that I have running | 20:22 |
| 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 |
| === pizza is now known as pizzaiolo | ||
| znf | and, surprise, the same path has different sigvers | 20:23 |
| 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:24 |
| znf | better screenshot: https://i.imgur.com/qir9fuM.png | 20:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:31 |
| 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:32 |
| 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:33 |
| === pizzaiolo is now known as piz | ||
| 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:34 |
| 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:35 |
| znf | why do the /new/ modules downloaded/installed today have a signature? | 20:36 |
| znf | but the old ones don't? | 20:36 |
| shibboleth | secureboot | 20:37 |
| shibboleth | won't load tampered or otherwise non-signed/corrupted modules | 20:38 |
| znf | hm | 20:39 |
| znf | shouldn't the kernel package be different then? | 20:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| znf | only the modules downloaded by the 'new' box are different | 20:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| shibboleth | and where do you suppose vmlinuz-foo comes frome? | 20:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| 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 | 20:59 |
| 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:00 |
| 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.. | 21:01 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
