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