[00:50] <mwhudson> does our cross toolchain stuff really have to be as brain-bending as it is
=== guiverc2 is now known as guiverc
[05:39] <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!
[08:31] <mwhudson> stevenm_: it'll be in partman-efi somewhere i guess
[08:33] <mwhudson> stevenm_: https://git.launchpad.net/ubiquity/tree/d-i/source/partman-efi/commit.d/format_efi
[08:36] <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:37] <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:40] <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:49] <cpaelzer> well, no more reproducible ... giving up but at least updated 1920640
[08:54] <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:55] <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:56] <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:57] <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
=== sem2peie- is now known as sem2peie
=== sem2peie- is now known as sem2peie
[11:55] <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?
[12:00] <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:01] <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:02] <tumbleweed> does that really have to happen before the package gets unpacked?
[12:03] <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:04] <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:05] <ogra> also ... it should not be *bash* but POSIX shell code 😉
[12:05] <ogra> (ubuntu uses dash as /bin/sh, not bash)
[12:41] <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!
[13:16] <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:17] <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:19] <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:24] <P-NuT> oh right on thanks for the heads up.
[14:51] <enr0n> Can a core-dev please retry these tests? These are historically flaky. retry-autopkgtest-regressions --blocks systemd -s jammy | grep -E "udisks|gvfs"
[15:01] <ginggs> enr0n: looking...
[15:07] <ginggs> enr0n: done, and what about systemd's own test on ppc64el?
[15:08] <enr0n> ginggs: thanks! I was going to retry that one locally first, but I am fine with it being retried anyways
[15:10] <ginggs> enr0n: retried that one as well
[15:10] <enr0n> ginggs: thanks again!
=== genii_ is now known as genii
[16:43] <tsimonq2> Does anyone have an idea on whether preseeding snaps in an install chroot is documented?
[16:44] <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:45] <ogra> tsimonq2, snapd des not run in chroots ...
[16:45] <ogra> *does
[16:46] <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:47] <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:48] <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:50] <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:51] <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:52] <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:54] <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:55] <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:57] <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?
[17:54] <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:55] <bdmurray> It'd most likely appear as proxy errors.
[18:52] <Eickmeyer[m]> bdmurray: Is there a known issue with swapfiles being too small (e.g. defaulting to 1024) and overfilling?
[18:54] <bdmurray> Eickmeyer[m]: not that I can recall immediately but I might have heard vorlon talking about it
[18:57] <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.
[19:11] <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:12] <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:13] <Eickmeyer[m]> We're not seeing that. The swapfile on 16GB RAM was showing as 1GB.
[19:14] <vorlon> not seeing what?
[19:14] <vorlon> 16GB RAM + 0 swap >= 8GiB RAM+swap
[19:15] <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:16] <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:17] <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:18] <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:19] <Eickmeyer[m]> mmikowski: When you have a minute, please reply to vorlon above.
[19:23] <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:45] <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:46] <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:48] <Eickmeyer[m]> arraybolt3: That's my thought.
[19:49] <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:50] <Eickmeyer[m]> arraybolt3: After the end-user setup.
=== arraybolt3_ is now known as arraybolt3
[19:57] <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:58] <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
[20:03] <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:04] <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:05] <Eickmeyer[m]> Make sure your'e not on secure boot.
[20:07] <arraybolt3[m]> OK, good. Then the moment of truth has arrives.
[20:08] <arraybolt3[m]> Yes, has arrives. Because I can't type.
[20:08] <arraybolt3[m]> s/arrives/arrived/
[20:11] <mmikowski> vorlon: Hi, this is mike. Eickmeyer[m] asked me to giv you a bump.
[20:12] <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:13] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:22] <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:23] <vorlon> swap file has zero relevance
[20:23] <mmikowski> No worries vorlon.  That was just speculation about what memory was being used.
[20:24] <mmikowski> bdmurray: Good to see you too :)
[20:58] <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.
=== justache is now known as justache_test
=== justache_test is now known as justache
[21:51] <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:53] <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:55] <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:58] <mmikowski> Booting through from 1013 kernels up and will report in bug.
[22:51] <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:56] <Eickmeyer[m]> vorlon: Yeah, that sound fine. UNRELATED (perhaps tangentally): still watching digikam and uploading git snapshots periodically in hopes that something stabilizes.
[22:57] <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
[23:07] <Eickmeyer[m]> vorlon: Done.