| wxl | mdeslaur: i noticed you uploaded 0.3.6 of usb-creator. i've a fix i want to upload but i can't find any repo anywhere that has anything beyond 0.3.5. maybe i'm blind. could you offer assistance, at least in matters outside of optometry? | 02:28 |
|---|---|---|
| -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (bionic-proposed) [1.173.7] | 06:06 | |
| -queuebot:#ubuntu-release- Unapproved: accepted linux-firmware [source] (cosmic-proposed) [1.175.5] | 06:13 | |
| -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (bionic-proposed) [1.16.1-1ubuntu1.3] | 08:08 | |
| -queuebot:#ubuntu-release- Unapproved: accepted sssd [source] (xenial-proposed) [1.13.4-1ubuntu1.15] | 08:10 | |
| Laney | infinity: That's like grep-dctrl's Source:Package thing | 08:26 |
| Laney | fauxpkg.py uses that construct elsewhere too | 08:32 |
| -queuebot:#ubuntu-release- Unapproved: gnome-settings-daemon (disco-proposed/main) [3.32.0-1ubuntu1 => 3.32.1-0ubuntu1] (ubuntu-desktop) | 08:32 | |
| Laney | I've pushed that, so if it starts acting up in weird ways you know where to look | 08:32 |
| marcustomlinson | please could someone review my libreoffice bionic sru. It's a relatively important crash fix | 09:44 |
| mdeslaur | wxl: I don't think there's a current repo anywhere | 11:08 |
| mdeslaur | wxl: what's your fix? | 11:08 |
| -queuebot:#ubuntu-release- Unapproved: systemtap (xenial-proposed/universe) [2.9-2ubuntu2 => 2.9-2ubuntu2.1] (no packageset) | 12:46 | |
| wxl[m] | mdeslaur: no repo? That's weird. Was hoping to SRU https://bugs.launchpad.net/ubuntu/+source/usb-creator/+bug/1629715/comments/6 so that the Qt version works *at all* | 13:22 |
| ubot5 | Launchpad bug 1629715 in usb-creator (Ubuntu Disco) "usb-creator-kde shows the install popup after a few seconds of launching without any input" [High,Triaged] | 13:22 |
| mdeslaur | wxl[m]: ok, wait before you do because I have some updates pending in the security team PPA here: https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages | 13:26 |
| mdeslaur | wxl[m]: I'll release them in the next few days, then you can base your SRUs on them | 13:27 |
| === kyrofa_ is now known as kyrofa | ||
| xnox | vorlon: 35 files changed, 1482 insertions(+), 251 deletions(-) | 17:05 |
| vorlon | xnox: deletions?! | 17:05 |
| vorlon | xnox: sounds like you need to do msgmerge instead of copying the files | 17:05 |
| vorlon | to not clobber translations of the existing templates | 17:06 |
| xnox | vorlon: somehow || RET="false" sounds easier. | 17:06 |
| xnox | vorlon: oh, you thought .po files were uptodate in openssl, huh?!=) | 17:06 |
| xnox | -#: ../libssl1.0.0.templates:1001 | 17:06 |
| xnox | +#: ../libssl1.1.templates:1001 | 17:06 |
| vorlon | heh | 17:06 |
| xnox | as produced by debconf-updatepo | 17:06 |
| vorlon | xnox: I don't mind reviewing obviously correct changes to templates | 17:06 |
| xnox | https://paste.ubuntu.com/p/CPKcndMbtQ/ is how i generated the thing | 17:07 |
| xnox | i hate gettext =) | 17:07 |
| vorlon | whereas I just get hatetext | 17:07 |
| vorlon | xnox: could the debconf-updatepo step be skipped? since it should only munge comments | 17:09 |
| xnox | true | 17:19 |
| -queuebot:#ubuntu-release- Unapproved: openssl (disco-proposed/main) [1.1.1b-1ubuntu2.3 => 1.1.1b-1ubuntu2.4] (core) | 17:35 | |
| -queuebot:#ubuntu-release- Unapproved: openssl (cosmic-proposed/main) [1.1.1-1ubuntu2.4 => 1.1.1-1ubuntu2.5] (core) | 17:36 | |
| xnox | vorlon: openssl is green on bionic, no adt regressions, but only 5 days. Could you release that to updates early? (sil is away today) | 18:01 |
| xnox | vorlon: then review templates thing that will land into bionic-proposed unapproved shortly and published that into -proposed. | 18:01 |
| xnox | vorlon: fixes on other releases are not verified yet, so can't release pending cosmic/disco SRUs (and still waiting for adt retries) but those releases are also not urgent at the moment to fix up | 18:02 |
| xnox | (not as urgent) | 18:02 |
| wxl | mdeslaur: cool thx | 18:17 |
| tsimonq2 | vorlon (last merger), xnox (TIL): In Lubuntu, we found a regression in initramfs-tools which only exists in Eoan. A workaround has been applied to our Calamares configuration, but from what I can tell, initramfs-tools still needs fixing. Full details including the precise problem are in bug 1829805; I don't want to step on toes and JFD the bugfix, so I wanted to ping and get your input. | 18:45 |
| ubot5 | bug 1829805 in initramfs-tools (Ubuntu) "Lubuntu Eoan Daily Image fails to boot after install on KVM" [High,Triaged] https://launchpad.net/bugs/1829805 | 18:45 |
| tsimonq2 | (Of course, if you *want* me to JFD a bugfix, I will do so. ;) ) | 18:46 |
| xnox | tsimonq2: i've read the whole bug and it's not clear to me | 18:49 |
| xnox | tsimonq2: what the bug in initramfs-tools is. | 18:50 |
| tsimonq2 | xnox: The bug description should be revised to include TJ-'s findings: https://bugs.launchpad.net/ubuntu/+source/calamares-settings-ubuntu/+bug/1829805/comments/13 | 18:50 |
| xnox | tsimonq2: ie. under this conditions, running this does not build an initrd. | 18:50 |
| ubot5 | Launchpad bug 1829805 in initramfs-tools (Ubuntu) "Lubuntu Eoan Daily Image fails to boot after install on KVM" [High,Triaged] | 18:50 |
| xnox | tsimonq2: because as it stands now, it's impossible for me to understand what you want changed in initramfs-tools and/or how it has regressed. | 18:50 |
| xnox | tsimonq2: still do not understand. | 18:51 |
| xnox | tsimonq2: what's the steps to reproduce it without any calamares stuff in the way? | 18:51 |
| xnox | tsimonq2: ie. remove these files; ask to create new initrd using this options; it doesn't do that | 18:52 |
| tsimonq2 | xnox: Again, see TJ-'s comment. Run "update-initramfs -k all -c -t" prior to the initramfs generation in a fresh-installed system. | 18:52 |
| xnox | tsimonq2: something like that. | 18:52 |
| xnox | tsimonq2: what fresh-installed system..... | 18:52 |
| tsimonq2 | xnox: Fresh-installed-before-system-is-finalized. I can write clear, reproducable instructions if you wish. | 18:53 |
| tsimonq2 | xnox: i.e. generation of an initramfs before one actually exists. | 18:54 |
| xnox | tsimonq2: what is "-t" for ? that arg does not exist? | 18:55 |
| xnox | tsimonq2: i did "sudo rm /boot/initrd.img*; sudo update-initramfs -c -k all" and that didn't produce any initrds. Which is ok. | 18:56 |
| xnox | tsimonq2: normally the first initrd is produced by kernel getting installed. | 18:57 |
| xnox | tsimonq2: how did the kernel get installed? and has kernel's postinst executed? | 18:57 |
| tsimonq2 | xnox: Have you verified that immediately after copying the squashfs, the initrd exists? | 18:57 |
| xnox | tsimonq2: i'm not running calamares installer.... nor squashfs. | 18:57 |
| tsimonq2 | xnox: I'm unsure that a clean squashfs for an Ubuntu image contains a kernel whose postinst has been executed. | 18:57 |
| xnox | tsimonq2: if this is a bug in `-k all` handing of update-initramfs, it should be reproducible on a running system too. | 18:58 |
| tsimonq2 | xnox: which is ok> I disagree with that. | 18:58 |
| tsimonq2 | xnox: You found the bug, but you're making false assumptions. | 18:58 |
| xnox | tsimonq2: please don't get into how installer work. we just need to identify regression in initramfs-tools and report upstream to debian. | 18:58 |
| tsimonq2 | xnox: The context for why this bug exists is in the installer. | 18:59 |
| xnox | tsimonq2: and they will not be interested in squashfs, calamares, ubiquity, curtin or anything. | 18:59 |
| tsimonq2 | xnox: You're misunderstanding my point. | 18:59 |
| tsimonq2 | xnox: You're making the assumption that at all times, if a kernel is installed, the initrd is present. I'm unsure that is the case with the root squashfs of an ISO. | 18:59 |
| tsimonq2 | xnox: I'm simply asking you to verify that assumption. | 19:00 |
| tsimonq2 | xnox: You don't need to care about the installer, at all. | 19:00 |
| tsimonq2 | xnox: Just "does initrd exist on a fresh squashfs"? | 19:00 |
| tsimonq2 | xnox: I can grab one now to see for myself if that helps? | 19:01 |
| xnox | curtin / subiquity / ubiquity, install base systems without kernels. | 19:02 |
| xnox | and without prebuild initrds. | 19:02 |
| xnox | and create the first initrd for target, in-target. | 19:02 |
| xnox | tsimonq2: and no, the question i asked, has not been answered. i commented on the bug. | 19:02 |
| tsimonq2 | How does it create the initrd, just by running the kernel postinst? | 19:02 |
| xnox | tsimonq2: it doesn't matter how, if you say there is a regression in the initramfs. | 19:03 |
| xnox | tsimonq2: and it should be possible to get to that state. | 19:03 |
| xnox | tsimonq2: it seems like calamares is trying to create an initrd, without any kernels installed..... for which no initrd can be created. Unless one expects it to have no kernel modules, but then it cannot be called "all" | 19:04 |
| xnox | tsimonq2: but that is just a guess. | 19:04 |
| xnox | tsimonq2: hence the question how to reproduce the problem at hand. | 19:04 |
| tsimonq2 | xnox: Okay, you can reproduce this by copying the squashfs somewhere where you can read/write, mount the appropriate directories, chroot into the system, and run the above update-initramfs command. | 19:04 |
| xnox | without any installers in the way, just initramfs-tools by itself. | 19:04 |
| tsimonq2 | xnox: The kernels *are* installed. | 19:04 |
| xnox | one really should not need squashfs to reproduce anything. | 19:04 |
| tsimonq2 | xnox: The initrd just isn't there. | 19:04 |
| tsimonq2 | ... | 19:04 |
| tsimonq2 | It's all about context, xnox. | 19:05 |
| tsimonq2 | This isn't a usual, glaring bug. | 19:05 |
| tsimonq2 | You just told me that the installer does the work of generating the initrd, but you're also telling me that if a kernel is present, the initrd is also present. | 19:06 |
| tsimonq2 | Those are incompatible in a squashfs that has a kernel but no initrd. | 19:06 |
| xnox | i never told you that initrd is also present if a kernel is present. | 19:06 |
| tsimonq2 | 01:56:53 PM < xnox> tsimonq2: i did "sudo rm /boot/initrd.img*; sudo update-initramfs -c -k all" and that didn't produce any initrds. Which is ok. | 19:06 |
| tsimonq2 | This is the bug. | 19:07 |
| xnox | most of our systems boot without initrd these days. | 19:07 |
| tsimonq2 | xnox: Ok, so that's what update-initramfs is assuming then. | 19:07 |
| tsimonq2 | If a kernel is present, so is the initrd. | 19:07 |
| tsimonq2 | That's the case *most* of the time. | 19:07 |
| xnox | tsimonq2: then report it upstream using those steps to debian, and double check it is failing in debian. | 19:07 |
| tsimonq2 | Yep, I plan on it. :)_ | 19:07 |
| xnox | then we can cherrypick upstream fixes for this issue. | 19:08 |
| xnox | tsimonq2: as per man-page | 19:09 |
| xnox | The use of "all" for the version string specifies update-initramfs to execute the | 19:09 |
| xnox | chosen action for all kernel versions, that are already known to update-initramfs. | 19:09 |
| tsimonq2 | xnox: I just don't want to get scolded for stealing TIL once we have the bugfix (although that seems to be a standard applied for some packages and not others...) | 19:09 |
| tsimonq2 | xnox: The version detection is done by reading which initrds are there. | 19:09 |
| tsimonq2 | xnox: Not via uname or related tools. | 19:09 |
| tsimonq2 | xnox: The logic needs to be improved. | 19:09 |
| xnox | that's as per documentation.... | 19:09 |
| tsimonq2 | Yes, and that's a bug. | 19:10 |
| xnox | report it to debian | 19:10 |
| tsimonq2 | I will. | 19:10 |
| xnox | as per man-page to make a kernel version known to update-initramfs, is to call it with -c and explicit version number | 19:10 |
| xnox | which is what kernel maintainer scripts do | 19:10 |
| xnox | hence post laying the disc, e.g. ubiquity reruns dpkg-reconfigure on the kernel packages | 19:11 |
| xnox | cause kernel maintainer scripts know their correct version, and know how to call update-initramfs with -c -k correctly | 19:11 |
| tsimonq2 | ack, I'll talk to the Debian maintainers, though. | 19:11 |
| xnox | indeed. | 19:12 |
| tsimonq2 | I think the discussion is done here. :) | 19:12 |
| -queuebot:#ubuntu-release- New source: ubuntustudio-menu-add (eoan-proposed/primary) [0.1] | 19:14 | |
| vorlon | tsimonq2: this may or may not be a regression in initramfs-tools, that's fine; but *why* do you have a squashfs containing a kernel but not an initrd? | 20:04 |
| vorlon | (if the answer is "that's what we get out of livecd-rootfs", then ok; I think that's also a bug and we should own it) | 20:05 |
| infinity | It shouldn't have either, ideally, *but* that's not really relevant. | 20:14 |
| infinity | The linux-image package is "installed", then we build an initrd, move kernel and initrd out (so we don't ship two copies), and let the installer move vmlinuz back and create a proper initrd. | 20:15 |
| infinity | Evidently, however ubiquity does the last bit works fine, however calamares does doesn't. | 20:15 |
| * vorlon nods | 20:21 | |
| -queuebot:#ubuntu-release- Unapproved: openssl (bionic-proposed/main) [1.1.1-1ubuntu2.1~18.04.3 => 1.1.1-1ubuntu2.1~18.04.4] (core) (sync) | 20:29 | |
| xnox | infinity: well ubiquity iterates and call /var/lib/dpkg/info/$pkg.postinst configure on "linux-*" stuff. | 20:30 |
| tsimonq2 | vorlon: Yeah, it comes from livecd-rootfs. | 20:31 |
| infinity | Which works, but is overkill for "regenerate all my initrds please" since initramfs-tools saves state and is meant to know which ones it has. | 20:31 |
| infinity | $ ls -l /var/lib/initramfs-tools/ | 20:31 |
| infinity | total 8 | 20:31 |
| infinity | -rw-r--r-- 1 root root 79 Jun 17 13:48 5.0.0-16-lowlatency | 20:31 |
| infinity | -rw-r--r-- 1 root root 79 Jun 20 00:31 5.0.0-17-lowlatency | 20:31 |
| vorlon | infinity: yeh except that state saving is itself terrible and we've had bugs in the past where initramfses grow back in /boot long after the kernel package they map to has been removed :P | 20:32 |
| infinity | It's meant to read those stamp files to decide what "-k all" means. | 20:32 |
| infinity | vorlon: Those cases were people manually deleting stuff from /boot instead of actually uninstalling kernel packages, weren't they? | 20:32 |
| xnox | vorlon: openssl sync for you to verify. I have figured a reproducer. I downgrade lxd container back to bionic-security, and then can upgrade to reproduce the issue => after purging the debconf database for libc6/pam packages. And yeah, upgrade to bionic-updates fails, but to the CI train ppa passes. | 20:32 |
| vorlon | infinity: not in my case, no | 20:33 |
| xnox | vorlon: and it is, just like you said, "just add more templates" | 20:33 |
| vorlon | infinity: (I experienced this myself) | 20:33 |
| vorlon | xnox: ack | 20:33 |
| * xnox promises to never touch openssl again | 20:33 | |
| tsimonq2 | infinity: I don't quite understand if you're implying this is a Calamares issue or an initramfs-tools issue. Shouldn't initramfs-tools be smart enough to read currently-installed kernels and think "oh, gee, I think I should generate an initrd for that"? | 20:34 |
| infinity | tsimonq2: It's more complex than "currently installed kernels", it's "currently installed kernels that I've been asked to create an initrd for in the past". | 20:34 |
| xnox | tsimonq2: i think the question is "did calamares always do the same thing" and "did the same thing was actually the same" and "did something change in initramfs / livecd-rootfs / etc" to change what is happening. | 20:34 |
| infinity | But yes, I'm arguing that if this has stopped working, it's an initramfs-tools bug, but that doesn't preclude calamares also being more explicit about what it asks for. | 20:35 |
| xnox | tsimonq2: cause i'm interested to know if it's just new code, or we have a real regression somewhere in the stack between livebuild -> postinstall boot. | 20:35 |
| xnox | which is a lot of moving pieces. | 20:35 |
| tsimonq2 | infinity: That's fair. I'll file Debian and upstream Calamares bugs. | 20:35 |
| tsimonq2 | xnox: The update-initramfs call in Calamares hasn't changed. | 20:35 |
| tsimonq2 | xnox: As the comment I keep pointing you to states, it's a specific commit in initramfs-tools we can point to. | 20:36 |
| xnox | tsimonq2: did the state on disk prior the call, now different between prior releases and eoan? | 20:36 |
| wxl | the last time it effectively changed in calamares was 2017 https://github.com/calamares/calamares/commit/086a019d19cc32c28731c7f65a55ffdad94f4ec3 | 20:36 |
| tsimonq2 | xnox: I don't quite understand your question. | 20:36 |
| xnox | tsimonq2: or is it just update-initramfs? | 20:36 |
| tsimonq2 | Oh, no, state on disk didn't change. | 20:36 |
| tsimonq2 | As far as I can tell, only update-initramfs changed. | 20:37 |
| infinity | So, testing locally, initramfs-tools feels regressed to me. | 20:37 |
| xnox | tsimonq2: ie. disco, at the point when that call is made used to look different to how eoan now looks. | 20:37 |
| xnox | tsimonq2: ack. | 20:37 |
| xnox | infinity: which does match documentation. | 20:37 |
| xnox | infinity: so i'm not sure if it regressed and docs were always wrong. | 20:37 |
| infinity | xnox: Erm, wat? | 20:37 |
| xnox | The use of "all" for the version string specifies update-initramfs to execute the | 20:38 |
| xnox | chosen action for all kernel versions, that are already known to update-initramfs. | 20:38 |
| xnox | whatever "known to update-initramfs" means | 20:38 |
| infinity | xnox: "known to update-initramfs" is "listed in /var/lib/initramfs-tools" | 20:38 |
| infinity | Or, was. | 20:38 |
| infinity | And now it's not. | 20:38 |
| infinity | So yes, this is regressed, and no longer matches docs. | 20:38 |
| infinity | If I delete my initrd, it doesn't come back with -k all. | 20:39 |
| xnox | ooooh | 20:39 |
| xnox | infinity: indeed, i see things in var/lib/initramfs-tools. | 20:39 |
| tsimonq2 | infinity: Right, and that's precisely the bug here. | 20:39 |
| * xnox learned about /var/lib/initramfs-tools today | 20:39 | |
| * tsimonq2 goes afk to do collegy stuff. | 20:39 | |
| xnox | tsimonq2: i presume the ondisk has relevant kernels mentioned in /var/lib/initramfs-tools too | 20:39 |
| xnox | (when calamares calls things) | 20:40 |
| -queuebot:#ubuntu-release- Unapproved: accepted openssl [sync] (bionic-proposed) [1.1.1-1ubuntu2.1~18.04.4] | 20:47 | |
| infinity | get_sorted_versions() | 20:52 |
| infinity | { | 20:52 |
| infinity | - version_list="$(ls -1 "${STATEDIR}" | linux-version sort --reverse)" | 20:52 |
| infinity | - | 20:52 |
| infinity | + version_list="$( | 20:52 |
| infinity | + linux-version list | | 20:52 |
| infinity | + while read -r version; do | 20:52 |
| infinity | + test -e "${BOOTDIR}/initrd.img-$version" && echo "$version" | 20:52 |
| infinity | + done | | 20:52 |
| infinity | + linux-version sort --reverse | 20:52 |
| infinity | + )" | 20:52 |
| infinity | verbose "Available versions: ${version_list}" | 20:52 |
| infinity | } | 20:52 |
| infinity | That appears to completely ignore STATEDIR now. | 20:52 |
| infinity | And 'linux-version list' doesn't list -17 on my system. Which seems suspect. | 20:55 |
| -queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (cosmic-proposed) [1.1.1-1ubuntu2.5] | 20:56 | |
| -queuebot:#ubuntu-release- Unapproved: accepted openssl [source] (disco-proposed) [1.1.1b-1ubuntu2.4] | 20:57 | |
| infinity | Wait. Now I'm confused. :) | 20:58 |
| infinity | Oh. I deleted a kernel while debugging. I'm SMRT. | 20:58 |
| infinity | Anyhow, the behaviour change above is that it switched from checking STATEDIR to stating the initrd. | 20:59 |
| infinity | So, instead of "statedir knows what we've done in the past", we have "in you have no initrd, you can't have a new one either". | 20:59 |
| infinity | s/in you/if you/ | 20:59 |
| infinity | https://salsa.debian.org/kernel-team/initramfs-tools/commit/f39625afd6ba6c1aa2027286dc3ef1c933da14e0 | 21:02 |
| infinity | vorlon: That would be the offending commit. I think the obvious way to get both old and new behaviour combined would just be to add the statedir bit to the list (and sort -u the mess). | 21:03 |
| vorlon | infinity: no opinion :) | 21:13 |
| -queuebot:#ubuntu-release- Unapproved: accepted newlib [source] (bionic-proposed) [2.4.0.20160527-3ubuntu0.1] | 22:37 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!