| mmikowski | Eickmeyer[m]: @vorlon bdmurray arraybolt3[m]: I will update bug, but interesting change from 5.17.0-1015 to 5.17.0-1016 was the initramrd went from 108MB to 165MB. | 05:49 |
|---|---|---|
| mmikowski | Changing to xz compression brought it to around 120 MB. But that's a huge, 50% jump from before. | 05:50 |
| arraybolt3 | mmikowski: I've seen other people have very similar problems. One thing that helped was changing the "MODULES=most" to "MODULES=dep" in the initramfs config file IIRC. | 05:51 |
| arraybolt3 | mmikowski: Also, the last time I saw someone with the problem, it was getting them on a system that did *not* use NVIDIA, so it might be related to something else. | 05:52 |
| mmikowski | arraybolt3: Thanks! I will definitely make a note of this. Btw, the 165 jump occured with no config changes for initramrd: it just happened on that kernel install. So perhaps the default changed from MODULES=dep to MODULES=most. I'd have to test to see if prior initramrd builds are also affected. | 05:53 |
| mmikowski | arraybolt3: That's interesting. This was on a NUC with an eGPU, but that was powered down, but the initramrd was built with the Nvidia modules for obvious reasons - prime falls back to using Intel if the eGPU isn't present. But again, odd this just started happening with the 5.17.0-1016 kernel, whereas 5.17.0-1015 initramrd was so much smaller. | 05:55 |
| arraybolt3 | mmikowski: Also, the guy with the messed-up initramfs has a 112MB initrd for one kernel, and an 82MB one for a different kernel, while the one that was generated after the change was only 62MB. Not sure if that's helpful, but just in case, there it is. | 05:55 |
| mmikowski | arraybolt3: Hmmm. So that's from changing the MODULES settings? Or is that just noting that a kernel change can sometimes cause huge swings in initramrd sizes? | 05:56 |
| arraybolt3 | mmikowski: I believe it was from changing the MODULES setting. And also it appears that initrd sizes can swing relatively largely between kernels (which really doesn't make a whole lot of sense to me). | 05:57 |
| mmikowski | Another weird thing: on other hardware (no eGPU), I see 164 and 165 MB for 1015 and 1016 kernels. So some strange hardware interaction going on there (164MB on NV laptop; 108MB on NUC with eGPU). Ahhh - this might be it -- apparently initramrd is sensitive to attached displays? The NUC previously had a 1200p display attached; the big bump occurred after attaching a 4k display. | 05:59 |
| mmikowski | Finally, there may be a BIOS setting to turn off SGX controls which might fix the squeeze on the NUC. The eGPU definitely makes this a bit of an edge-case. | 06:01 |
| mmikowski | So calling it a night. Thanks @arraybolt3! | 06:01 |
| arraybolt3 | mmikowski: Glad to provide some helpful info! | 06:02 |
| mmikowski | @arraybolt3: yes, you've been great. More stuff to investigate. Noted and I will report back if I find anything interesting. | 06:02 |
| khfeng | rbasak: hi! is it possible to upload it for Focal? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amdgpu/+bug/1987038 | 06:59 |
| ubottu | Launchpad bug 1987038 in xserver-xorg-video-amdgpu (Ubuntu Focal) "Fix slow refresh rate when AMD GPU screen in reverse prime mode" [Medium, Confirmed] | 06:59 |
| === sem2peie- is now known as sem2peie | ||
| === sem2peie- is now known as sem2peie | ||
| === sem2peie- is now known as sem2peie | ||
| bluca | enr0n: ping - just making sure you saw the message from yesterday | 10:18 |
| ginggs | bdmurray, kanashiro__: i'm seeing several failures on amd64, e.g. https://autopkgtest.ubuntu.com/packages/3/389-ds-base/kinetic/amd64 2022-09-07 04:15:12 UTC | 10:44 |
| ginggs | autopkgtest [04:15:11]: ERROR: testbed failure: cannot send to testbed: [Errno 32] Broken pipe | 10:44 |
| ginggs | also i386 | 10:45 |
| enr0n | bluca: Yes, thanks for the heads up. I was just about to begin debugging that failure when you sent | 12:35 |
| enr0n | Can a core dev please retry systemd autopkgtests on kinetic: retry-autopkgtest-regressions --blocks systemd -s kinetic ? I am seeing many of the weird failures that ginggs described above (I have also seen this happen in the past). | 12:58 |
| ginggs | enr0n: running that command I only see 3 packages to retry; coturn, initramfs-tools, and nut. were you expecting more? | 14:02 |
| enr0n | ginggs: ah I think sil2100 started several after our meeting but didn't mention it here | 14:12 |
| === popey6 is now known as popey | ||
| ginggs | enr0n: i've just chatted to sil2100, he didn't restart them yet -- it is weird, running the script again now, it showed many more. anyway,I'll retry all those I can now | 14:26 |
| enr0n | ginggs: weird indeed, but thanks! | 14:27 |
| bdmurray | enr0n, ginggs: Have the "cannot send to testbed" errors all been on amd64 / in lgw01 ? | 15:24 |
| enr0n | bdmurray: For the most part, yes e.g. https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/f/fetchmail/20220907_043933_fbb77@/log.gz and https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/c/ceph/20220907_040000_b4874@/log.gz. There are also some i386 e.g. | 15:28 |
| enr0n | https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/i386/c/clutter-1.0/20220907_050854_f3aae@/log.gz. | 15:28 |
| bdmurray | enr0n: ack, thanks! | 15:30 |
| bdmurray | enr0n: some of those logs show kernel oopses w/ systemd-udevd being hung. Have you looked at that at all? | 16:59 |
| enr0n | bdmurray: No, I haven't looked to closely at those since it looked like an issue we've seen before. Can you link one of those examples? | 17:04 |
| bdmurray | https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/f/fetchmail/20220907_164153_f66ff@/log.gz | 17:08 |
| enr0n | looking | 17:14 |
| enr0n | bdmurray: hm yeah that could use more investigation. However I think it's unlikely it was introduced in the latest upload, which only modifies systemd-resolved.postinst. | 17:16 |
| bdmurray | enr0n: I booted a test system in lgw01 with systemd 251.4-1ubuntu3 and it also hit a kernel oops | 17:51 |
| vorlon | bdmurray, enr0n: the autopkgtest failure logs I'm seeing show a system that hasn't had a chance to install the new systemd | 18:21 |
| bdmurray | vorlon: new being ubuntu4 or ubuntu3 ? | 18:26 |
| vorlon | bdmurray: ubuntu4 | 18:26 |
| vorlon | bdmurray: do you think the previous systemd is what broke the env? | 18:27 |
| vorlon | my point is that these don't look like they should block promotion of ubuntu4 | 18:27 |
| bdmurray | vorlon: bdmurray-test-kerneloops3 in prod-proposed-migration took a very long time to finish provisioning b/c of 'task systemd-udevd:143 blocked for more than 1208 seconds' and it has ubuntu3 installed | 18:30 |
| vorlon | ok | 18:30 |
| vorlon | but is there any reason not to skiptest ubuntu4 and potentially unbreak the livefs builds? | 18:30 |
| bdmurray | not that would be for the greater good | 18:31 |
| bdmurray | s/not/no/ | 18:31 |
| vorlon | ack, adding the hint, thanks | 18:32 |
| vorlon | jbicha: so you synced a systemd-cron package from unstable that adds a dependency on a non-existent package? | 18:36 |
| jbicha | vorlon: I didn't make it worse since the dep change was already done by autosync | 18:42 |
| vorlon | jbicha: ah | 18:43 |
| enr0n | vorlon, bdmurray: thanks for adding the hint. In any case I will dig a bit more into the issue | 18:43 |
| arraybolt3 | When building a debian/copyright file, how should I handle supporting documentation files within the source code of a project that have no license specified? I'm dealing with dssi-1.0.0 (part of distrho-ports), and have been met with a whopping load of GNU Autoconf and related junk (all of which I believe I can simply omit from the copyright file according to Debian policy), however there's also a "README" file and a "ChangeLog" | 20:38 |
| arraybolt3 | file with no license specified in them or in other areas of the software. | 20:38 |
| arraybolt3 | (The software also licenses different parts of itself under different licenses and has no overarching "license" applied to the entire thing, so I can't fall back to the "default license" of the project since there is none.) | 20:39 |
| arraybolt3 | (I think I can probably just omit the files entirely.) | 20:46 |
| sarnold | users expect readmes and changelogs :) | 20:47 |
| arraybolt3 | sarnold: I mean omit them from the copyright file. | 20:50 |
| sarnold | ah :) | 20:50 |
| arraybolt3 | (They're obviously supporting documentation for an open-source project, the license is just... missing. I'm guessing no one expected the need to specify a license for files like that.) | 20:51 |
| vorlon | arraybolt3: the assumption is that files included in the tarball which don't include an explicit per-file license declaration have the same license as the project as a whole. Where would I find the tarball for this to look at? | 21:10 |
| arraybolt3 | vorlon: It's a part of a giant project, let me see if I can pull up the info... | 21:23 |
| vorlon | arraybolt3: eh what is it that you're reviewing? :) | 21:24 |
| arraybolt3 | vorlon: The repo is "git clone https://git.launchpad.net/distrho-ports". I'm building the entire copyright file for the whole project. | 21:24 |
| arraybolt3 | The exact part in question is libs/juced/source/dependancies/dssi-1.0.0. | 21:24 |
| vorlon | hmm | 21:25 |
| vorlon | arraybolt3: that directory has a COPYING file which we would assume is controlling | 21:26 |
| arraybolt3 | It's essentially a ton of smaller projects lumped into one gigantic one, the project as a whole is GPL-2, but all of the stuff inside is under various different licenses with tons of different copyrights. | 21:26 |
| arraybolt3 | vorlon: That file specifically says it only applies to one specific file in the project. | 21:26 |
| vorlon | ah | 21:26 |
| arraybolt3 | NOTE: This license applies to the DSSI header file. See README for a summary of the licensing of other files, and the individual source code for more details. | 21:27 |
| arraybolt3 | Thus is the notice in COPYING. | 21:27 |
| arraybolt3 | Neither one of the things the header mentions helps in determining the copyright of the README itself or the ChangeLog. | 21:28 |
| vorlon | arraybolt3: shrug I would still treat those as LGPL as that's the most restrictive license there | 21:29 |
| vorlon | but also this looks like a terrible bundling of things to be trying to package | 21:29 |
| arraybolt3 | vorlon: That makes sense. Also, one last thing, are file format specifications licensable, or only patentable? There's an RFC.txt file in the mess with missing copyright info and I don't know how that plays in. | 21:29 |
| arraybolt3 | (Er, I don't think it's a file format specification, but it is a specification.) | 21:30 |
| vorlon | ugh there has been a lot of nuisance with rfcs because the IETF has applied a copyright license to them which is non-free | 21:30 |
| vorlon | Debian has largely dealt with this | 21:30 |
| arraybolt3 | vorlon: I don't think the RFC.txt file in here is copyrighted by the IETF. No mention of them is made, and I'm not finding the file in the IETFs RFC stuff. | 21:35 |
| vorlon | ah | 21:35 |
| arraybolt3 | *shrug* I guess I'll just treat it as LGPL too? I mean, that's the best I can figure. But maybe I or Eickmeyer should toss an email at the DSSI guys and say "GUYS! Your licensing info! Fix it! :P" | 21:37 |
| Eickmeyer[m] | Dssi is mortibund. | 21:38 |
| arraybolt3[m] | ...well I guess then we'll only have to do this once! | 21:40 |
| mmikowski | arraybolt3: We added hardward support now for NXg1. In package testing. This fixes the overly large initramrd. Was 169MB; change to xz compression brings it to 120; change to modules = dep, brings it to 82 (smaller than prior kernels). Eickmeyer[m] is pushing out a testing package perhaps tomorrow. Plan to release after a hardware peripheral check. Thanks for your help! | 22:45 |
| mmikowski | NXg1 = Kubuntu Focus NX gen 1. FWIW, no other platform requires these tweaks, so only applies to that hardware which is sensed and patched on upgrade. | 22:46 |
| arraybolt3 | mmikowski: Nice! Glad to help! | 22:46 |
| mmikowski | arraybolt3: Yes, thanks again. Used a symlink drop file in /etc/initramfs-tools/conf.d/ fwiw. Testing change in initrd file for prior kernel version ... | 22:48 |
| mmikowski | also, interestingly, seems to boot much faster now (haven't time it though). | 22:49 |
| mmikowski | Hmmm. I guess we could have dropped into /usr/share/initramfs-tools/conf.d, but this will work for a drop file IMO. | 22:50 |
| mmikowski | arraybolt3: updating prior initramd results in 29MB (1/4 size). Not sure about nv libs, but that's even more testing (gahhh!) | 23:12 |
| arraybolt3 | Good grief, that seems a bit on the small side. | 23:13 |
| Eickmeyer[m] | xz is much higher compression, but is much more CPU intensive. | 23:41 |
| sarnold | and vastly slower | 23:42 |
| sarnold | I've got a collection of scripts for unpacking the archive to search things, and I've seen some of the unpack operations take four minutes of xeon e5 CPU time | 23:43 |
| Eickmeyer[m] | sarnold: For the computers in question (11th gen Intel NUCs), the difference has been negligible, and boot time has been actually shorter, believe it or not. | 23:46 |
| sarnold | Eickmeyer[m]: heh, what were they using for storage? an sd card? | 23:47 |
| sarnold | I'm prepared to accept that xz might be faster than lz4 or zstd in some situations but I'd mostly expect it to be with *slow* storage | 23:47 |
| Eickmeyer[m] | sarnold: nvme SSD. | 23:47 |
| sarnold | o_O | 23:47 |
| Eickmeyer[m] | Yeah. Somewhat anti-intuitive, but it's true. | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!