| mwhudson | does our cross toolchain stuff really have to be as brain-bending as it is | 00:50 |
|---|---|---|
| === guiverc2 is now known as guiverc | ||
| stevenm_ | can anyone show me the command ubiquity uses to format the ESP? (presumably using mkfs.fat ?) | 05:39 |
| stevenm_ | As when I look at mine with 'file -s' or 'minfo -i'... you can see a value called 'reserved' (which I've seen examples of 'reserved=0x0', 'reserved=0x1' and 'reserved=0x3')... what the heck is that? the man/docs don't explain it! | 05:39 |
| mwhudson | stevenm_: it'll be in partman-efi somewhere i guess | 08:31 |
| mwhudson | stevenm_: https://git.launchpad.net/ubiquity/tree/d-i/source/partman-efi/commit.d/format_efi | 08:33 |
| cpaelzer | Hmm, with the latest ubuntu-dbgsym-keyring update in jammy I see "The following signatures were invalid: BADSIG C8CAB6595FDFF622 Ubuntu Debug Symbol Archive Automatic Signing Key (2016)" | 08:36 |
| cpaelzer | That seems reproducible on a new container, but I feel that I can't be alone with that yet I found no report e.g. on https://bugs.launchpad.net/ubuntu/+source/ubuntu-keyring/+bugs - does anyone have a pointer if this is already tracked/discussed? | 08:37 |
| cpaelzer | hmm, deleting the key and reinstalling the keyring helped - but I'm not yet convinced this doesn't have a root cause that would be worth to understand | 08:40 |
| cpaelzer | well, no more reproducible ... giving up but at least updated 1920640 | 08:49 |
| stevenm_ | mwhudson, nah it's not - i already looked there | 08:54 |
| stevenm_ | got the answer anyway... it only appeared when it's mounted... I think it's a flag used to know if it was properly unmounted or not (e.g. for windows chkdsk) | 08:54 |
| stevenm_ | oddly that source you linked to... it's weird how it uses fat16 if the arch isn't amd64/i386 - a very arbitrary decision | 08:55 |
| stevenm_ | you'd think it'd be based on the size of the ESP that it picks fat12/16/32 (as a standards compliant UEFI supports all 3) | 08:56 |
| stevenm_ | in fact I've the UEFI firmware for the pi 4 doesn't support fat16 properly - so ubiquity (and d-i that it's based off) would probably fail on that | 08:57 |
| === sem2peie- is now known as sem2peie | ||
| === sem2peie- is now known as sem2peie | ||
| P-NuT | Afternoon all. | 11:55 |
| P-NuT | when building a ubuntu / debian .deb package you can use a preinst script to run first. | 11:55 |
| P-NuT | Does this script HAVE to be bash? | 11:55 |
| P-NuT | Can it be python for example? | 11:55 |
| tumbleweed | It can, but then you need to pre-depend on python, which can make upgrades more complex / cause them to break | 12:00 |
| tumbleweed | Generally maintainer scripts should have the smallest dependencies possible. *especially* preinst | 12:00 |
| P-NuT | I hear that, but I need to do a lot of modification to netplan and systemd-resolve beforehand as I'm building an appliance. | 12:01 |
| P-NuT | everything relies on python anyway. | 12:01 |
| tumbleweed | does that really have to happen before the package gets unpacked? | 12:02 |
| P-NuT | Partly, yes because I install dnsmasq which needs systemd-resolve's config to be changed so as to free up port 53 before it can even install the .deb package for it | 12:03 |
| P-NuT | I guess i could write the priinst in bash and at the end have it kick off a python script. | 12:04 |
| tumbleweed | that's functionally equivalent in terms of dependencies | 12:04 |
| P-NuT | ok, i'll give that a go. | 12:04 |
| ogra | also ... it should not be *bash* but POSIX shell code 😉 | 12:05 |
| ogra | (ubuntu uses dash as /bin/sh, not bash) | 12:05 |
| mitya57 | Trevinho: hi, ping about https://code.launchpad.net/~rs2009/unity/+git/unity/+merge/429299/comments/1135951 | 12:41 |
| Trevinho | mitya57: hey, I've it in the radar, but I've to finish some glib stuff first | 12:41 |
| mitya57 | Ok, thanks! | 12:41 |
| P-NuT | Hi all. I have built a .deb file that uses the Depends: line in the control file, but rather than install the dependancies, it just fails saying that they need to be installed. | 13:16 |
| P-NuT | Can anyone help me understand why this is as this has not been my experience of use any other standalone deb with dpkg -i <packagename>.deb | 13:17 |
| rbasak | That's what dpkg does. If you want something to automatically grab and install dependencies, use apt. | 13:17 |
| rbasak | Note though that this channel is supposed to be for development of Ubuntu itself. #ubuntu-packaging is for people writing packages *for* Ubuntu. | 13:19 |
| P-NuT | oh right on thanks for the heads up. | 13:24 |
| enr0n | Can a core-dev please retry these tests? These are historically flaky. retry-autopkgtest-regressions --blocks systemd -s jammy | grep -E "udisks|gvfs" | 14:51 |
| ginggs | enr0n: looking... | 15:01 |
| ginggs | enr0n: done, and what about systemd's own test on ppc64el? | 15:07 |
| enr0n | ginggs: thanks! I was going to retry that one locally first, but I am fine with it being retried anyways | 15:08 |
| ginggs | enr0n: retried that one as well | 15:10 |
| enr0n | ginggs: thanks again! | 15:10 |
| === genii_ is now known as genii | ||
| tsimonq2 | Does anyone have an idea on whether preseeding snaps in an install chroot is documented? | 16:43 |
| tsimonq2 | I see quite a bit of autogeneration for the seed.yaml in livecd-rootfs, while I can use the snap command line to perform all those steps in one locally. I can't be the only one with this use case and it took me too long not to share my steps somewhere | 16:44 |
| ogra | tsimonq2, snapd des not run in chroots ... | 16:45 |
| ogra | *does | 16:45 |
| ogra | so you can not actually use "the snap command line" | 16:46 |
| tsimonq2 | Well, you can use it on the host with the mount point if you use the model from snap known model | 16:46 |
| tsimonq2 | That sets up the preseed in the chroot which I later plan on booting | 16:46 |
| tsimonq2 | (So the chroot step is simply prep, I'm recreating a smaller version of livecd-rootfs for my own install essentially, skipping the entire ISO creation step and using debootstrap on my already-partitioned drive) | 16:47 |
| tsimonq2 | In livecd-rootfs, instead of using snap generate-image (recalling from memory...) it manually downloads the snaps and creates the yaml file | 16:48 |
| ogra | right, but all processing happens on first boot | 16:48 |
| ogra | (because on the build servers we can not just "use it on the host with the mount point" so there is nothing else implemented in livecd-rootfs beyond crafting the seed.yaml and putting the snap files where snapd will find them on first boot | 16:50 |
| ogra | ) | 16:50 |
| tsimonq2 | Right, so my question is essentially, why not let snap generate the yaml file instead of generating and validating it manually in livecd-rootfs? | 16:51 |
| ogra | because yu can not run snap inside the build chroot (unless you hack arund it like you do at home currently) | 16:52 |
| tsimonq2 | snap known model > /tmp/generic.model && sudo snap prepare-image --arch amd64 --classic /tmp/generic.model --snap=core --snap=firefox=latest/edge --snap=core22 --snap=core20 --snap=gtk-common-themes --snap=gnome-3-38-2004 --snap=bare --snap=newsboat --snap=chromium --snap=thunderbird=latest/beta --snap=lxd /mnt | 16:52 |
| ogra | snap is just interfacing with snapd ... if snapd does not run you wont get anything from it | 16:52 |
| tsimonq2 | ogra: The snap command is already ran in livecd-rootfs to get the model: https://git.launchpad.net/livecd-rootfs/tree/live-build/functions#n675 | 16:54 |
| ogra | yes, some special commands are local to the snap binary ... but i.e. snap install is not | 16:55 |
| ogra | prepare-image, version, known and pack are distinct functions of the snap binary ... everyting else is calls to the snapd REST API | 16:55 |
| tsimonq2 | When generating ISOs, would prepare-image not do the trick, rather than a manual download + add to the yaml file? I mean, it's essentially what prepare-image does on classic images, yeah? | 16:57 |
| bdmurray | ginggs, kanashiro: IS just made a change to the network in bos01 which shouldn't negatively affect autopkgtests but if you see something strange in your +1 shift please let me know! | 17:54 |
| bdmurray | It'd most likely appear as proxy errors. | 17:55 |
| Eickmeyer[m] | bdmurray: Is there a known issue with swapfiles being too small (e.g. defaulting to 1024) and overfilling? | 18:52 |
| bdmurray | Eickmeyer[m]: not that I can recall immediately but I might have heard vorlon talking about it | 18:54 |
| Eickmeyer[m] | bdmurray: Thanks. We (kfocus) just ran into an issue with a system that had a 1024 swapfile that couldn't unpack nvidia drivers due to OOM on a full swapfile. I was a bit taken aback when I got the report this morning. | 18:57 |
| vorlon | Eickmeyer[m], bdmurray: would need more info here. We don't automatically increase size of swapfiles on upgrade, though in principle we could; and 22.04.1 in particular has refactored its minimum swap calculations but that only matters if you're using ubiquity from 22.04.1 | 19:11 |
| Eickmeyer[m] | vorlon: These are brand-new installs for the most part. | 19:12 |
| vorlon | As of 22.04.1 the minimum allocated by ubiquity is 8GiB RAM+swap | 19:12 |
| vorlon | brand-new with what vintage installer though, and how much RAM? etc | 19:12 |
| Eickmeyer[m] | We're not seeing that. The swapfile on 16GB RAM was showing as 1GB. | 19:13 |
| vorlon | not seeing what? | 19:14 |
| vorlon | 16GB RAM + 0 swap >= 8GiB RAM+swap | 19:14 |
| Eickmeyer[m] | Ok, I'll back-up. This is on 22.04.1, Kubuntu, new install, no encryption. 16GB RAM, default whole disk install, swapfile came to 1GB. | 19:15 |
| vorlon | which all sounds reasonable to me | 19:15 |
| vorlon | a package upgrade alone is not going to run you out of memory on a system with 17GiB of virtual memory | 19:16 |
| Eickmeyer[m] | Right, but when nvidia was installed after-the-fact later as an eGPU, it filled the swapfile upon unpack. | 19:16 |
| vorlon | "filled the swapfile" makes no sense | 19:17 |
| vorlon | the kernel manages momery | 19:17 |
| vorlon | memory | 19:17 |
| Eickmeyer[m] | I'm just telling you what was reported to me. Looks like it filled RAM and then swapped-out and went OOM. | 19:17 |
| vorlon | well the nvidia package installation is not RAM-intensive | 19:18 |
| vorlon | so this is not a very good bug report :) | 19:18 |
| arraybolt3[m] | Eickmeyer: Is this something I can reproduce on my own NVIDIA hardware? Install Kubuntu without installing proprietary drivers, then attempt to install the driver after-the-fact, with 16 GB RAM? | 19:18 |
| arraybolt3[m] | (My NVIDIA card is internal.) | 19:18 |
| Eickmeyer[m] | arraybolt3: You can give it a shot. | 19:18 |
| * arraybolt3[m] takes RAM sticks out of desktop and begins investigation | 19:18 | |
| Eickmeyer[m] | This was all tested on an Intel NUC. | 19:18 |
| Eickmeyer[m] | mmikowski: When you have a minute, please reply to vorlon above. | 19:19 |
| vorlon | Eickmeyer[m], mmikowski: some analysis of *what* is consuming memory when the system OOMs would be useful; e.g. a snapshot of top -o RES, or pmap -x output; and dmesg output telling what processes were killed by the oom manager | 19:23 |
| arraybolt3[m] | Eickmeyer: Were you using OEM install mode by any chance? I'm about to do a standard installation and I don't know if that's right or not. | 19:45 |
| Eickmeyer[m] | arraybolt3: Yes. | 19:45 |
| arraybolt3[m] | Eickmeyer: Thanks, let's see if that triggers it. (I've not yet done the normal install, but may as well give the bug the greatest chances of appearing, right?) | 19:46 |
| Eickmeyer[m] | arraybolt3: That's my thought. | 19:48 |
| arraybolt3[m] | Eickmeyer: Also, when did you try to install the NVIDIA drivers? Did you do that during the OEM setup mode after initial installation, or was this after having finished the end-user setup? | 19:49 |
| Eickmeyer[m] | arraybolt3: After the end-user setup. | 19:50 |
| === arraybolt3_ is now known as arraybolt3 | ||
| arraybolt3[m] | Eickmeyer: Possibly a little late, but did you install updates during the installation procedure, or later? Or were they installed at all before trying to install the drivers? | 19:57 |
| Eickmeyer[m] | During. Just no 3rd party drivers during install. | 19:58 |
| arraybolt3[m] | Alright, that's what I just finished doing, so we're on track. | 19:58 |
| Eickmeyer[m] | coo coo | 19:58 |
| arraybolt3[m] | Eickmeyer: Last bits of details to extract out of you - should I reboot after finishing end user configuration, or go right to installing the drivers? And, should the drivers be installed via software-properties-kde, or using the command line? | 20:03 |
| Eickmeyer[m] | arraybolt3: Just fully update, reboot, then install the drivers and see what happens. | 20:04 |
| Eickmeyer[m] | Yeah, install the drivers via software-properties-kde. That's fine. | 20:04 |
| Eickmeyer[m] | Make sure your'e not on secure boot. | 20:05 |
| arraybolt3[m] | OK, good. Then the moment of truth has arrives. | 20:07 |
| arraybolt3[m] | Yes, has arrives. Because I can't type. | 20:08 |
| arraybolt3[m] | s/arrives/arrived/ | 20:08 |
| mmikowski | vorlon: Hi, this is mike. Eickmeyer[m] asked me to giv you a bump. | 20:11 |
| mmikowski | So we had an issue with initramrd on boot the system provided an 'out of memory' condition. This was an Intel NUC (Kubuntu Focus NX) and appeared to have been triggered by a Kernel update. | 20:12 |
| mmikowski | We had been using it to test an Nvidia eGPU, so the initramrd was very big, and that resuted in the 'out of memory' error on boot and drop into a rescue shell. I added xz compression to initramrd and that fixed the issue. | 20:13 |
| bdmurray | That sounds very different that what Eickmeyer[m] described | 20:14 |
| mmikowski | The swap file was 1GB. | 20:14 |
| mmikowski | I think it's just a case of telephone. Hi Brian! :) | 20:14 |
| vorlon | swap files are not used in the initramfs | 20:14 |
| bdmurray | What mmikowski is describing sounds like bug 1842320 | 20:14 |
| ubottu | Bug 1842320 in OEM Priority Project "Can't boot: 'error: out of memory.' immediately after the grub menu" [Critical, Triaged] https://launchpad.net/bugs/1842320 | 20:14 |
| vorlon | right | 20:15 |
| bdmurray | A bad game of telephone | 20:15 |
| mmikowski | ubottu: That definitely is the error. | 20:15 |
| mmikowski | Let me check the bug... | 20:15 |
| vorlon | the issue is the initramfs being too big for the space allocated by firmware for it | 20:16 |
| mmikowski | The bug looks correct. | 20:16 |
| vorlon | how big is "very big" for your initramfs? | 20:17 |
| mmikowski | I | 20:17 |
| mmikowski | will look it up ... | 20:17 |
| vorlon | I don't know why nvidia eGPU should increase the initramfs size | 20:17 |
| arraybolt3[m] | Eickmeyer: Could not reproduce issue. | 20:17 |
| Eickmeyer[m] | arraybolt3: Thanks. The issue was miscommunicated and/or I misunderstood anyhow. I've got the horse's mouth in here talking about it. Thanks for the test! | 20:18 |
| vorlon | only video drivers should be copied to the initramfs because video output needs to be correct in early boot | 20:18 |
| mmikowski | I believe I can reproduce here with the NUC. I just need to turn off xz compression. | 20:18 |
| arraybolt3[m] | My initrd size on the test system is 106.2 MiB. | 20:18 |
| mmikowski | ls -alh initrd.img-5.17.0-1016-oem | 20:19 |
| mmikowski | -rw-r--r-- 1 root root 165M Sep 1 19:50 initrd.img-5.17.0-1016-oem | 20:19 |
| arraybolt3[m] | (Note I'm using a totally different test system than mmikowski, so my input may be of limited usefulness - internal NVIDIA card on a relatively old desktop.) | 20:19 |
| mmikowski | Nvidia drivers 510. | 20:19 |
| mmikowski | I used a rescue disk and chroot environment to update the build config per https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1842320/comments/41 | 20:20 |
| ubottu | Launchpad bug 1842320 in OEM Priority Project "Can't boot: 'error: out of memory.' immediately after the grub menu" [Critical, Triaged] | 20:20 |
| mmikowski | I believe this along fixed it; I have the NUC right here and I can determine how to reproduce. I expect turning off xz compession will be enough; I don't believe I enlarged the swap file. But I could test that as well. | 20:22 |
| mmikowski | * this along fixed it = this alone fixed it. | 20:22 |
| vorlon | swap file has zero relevance | 20:23 |
| mmikowski | No worries vorlon. That was just speculation about what memory was being used. | 20:23 |
| mmikowski | bdmurray: Good to see you too :) | 20:24 |
| mmikowski | arraybolt3[m]: As always, thank you for your help. I am working on recreating here and testing through hypothesis. Sorry, the original bug was a transient impediment I had to get through before getting other work done, so the documentation wasn't stellar. | 20:58 |
| === justache is now known as justache_test | ||
| === justache_test is now known as justache | ||
| bluca | enr0n: I didn't notice the systemd TEST-58-REPART was also enabled in jammy-proposed by slyon, for that to work on ppc64 you'll need to backport https://github.com/systemd/systemd/commit/8e65d93e85f06e3f2 | 21:51 |
| ubottu | Commit 8e65d93 in systemd/systemd "test: do not assume x86-64 arch in TEST-58-REPART" | 21:51 |
| mmikowski | I've just checked 1013 kernel does not have the issue; 1016 does. Asooubling swapfile size to 2GB does not resolve issue. @bdmurray @ubottu @vorlon @Eickmeyer[m]. | 21:53 |
| mmikowski | To clarify these are oem-5.17.0-1013 through oem-5.17.0-1016 kernels. This behavior does seem to be device specific, and discussed above. | 21:55 |
| mmikowski | Booting through from 1013 kernels up and will report in bug. | 21:58 |
| vorlon | Eickmeyer: it looks like ffmpeg2theora, recommended by ubuntustudio-video, is obsolete; ffmpeg itself supports theora as a codec now, and ffmpeg2theora hasn't seen upstream activity since 2016. Drop from the seed for kinetic? | 22:51 |
| vorlon | Eickmeyer: (I took a stab at porting it, but then hit the inner loop of avcodec_decode_video2() that needs porting and decided life's too short) | 22:51 |
| Eickmeyer[m] | vorlon: Yeah, that sound fine. UNRELATED (perhaps tangentally): still watching digikam and uploading git snapshots periodically in hopes that something stabilizes. | 22:56 |
| vorlon | Eickmeyer[m]: shall I drop ffmpeg2theora from the ubuntustudio seed? | 22:57 |
| Eickmeyer[m] | vorlon: I can do it, I'm in the seed right now and that way I can update the meta too. | 22:57 |
| vorlon | ok | 22:57 |
| Eickmeyer[m] | vorlon: Done. | 23:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!