[09:28] hello everyone! [09:29] in 22.04 and kinetic it takes almost 20s to get from grub's "boot now" (Ctrl+X) to the first line of kernel output, even with enabling "debug" [09:30] with Fedora that takes a mere 3s; any idea how to debug that? it feels like grub takes an awful amount of time to unpack the kernel or so? [09:37] indeed when I drop the "initrd" line, it boots almost immediately (of course with a kernel panic, as it can't find the root fs); but that points to awfully slow initrd unpacking [09:52] eww -- initrd.img-5.15.0-41-generic is 102 MB! no wonder it takes so long [10:45] pitti: mine are only 35 MB, i use: /etc/initramfs-tools/conf.d/compress:COMPRESS=xz [10:45] oh wait 22.04 110 MB, 35 MB was 20.04 [10:46] I left my observation in https://bugs.launchpad.net/cloud-images/+bug/1592684/comments/8 [10:46] Launchpad bug 1592684 in cloud-init (Ubuntu) "Add MODULES=dep initramfs configuration" [Wishlist, Triaged] [13:59] Is anyone working on the Haskell transition? I've been digging into it, but some of the issues seem quite deep. [14:03] pitti, hey. could that also have to do with the compression in use? what kind of hardware are you seing those numbers on? [14:09] seb128: yes, could be -- even decompressing 100 MB shouldn't take 18 MB; I see it in qemu-system-x86_64 -enable-kvm with the defaults (1 CPU, $whatever model) and 2 GiB RAM [14:10] but either way, I got it down to 18 MB and < 2s now, good enough [14:16] pitti, nice improvement :) [14:20] "even decompressing 100 MB shouldn't take 18 MB" -- d'oh, of course I meant "18 seconds" 🙈 [14:24] :) [14:25] still weird indeed, on a modern hardware in a qemu even with 1 CPU I would expect decompression to not be that slow :/ [14:27] Hey folks, not sure if these MPs are monitored so: I have a small fix to avoid reporting that NBD devices will get fsck'd: https://code.launchpad.net/~oddbloke/update-notifier/+git/update-notifier/+merge/427497 [14:53] Retest click please? retry-autopkgtest-regressions|grep package=livecd-rootfs [15:36] vorlon: How would you like to proceed on digikam? I can upload my fix now, or you can upload a with a patch to port it to ffmpeg5, or I can do mine now and you can do yours later or not at all? [15:43] dbungert: I'll retry them and use it as an opportunity to try out --blocked-by-tests