| rbasak | Could someone please explain https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-8.0? | 11:06 |
|---|---|---|
| rbasak | eg. libmysqlclient-dev/amd64 unsatisfiable Depends: libmysqlclient21 (= 8.0.16-0ubuntu1) | 11:06 |
| rbasak | But that's produced by the same source package, and does seem to be installable in combined release+proposed at least | 11:06 |
| rbasak | The binaries were accepted yesterday | 11:09 |
| rbasak | pitti: http://people.canonical.com/~pitti/scripts/britney-indexes as linked from https://wiki.ubuntu.com/ProposedMigration/LocalSetup no longer exists. Any chance of a copy? Does anyone else have it, please? | 11:46 |
| rbasak | Or I will try and reverse engineer what it does :-/ | 11:46 |
| rbasak | Oh. Could it be a component mismatch? | 12:08 |
| rbasak | o mysql-8.0: libmysqlclient21 mysql-client-8.0 mysql-client-core-8.0 mysql-server-8.0 mysql-server-core-8.0 | 12:08 |
| rbasak | [Reverse-Depends: libmysqlclient-dev (MAIN), mysql-client-8.0, mysql-server (MAIN), mysql-server-8.0] | 12:08 |
| rbasak | Aha | 12:08 |
| rbasak | We already seed mysql-server, which is created by src:mysql-8.0 now (taking over from src:mysql-5.7), which depends on mysql-server-8.0, which is in universe. | 12:12 |
| rbasak | So that (and perhaps some other binaries) need overriding over by an AA I think. | 12:12 |
| pitti | rbasak: Robert did an improved version of that in https://git.launchpad.net/bileto/tree/britney/fetch-indexes | 12:19 |
| pitti | althuogh it seems this wasn't updated in a while | 12:20 |
| rbasak | pitti: well it's better than a 404, so I'll update the wiki. Thanks! | 12:20 |
| rbasak | Could an AA please move src:mysql-8.0 in eoan-proposed to main, and the following binaries that are renamed from 5.7? libmysqlclient21 mysql-client-8.0 mysql-client-core-8.0 mysql-server-8.0 mysql-server-core-8.0 | 12:22 |
| rbasak | apw or sil2100: around please? ^ | 12:22 |
| apw | rbasak, looking | 12:34 |
| rbasak | apw: any joy please? Or did you get interrupted? | 13:17 |
| apw | rbasak, i've asked for the change, but hte publisher was down until about T-10m because the librarian was in a heap | 13:22 |
| apw | and as a result it has a large backlog | 13:22 |
| rbasak | Ah. Thanks! | 13:25 |
| === didrocks999 is now known as didrocks | ||
| rbasak | apw: it worked now. Thanks! | 14:09 |
| rbalint | santa_, ddstreet : i placed the systemd 242 merge in ppa:rbalint/scratch3 but autpkgtest infra did not like me and now i'm testing that locally | 14:40 |
| rbalint | sil2100, ^ | 14:40 |
| rbalint | eoan boots to desktop with it but i'm waiting for a full qemu run before i upload | 14:41 |
| rbasak | Skuggen: results are coming in for autopkgtest failures now: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#mysql-8.0 | 14:41 |
| rbasak | Skuggen: we need to get these fixed first | 14:41 |
| rbasak | (though we can upload FTBFS fixes that we know are required, too) | 14:42 |
| rbasak | They should build against libmysqlclient21 now and thus the transition will begin. | 14:42 |
| rbasak | Skuggen: I'll look at cacti first. Looks straightforward. | 14:43 |
| sil2100 | rbalint: thanks o/ | 14:43 |
| rbasak | I'll stick debdiffs in the same repo we were using for review. | 14:43 |
| === M_hc[m] is now known as _hc | ||
| Skuggen | rbasak: Yeah, I'll get the 8.0 build tests fixed | 15:04 |
| rbasak | Skuggen: thanks | 15:05 |
| rbasak | The cacti failure is actually a dbconfig failure | 15:05 |
| rbasak | That dep8 isn't triggered directly but I suspect it also fails | 15:05 |
| Skuggen | The MySQL failure is a bit odd. Thought maybe it was just a missing symlink for the test client binaries, but we don't seem to build the binary it complains about at all | 15:10 |
| Skuggen | dbconfig failure seems to be that 8.0 no longer allows adding "IDENTIFIED BY" clause to a GRANT statement | 15:12 |
| rbasak | Yes | 15:12 |
| rbasak | The question is how to change it exactly | 15:13 |
| rbasak | I think the code ensures that the user always exists first | 15:13 |
| rbasak | So I think I can insert an "ALTER USER x IDENTIFIED BY" before it (not checked for syntax) | 15:13 |
| rbasak | I'm hoping the existing tests will check my fix though. Still running them, but I think I saw the right kinds of failrues scroll by. | 15:14 |
| Skuggen | Oh, about the MySQL failure: we build with --list-missing. I was expecting it to fail if there were unhandled binaries :) | 15:15 |
| Skuggen | There was a similar issue in ruby-mysql, but there the fix was just to remove the clause | 15:16 |
| rbasak | There is also --fail-missing | 15:20 |
| Skuggen | Yeah, we use that upstream. We'd need to do some cleanup for it. There are some extra docs files we don't include, and also router | 15:29 |
| juliank | vorlon: Do you happen to know why we have wait-for-root? this is significantly delaying the boot because it's sitting around for 30s and only then we enter Debian's loop which executes local-block which in turn runs lvchange and hence is able to discover the new lvm volumes after unlocking a crypt partition | 15:31 |
| juliank | xnox: ^ | 15:31 |
| juliank | If I add a local_block "${dev_id}" call before we run wait-for-root stuff works fine | 15:32 |
| Skuggen | rbasak: I've added the missing files (except router and redundant docs files). Will test locally, then make a merge request in salsa | 15:32 |
| vorlon | juliank: "why we have it" is because it worked when it was added and solved problems. AFAIK Debian still doesn't use udev in the initramfs so the boot process is different between Debian and Ubuntu | 15:35 |
| vorlon | # in ubuntu, we should never actually enter this loop as wait-for-root | 15:37 |
| vorlon | # above should waited until the device appeared. | 15:38 |
| vorlon | juliank: so the device should've appeared before | 15:38 |
| juliank | vorlon: No, there's some udev involved somehow. But now it's definitely not running lvm2 after I'm unlocking the cryptroot before we run wait-for-root | 15:38 |
| juliank | The root device appears if I run local_block before wait-for-root, as that runs lvm2's lvchange which creates the root device | 15:38 |
| juliank | This used to work in disco I think but it somehow got broken | 15:38 |
| juliank | What happens is that we run lvm2 (via local-top) -> cryptroot - ... -> wait-for-root -...-> lvm2 (via local-block) | 15:39 |
| rbasak | Skuggen: great. Thanks! | 15:40 |
| juliank | I gotta setup two encrypted VMs with disco and eoan and see what the difference in the boot is | 15:41 |
| xnox | juliank: i think we want to drop wait-for-root and switch to settle / local-block loop thing | 16:47 |
| juliank | +1 | 16:47 |
| vorlon | xnox, juliank: I am uncomfortable with having to reintroduce any sort of loops in the shell code when this should all be driven by udev rules | 17:13 |
| vorlon | I'd like to understand why this stopped working | 17:14 |
| juliank | vorlon: I'd like to understand it too, but I don't see any difference in the initramfs debug trace | 17:15 |
| juliank | vorlon: Maybe the appearance of the crypt mapping should cause lvm2 to be running via udev and it's not? | 17:15 |
| juliank | where the crypt mapping is an LVM2 PV | 17:16 |
| vorlon | yes, that's what should happen | 17:16 |
| juliank | so maybe lvm2 | 17:16 |
| vorlon | yes | 17:16 |
| juliank | 's udev rules broke somewhere | 17:16 |
| juliank | vorlon: So, in eoan, the udev rule that runs pvscan moved to use pvscan@.service | 17:21 |
| juliank | I think | 17:21 |
| juliank | hmm | 17:22 |
| xnox | vorlon: loop in shell code, in initrd is new(ish) to support udev-based arbitrary stacking of raid/lvm/crypto | 17:32 |
| juliank | xnox: I think the argument is that udev should be handling the stacking itself, by running codes from RUN as needed | 17:32 |
| xnox | vorlon: the old loop, had static stacking. | 17:32 |
| xnox | juliank: but it can't for unlock. | 17:32 |
| vorlon | for unlock true, but per juliank's description, that's not where it's sticking | 17:32 |
| juliank | xnox: once you unlocked, an LVM PV appears, and the udev rule should RUN pvscan to scan it | 17:33 |
| juliank | ah but yes | 17:33 |
| xnox | juliank: we could do unlock from udev too.... if we add systemd with systemd-cryptsetup and tty-ask | 17:33 |
| juliank | if you have cryptroot nested inside cryptroot too? | 17:33 |
| xnox | yes | 17:34 |
| juliank | So, I reverted the eoan machine to disco's lvm2 69*rule, but it did not help | 17:34 |
| juliank | and debugging udev hook stuff inside initramfs | 17:35 |
| juliank | sounds hard | 17:35 |
| juliank | The Debian approach is certainly more flexible | 17:35 |
| vorlon | historically, Debian's approach has been much slower. If that's fixed, we can look at reconverging | 17:36 |
| juliank | xnox: We might just need a systemd in the initramfs that has one init.service that executes the initramfs-tools init script | 17:36 |
| juliank | The problem I tihnk I see is that udev rules want to start systemd services now, and we don't have systemd in the initramfs, hence the udev rules don't work | 17:37 |
| juliank | I might be hitting a different issue but not sure | 17:39 |
| vorlon | does that imply Debian's udev rules are now also incompatible with non-systemd init? | 17:41 |
| vorlon | I would think that's a bigger issue for them than us | 17:41 |
| juliank | I'm not sure | 17:41 |
| juliank | so, the lvm2 rules pass --disable-udev-systemd-background-jobs but only for the udeb | 17:41 |
| vorlon | in debian/rules you mean | 17:42 |
| vorlon | cute | 17:42 |
| juliank | and 69-lvm-metad.rules executes stuff like this: | 17:42 |
| juliank | ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm pvscan --cache $major:$minor", GOTO="lvm_end" | 17:42 |
| juliank | so without systemd-run I'd expect lvm to be broken | 17:42 |
| juliank | and init papers over that | 17:42 |
| juliank | because local-block and local-top run lvchange in a loop until the root device is found | 17:42 |
| juliank | vorlon: But if that's the problem, we do want to have that stuff on the host, but we can't have it in initramfs | 17:44 |
| vorlon | juliank: I don't see any reason to need to background this via systemd-run. A pvscan of a single PV should be trivially quick | 17:46 |
| vorlon | i.e. it looks to me to be appropriate to --disable-udev-systemd-background-jobs for both host and initramfs | 17:46 |
| vorlon | alternatively we could mock /bin/systemd-run in the initramfs, avoiding the need to mangle udev rules | 17:47 |
| vorlon | cat > /bin/systemd-run | 17:47 |
| vorlon | #!/bin/sh | 17:47 |
| vorlon | exec "$@" | 17:47 |
| juliank | vorlon: there's also a pvscan@.service | 17:49 |
| juliank | rebuilt lvm2 with that --disable option, going to see what happens | 17:51 |
| juliank | currently it's weirdly stuck | 17:51 |
| juliank | So that seems to fix it | 17:52 |
| juliank | Now testing on the host rather than the VM | 17:53 |
| juliank | So yeah, we want that version in the initramfs, but we'd want the other on the host | 17:56 |
| juliank | Laney just poited out that the systemd version also runs on change, whereas the direct pvscan one only runs on add | 17:56 |
| vorlon | again, I think this systemd indirection is spurious. I can't imagine how a pvscan of a single block device would ever hit a systemd timeout | 17:57 |
| juliank | vorlon: I think upstream must have had a good reason for adding this | 17:59 |
| juliank | vorlon: https://github.com/lvmteam/lvm2/commit/546db1c4be55d47d41082a345e15a35055223154#diff-b9ff0cca0b0701fbf51064e3459fa592 | 18:00 |
| juliank | vorlon: In any case, we build the rule in both variants anyway (for deb and udeb), so we can just copy the udeb one to the initramfs | 18:01 |
| vorlon | juliank: ok if the udev rule is forking and spawning lvmetad, that would be long-running. I think it's still an upside-down way to implement it | 18:01 |
| juliank | Isn't lvmetad gone these days? | 18:02 |
| vorlon | *I* don't use lvmetad | 18:02 |
| juliank | " Remove lvmetad" | 18:02 |
| juliank | in 2.03 | 18:02 |
| vorlon | but it's part of the rationale in that commit | 18:02 |
| vorlon | heh | 18:02 |
| vorlon | so maybe the rationale for supporting long-running processes from the udev rules is itself obsolete | 18:03 |
| juliank | 2.03 removed a lot of daemons | 18:03 |
| juliank | vorlon: I'm just going to report a bug in Debian now that it won't work on alternate inits :D | 18:03 |
| vorlon | anyway, I still think it's cleaner to mock systemd-run in the initramfs than to copy the udeb version of the rules | 18:03 |
| * vorlon nods | 18:04 | |
| juliank | debian bug 933011 | 18:11 |
| ubottu | Debian bug 933011 in lvm2 "lvm2: udev rules don't work outside of systemd" [Important,Open] http://bugs.debian.org/933011 | 18:11 |
| juliank | vorlon: So instead of hardcoding either solution. I'm changing the script so it uses systemd on systemd systems and direct execution otherwise | 18:27 |
| juliank | So ACTION!="add", GOTO="lvm_end" in classic mode, and ACTION!="add|change", GOTO="lvm_end" in systemd mode now become | 18:27 |
| juliank | TEST!="/run/systemd/system", ACTION!="add", GOTO="lvm_end" | 18:27 |
| juliank | TEST=="/run/systemd/system", ACTION!="add|change", GOTO="lvm_end" | 18:27 |
| vorlon | juliank: you overachiever | 18:27 |
| vorlon | wfm | 18:27 |
| juliank | Laney found out about the TEST== rule | 18:28 |
| Laney | Ⓒ ™ ⓡ | 18:33 |
| juliank | lvm2 uploaded | 19:12 |
| juliank | patch forwarded to Debian, upstream | 19:13 |
| juliank | We should probably consider changing installers to setup thinpool when doing lvm, so that people can benefit from thinpool snapshots and stuff | 20:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!