| smoser | xnox: i wont' pretend to have remotely as good a handle on what systemd is capable of as you. And I am not really in the position to devote lots of time. | 00:05 |
|---|---|---|
| smoser | don't let this get out, but I do have a reasonable amount of trust that you'll do something sane. | 00:06 |
| arnatious | Anyone know why patches are left out of the state when a debdiff is generated? | 03:25 |
| arnatious | I have a package, python-flake8-3.7.9, and an SRU candidate, python-flake8-3.8.3~20.04.1, if I generate a debdiff between their dsc's and try and apply that to 3.7.9, it fails | 03:27 |
| arnatious | i.e.: debdiff xxx-3.7.9.dsc xxx-3.8.3.dsc > xxx.debdiff | 03:28 |
| arnatious | Then some files failing to patch when going into xxx-3.7.9.dsc and running patch -p1 < ../xxx.debdiff | 03:29 |
| eeos | Hi everybody! The new vlc snap on *ubuntu 20.04.1 LTS is pretty dangerous and can stall production machines .... | 08:00 |
| eeos | It seems to be related to apparmor | 08:00 |
| === pieq_ is now known as pieq | ||
| Laney | xnox: think all the livefs failures are for you | 08:24 |
| Laney | "please fail", "ok, I will fail, here you go *BOOM*" | 08:30 |
| === fabio__ is now known as fcole90 | ||
| xnox | Laney: har har har! | 09:35 |
| xnox | juliank: so grub-pc now fails to install during livefs build. I.e. https://launchpadlibrarian.net/496116283/buildlog_ubuntu_groovy_amd64_ubuntu_BUILDING.txt.gz and now I am confused. I thought installing grub-pc in a chroot should do nothing.... | 09:37 |
| juliank | xnox: Well, it runs if one of /boot/grub/{,<arch>/}core.img exists | 09:40 |
| juliank | xnox: It also runs if test -z "$2" | 09:42 |
| juliank | which confuses me | 09:42 |
| xnox | /boog/grub is empty | 09:44 |
| xnox | arm64 images all built fine, so whatever we do for efi is all good. | 09:49 |
| xnox | juliank: "test -z "$2"" feels bogus. | 09:50 |
| xnox | because for the first time, we started to catch errors and fail install. | 09:50 |
| xnox | and clearly installing grub-pc in a chroot, is bogus, and shouldn't attempt to grub-install things. | 09:50 |
| Laney | there's already a running_in_container, you could add a running_in_chroot too or something | 09:52 |
| xnox | or maybe I added one too many "exit 1" | 09:53 |
| xnox | cause i assert on "failed to install to a device" and "no devices to install to" | 09:53 |
| xnox | Laney: people often chroot into systems, to rescue them, though. | 09:54 |
| Laney | via like dpkg-reconfigure? | 09:55 |
| Laney | maybe they do | 09:55 |
| xnox | via both apt install or dpkg-reconfigure. For example, they purged grub-pc because they are silly. | 09:55 |
| xnox | and realized that oh wait, no this system does need bios to boot. | 09:55 |
| xnox | boot of usb stick, chroot, apt install grub-pc. | 09:55 |
| xnox | but then they would call grub-install | 09:55 |
| xnox | yeah, it's weird. how could you have booted, if you are installing grub-pc for the first time. | 09:56 |
| xnox | i shall check what the installers do | 09:59 |
| Laney | call time! | 10:00 |
| xnox | juliank: so both curtin & subiquity call grub-install explicitely. (and grub-installer did too). So for installers there is no need for grub-pc to attempt install. | 11:46 |
| xnox | i will drop the "$2" test. | 11:46 |
| juliank | xnox: that's correct, my understanding was that grub-* should only update systems, not do initial install | 11:46 |
| juliank | xnox: but I don't understand why this regressed _now_? | 11:47 |
| juliank | xnox: nothing changed there | 11:47 |
| xnox | juliank: i changed things! | 11:48 |
| xnox | juliank: i made postinst exit 1, instead of break && exit 0. | 11:49 |
| juliank | OK | 11:49 |
| xnox | juliank: when installing non-interactive | 11:49 |
| xnox | juliank: but i see that grub-multi-install has the same bugs! | 11:49 |
| xnox | i.e. break && exit 0, instead of exit 1 upon non-interactive upgrade with invalid devices. | 11:49 |
| juliank | xnox: It is a copy of postinst after all | 11:52 |
| juliank | :D | 11:52 |
| juliank | Also maybe we should add triggers on /etc/default/grub.d | 11:52 |
| juliank | re snippets other packages drop in there | 11:52 |
| juliank | but hard | 11:53 |
| juliank | next cycle we really need to work on reducing delta with debian | 11:53 |
| xnox | juliank: ok | 11:54 |
| ahasenack | good morning | 12:05 |
| rafaeldtinoco | ahasenack: o/ | 12:14 |
| rafaeldtinoco | morning all | 12:14 |
| smoser | xnox: was/is there a currently painful bug that motivates the multi-transactional boot discussion ? | 12:42 |
| Odd_Bloke | smoser: https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1870346 is one, and there's a similar issue with OVS via MAAS (though I can't find a bug for that right now). The high-level issue is that there are some netplan configurations which emit additional systemd units for correct operation, and because the systemd boot transaction has already started when it emits them as a result of being | 12:51 |
| ubottu | Launchpad bug 1870346 in cloud-init (Ubuntu) "Wifi configuration" [Medium,Triaged] | 12:51 |
| Odd_Bloke | called by cloud-init, they aren't run on first boot. | 12:51 |
| Odd_Bloke | This isn't a problem in "regular" netplan operation (quotation marks because I think netplan runs alongside cloud-init more often than not :p), because `netplan generate` expects to run at generator time. | 12:53 |
| slyon | The other bug is here: https://bugs.launchpad.net/cloud-init/+bug/1892851 | 12:54 |
| ubottu | Launchpad bug 1892851 in cloud-init "Staged boot, to fix integration of systemd generators" [Undecided,Confirmed] | 12:54 |
| smoser | Odd_Bloke: oh yeah.. the ligh-level made me remember why i called it a work around. | 12:57 |
| smoser | i honestly think there will be loads of workarounds for netplan until it stops being a layer of indirection and instead can take a config and make it happen directly. | 12:58 |
| xnox | Odd_Bloke: smoser: chatting with other people, some other cloud-init like things do everything in the initrd (i.e. talking to metadata source, customizing things) then first boot is configured and does everything. | 13:01 |
| xnox | fetching metadata at systemd-generator time, is a bit non-starter, especially if the rootfs is still RO at that point, and udevd is not running. | 13:02 |
| smoser | xnox: yeah... initrd is kind of the first "transaction" | 13:03 |
| xnox | i am now learning that inflight transactions get merged. So maybe it would be possible to call "netplan generate & daemon-reload & restart network.target" or like make netplan-generate do that. | 13:03 |
| xnox | cause when it runs as a systemd system-generator for real, effectively daemon-reload & start network.target is what happens next. | 13:03 |
| xnox | smoser: yes, indeed. | 13:04 |
| xnox | i need to experiment more with this, to like find bugs in systemd. | 13:04 |
| xnox | cause in the most common case, netplan generate usually doesn't create any service units, and that means we should be able to avoid daemon-reload / multiple transactions. | 13:05 |
| xnox | and maybe it could be smart enough to enque restart of network.target, if it realizes it is being called "just-in time", whilst systemctl is-system-running is "starting" | 13:05 |
| xnox | cc: Odd_Bloke slyon ^^^^ | 13:05 |
| === gusnan is now known as Guest91337 | ||
| xnox | lunch | 13:06 |
| Odd_Bloke | xnox: Can you point at a PR or whatever for "inflight transactions"? I don't really know what that means. | 13:12 |
| Odd_Bloke | mwhudson: FYI, subiquity-installed systems also end up with a /etc/cloud/ds-identify.cfg which forces cloud-init to be enabled on all boots; if I remove both that and the cloud.cfg.d/99-installer.cfg then cloud-init does not run. | 13:41 |
| xnox | Odd_Bloke: that was proposed by slyon before, can't remember if it was on netplan or cloud-init repos. And don't have time to find now. As i should be end of week already; but still need to test grub fixes. | 14:11 |
| rafaeldtinoco | ahasenack: about this statement "The content of /etc/update-motd.d/* really, really, really shouldn't be executed if the session in question is not interactive, as it provides no value at all. " | 14:12 |
| rafaeldtinoco | weren't you dealing with update-motd lately ? | 14:12 |
| rafaeldtinoco | im triaging wednesday queue and there is a new bug about it | 14:12 |
| rafaeldtinoco | saying that non interactive ssh (scp) sessions were causing a big load spike for this end-user "usage" (lots of servers uploading things from time to time using scp) | 14:13 |
| ahasenack | not related to that, no | 14:13 |
| ahasenack | ("dealing with update-motd") | 14:13 |
| rafaeldtinoco | ah ok | 14:13 |
| rafaeldtinoco | so its a new thing | 14:13 |
| ahasenack | yes | 14:13 |
| rafaeldtinoco | ok, let me triage it normally then | 14:14 |
| rafaeldtinoco | thanks | 14:14 |
| ahasenack | I know that landscape-sysinfo, one of the processes that were mentioned in the bug, the wrapper that launches it checks for load before doing so | 14:14 |
| ahasenack | it may be the only motd script that actually runs something on logon, all the others just cat files to stdout | 14:14 |
| ahasenack | files that were prepared by a cron job, or systemd timer, in advance | 14:14 |
| rafaeldtinoco | yep | 14:14 |
| Odd_Bloke | xnox: Ack, we can catch up next week; have a good weekend! | 14:24 |
| smoser | i'd really recommend not writing ds-identify.cfg *anywhere*. | 14:32 |
| smoser | from an upstream cloud-init perspective... its not something that we desire to support. from a downstream perspective, it should not be needed. | 14:32 |
| xnox | smoser: i also found that it's impossible to use cloud.cfg.d from /run, because cloud.cfg in /run is like exclusive to ds-identify itself and nothing else. | 14:53 |
| smoser | that surprises me. | 14:54 |
| xnox | maybe i should open a bug report then! =) | 15:07 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!