=== WrathOfA1hilles is now known as WrathOfAchilles === gpiccoli_ is now known as gpiccoli [17:02] vorlon: There are a lot of new grub-installer bug failures will older media fail to install grub? [18:15] bdmurray: should not [20:55] vorlon: there are quite a few with the following error - "grub-installer: grub-install: error: failed to register the EFI boot entry: Operation not permitted." [20:58] I've seen a *lot* of those [20:58] Is *lot* > "quite a few" ? [20:58] and I don't recall seeing a satisfying explanation of what causes those [20:59] bdmurray: well, it's more than several by a bunch [20:59] such precise metrics :) [21:15] bdmurray: that's not a new failure; we have a number of older reports like that, and ultimately it comes down to some sort of incompatibility between libefivar and the firmware. (Not sure if it's a firmware bug or a client software bug) [21:16] those grubs error are probably the most reported issues on launchpad [21:16] it feels wrong that we never tried to figure the problem out or to properly message it to user... [21:16] it's firmware-dependent [21:17] so if someone has a machine where they can reproduce it, I'm happy to debug [21:17] still, it's hitting lot of users and we are not doing much for them [21:17] well, we get almost daily reports for years but we ignore those [21:17] but all the reports we've gotten in LP have been drive-bys from people who don't follow up [21:17] do we have any debug instructions we could end to users to get some data? [21:17] I don't ignore them; I follow up and get no response [21:18] dmidecode? [21:18] I would disagree with that, most reports didn't get a reply [21:18] then I don't know where they're filing the bugs [21:19] ubiquity or grub2 in most cases [21:19] anyway, if we had a stock reply with instructions on what debug commands are useful that would be nice [21:24] I should be able to script commenting on the bugs with the commands and we can see what happens. [21:26] vorlon, replying to your question, https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bugs?orderby=-id&start=0 [21:27] 1377 New bugs [21:28] it's daily report of install failures of that type or of Invalid argument errors [21:28] ok well it's non-trivial to sort through the logs that get attached to ubiquity bug reports to classify these bugs [21:29] the ones that get filed against shim-signed and grub2 have clear logs and generally get triaged... without follow-up from submitters [21:30] follow-up is probably tricky indeed [21:30] some have logs though [21:30] again, logs are useless, this is a firmware-specific problem and no one I know has affected firmware [21:30] e.g https://bugs.launchpad.net/ubuntu/+source/grub-installer/+bug/1874610 from 'boot-repair' whatever that is, e.g https://launchpadlibrarian.net/481279131/plain so it's likely those users would reply if we had followed up [21:30] Launchpad bug 1874610 in grub-installer (Ubuntu) "error: failed to register the EFI boot entry: Operation not permitted." [Undecided,Confirmed] [21:31] boot-repair ugh [21:31] ah that one at least lists a machine model [21:31] we should at least be able to tweak the apport hook to collect the info that would be useful [21:32] if what we need is a list of hardware references [21:32] vendor/model of laptops or similar [21:32] what we really need isn't to know what the machine is, but to have access to an affected machine to debug [21:32] I don't suppose cert has a Dell Latitude e7270 [21:32] well, knowing the machine could allow us to maybe talk to the vendor to get one of those [21:33] * vorlon nods [21:34] also, fwiw, at least some of these are matters of firmware configurations that are incompatible with installing Ubuntu - because they have a firmware setting that locks the boot order [21:35] I don't know what we can do to improve the user's experience in that case; the failure happens at the end of the install, and requires a reboot to get into the firmware to fix the setting [21:35] could that be tested via a no-op write at the start? [21:36] possibly [21:36] I suppose if we actually had one of those machines to tst one, we'd know :) heh [21:36] we started poking at bios setting to warn users upfront about issues with e.g rts disk setups [21:36] maybe we could something similar for those situations? [21:37] (rts->rst) === antoine2 is now known as antoine [22:50] Trevinho: hi do you know what the story is with gjs and its autopkgtests? [22:51] mwhudson: not really, I've seen the failures this morning but I was a bit busy with other sides of the stack, but it's not clear to me what's failing, given they worked fine at build time [22:52] Trevinho: ah i bet they need to be run with the libffi from proposed [22:52] although no, i tried that yesterday [22:52] mwhudson: I need to check it closely, however, ideally we're soon importing a new mozjs and gjs versions anyways [22:52] mwhudson: yeah, I was thinking libffi could be related [22:53] mwhudson: iirc I built with proposed in my sbuild and they went well [22:53] Trevinho: the same tests are run at build and autopkgtest time? [22:53] i guess i can retry with all-proposed=1 [22:55] Trevinho: how soon is "soon", it's one of the things blocking the libffi transition [22:55] although ghc is also blocking the libffi transition and that has a few more days of hamster-wheel spinning at best [22:56] mwhudson: so, I checked I tested with proposed... but let me retry [22:57] mwhudson: as per "soon", I've uploaded mozjs78 in debian and it's in new there, so would just need a sync in ubuntu (and NEW approval), same for new gjs, it's in experimental... [22:57] Trevinho: well as you say the builds passed on launchpad, so if that runs the same tests then it *should* work with all-proposed=1 [22:57] unless it's vm vs chroot or kernel versions or some such [23:00] mwhudson: I didn't rebuild in LP after transition I think, as I did it before uploading... So it likely built there with previous ffi. [23:00] oh [23:02] no, it built with libffi8ubuntu1 amd64 3.4~20200819gead65ca871-0ubuntu3 [23:05] mwhudson: ok, so rebuilt locally... and went well as well [23:05] with 3.4 as you say [23:22] Trevinho: ok [23:23] mwhudson: I've retriggered it and worked though https://autopkgtest.ubuntu.com/packages/gjs/groovy/amd64 [23:24] mwhudson: oh, no sorry... i misread the number I think [23:24] yeah i was going to say, the pass is the version from release [23:28] anyway sure something changed ffi.. as per "not ok 7 - Unicode encoding for symbols should be functioning properly for ARGV and imports." [23:29] mwhudson: installed tests have changed install location in this release, I'm not sure if this affected though [23:39] Trevinho: it passed with all-proposed=1 https://autopkgtest.ubuntu.com/packages/gjs/groovy/amd64 [23:39] \o/ [23:39] yeah [23:40] without all-proposed it means it uses only part of proposed or what? :o [23:40] only the package being tested [23:40] the idea is to test if the package will make release worse [23:40] so by default you test release + the package [23:42] britney has gotten a bit smarter about this recently, it's clear that gjs isn't even installable unless libffi migrates as well, so it tests gjs + libffi from proposed and everything else from release [23:42] clearly there is some other package version that gjs implicitly depends on and ideally we'd figure out what and add a versioned dependency i guess [23:42] but well [23:48] ah i see