[00:46] Hrm, any idea when riscv will be available for PPAs? [00:56] Unit193: I've got a checkbox on one of my ppas, though maybe I have that due to magic powers [00:56] My box is all grayed out. [00:56] oh :( [00:57] Which normally I don't care about riscv at all, but something is failing only there, and for some silly reason it's not migrating. [00:57] Unit193: probably the way to find out if you can have it flipped is to file a question on the launchpad questions section [00:57] Unit193: I think some of the biletto ppas have it enabled too, would that be any help? [00:57] sarnold: Well...I don't really want special treatment if it's not really ready yet. :3 [00:57] (I've never tried these) [00:57] I have no idea how to use those either. :D [00:57] hehe [01:24] Unit193: heh, was it failing package tests? https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1891686 [01:24] Launchpad bug 1891686 in dpkg (Ubuntu) "Please default to nocheck on riscv64" [Undecided,Fix released] [01:40] mwhudson: if it helps, this is the diff of what has been installed in gjs (+ proposed) vs the failing one: https://paste.ubuntu.com/p/VDTQpzVWQT/ [01:40] mwhudson: gobject-introspection amd64 1.64.1-1build2 looks to be a good candidate [01:42] Trevinho: yeah, sounds plausible [01:43] mwhudson: you can probably do a build1 with that, or I can but tomorrow [01:43] Trevinho: well it's also part of the libffi transition so they will migrate together [01:43] yeah, sure, I mean if we need to have a specific b-d for britney happyness [01:44] i don't think so [01:44] thanks for checking though! [02:23] sarnold: FTBFS. [07:04] Hi, I noticed that the filesystem.squashfs in the Groovy Gorilla daily builds have /boot/vmlinuz and /boot/initrd.img as broken symlinks. They point to initrd.img-* and vmlinuz-*, which do not exist. I was building a custom Ubuntu ISO from an existing Ubuntu 20.10 daily ISO using the chroot method. I copied the initramfs from the /casper/ directory [07:04] in the custom disk and installed the linux-image in the chroot, as I needed to change the plymouth logo. I then ran update-initramfs -u -k all inside the chroot. I copied /boot/initrd.img to /casper/ and built the ISO. When I booted the ISO in a VM, it showed the plymouth boot screen for one second, after which it dropped to the BusyBox initramfs [07:04] prompt. Did something change in 20.10? I'm not aware of any change apart from the switch to GRUB for both BIOS and UEFI. === cpaelzer__ is now known as cpaelzer === didrocks999 is now known as didrocks [12:08] Laney i think the autopkgtest armhf lxd-worker needs to be restarted to pick up a worker.conf change, to make haveged a long_test; it is still running it with the default timeout, though haveged was added to long_tests a week or so ago [12:08] could you check it when you have a chance? [12:08] ddstreet: it does, who deployed it? [12:08] they might need some education [12:08] * Laney brings out the education stick [12:08] Laney you mean who deployed autopkgtest? this is on the official builders https://autopkgtest.ubuntu.com/packages/h/haveged/groovy/armhf [12:08] who merged the config change [12:09] oh, i think vorlon [12:09] https://git.launchpad.net/autopkgtest-cloud/commit/?id=5763aed3a3a1c1eb3839bf74263f885ae979527e [12:10] right, missed being done on armhf [12:10] done now [12:10] thanks! [15:02] rs2009: is this desktop or server? [15:03] rs2009: did you also specify environmental variable to trigger casper initrd to be generated with uuid checks? [15:18] xnox: This is the desktop variant. I wasn't building a daily image, rather was chrooting into the ISO and making some changes, and then rebuilding the ISO. === smoser1 is now known as smoser [15:19] rs2009: when rebuilding initrd you must set CASPER_GENERATE_UUID environment variable. [15:19] rs2009: or have grub.cfg to have boot=casper [15:19] in kernel commandline. [15:20] xnox: I already have boot=casper in the kernel commandline. [15:20] rs2009: by default we build initrd for the iso with CASPER_GENERATE_UUID=y set, matching uuid committed on the iso in .disk/, and with clean kernel commandline. [15:20] rs2009: in that case i don't know why your boot failed. and you do not give enough information for me to suggest antyhing to you. [15:21] rs2009: it sounds like you have missbuilt your kernel/initrd pair, and it doesn't match the rest of the iso. [15:23] xnox: I was building a custom Ubuntu ISO from an existing Ubuntu 20.10 daily ISO (using the chroot method) when I saw that /boot/initrd.img and /boot/vmlinuz are broken symlinks in filesystem.squashfs. I copied the initramfs from the /casper/ directory in the custom disk and installed the linux-image in the chroot, as I needed to change the [15:23] plymouth logo. I then ran update-initramfs -u -k all inside the chroot. I copied /boot/initrd.img to /casper/ and built the ISO. When I booted the ISO in a VM, it showed the plymouth boot screen for one second, after which it dropped to the BusyBox initramfs prompt. [15:28] xnox: the daily ISO has 5.4.0-42-generic (checked in /lib/modules) and the initrd kernel version corresponds to it. [15:33] xnox: This issue does not happen with the default initramfs, rather with an initramfs built with update-initramfs [15:33] rbalint: https://launchpadlibrarian.net/495890903/buildlog_ubuntu-groovy-armhf.mozjs78_78.2.0-1~fakesync1_BUILDING.txt.gz does this interest you? [15:34] also, I saw your ping on that autopkgtest-cloud MR, will review this week [15:34] rs2009: you should have no need to install linux-image.... as that one might be different from the rest of iso. [15:34] rs2009: and you should restore initrd&vmlinuz from casper into where the broken links point to. [15:35] rs2009: and you should generate new initrd for that same kernel version, not any other different one. [15:35] rs2009: calling update-initramfs without environment variables set, and without correct kernel version as installed in the chroot, will not generate a complete nor valid initrd usable for cd boot. [15:37] xnox: The issue happens without linux-image as well. I had restored the initrd and vmlinuz to where the broken links point to. I was building the initramfs for the kernel in the ISO only. I did not know that it was mandatory to build with CASPER_GENERATE_UUID=y set. I thought it wasn't required if boot=casper was being added to the command line. [15:39] rs2009: and how did you rebuild the initrd? which kernel version did you specify? [15:40] rs2009: after you build with CASPER_GENERATE_UUID=y you also need to copy out the same uuid into the iso. otherwise there will be uuid-missmatch and you will fail to boot. [15:41] xnox: I used update-initramfs and specified 5.4.0-42-generic which I found in /lib/modules/. [15:42] rs2009: yeap that's the right version number, so that should have worked. [15:42] xnox: I'm trying out CASPER_GENERATE_UUID=y right now [15:42] generate initrd with UUID, copy it out and place it on the iso in .disk/ dir, remaster the iso and hopefully things will start working [15:43] if they don't, edit kernel cmdline and append ignore_uuid to ignore uuid missmatch, to doulbe check if that's what's causing the failure to boot [15:59] xnox: ignore_uuid works, so it looks to be an issue with the UUID. I couldn't find the UUID in the output of update-initramfs. [16:33] rs2009: it's inside the initrd.... one has to unpack it to copy it into the .disk/uuid [16:34] xnox: Yes, I was doing that :) Thank you for your help! [19:54] Laney, re: MR, thanks! re: mozjs, no, sorry, i'd like to get glibc rounds done first