smoserxnox: 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
smoserdon't let this get out, but I do have a reasonable amount of trust that you'll do something sane.00:06
arnatiousAnyone know why patches are left out of the state when a debdiff is generated?03:25
arnatiousI 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 fails03:27
arnatiousi.e.:  debdiff xxx-3.7.9.dsc xxx-3.8.3.dsc > xxx.debdiff03:28
arnatiousThen some files failing to patch when going into xxx-3.7.9.dsc and running patch -p1 < ../xxx.debdiff03:29
eeosHi everybody! The new vlc snap on *ubuntu 20.04.1 LTS is pretty dangerous and can stall production machines ....08:00
eeosIt seems to be related to apparmor08:00
=== pieq_ is now known as pieq
Laneyxnox: think all the livefs failures are for you08:24
Laney"please fail", "ok, I will fail, here you go *BOOM*"08:30
=== fabio__ is now known as fcole90
xnoxLaney:  har har har!09:35
xnoxjuliank:  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
juliankxnox: Well, it runs if one of /boot/grub/{,<arch>/}core.img exists09:40
juliankxnox: It also runs if test -z "$2"09:42
juliankwhich confuses me09:42
xnox/boog/grub is empty09:44
xnoxarm64 images all built fine, so whatever we do for efi is all good.09:49
xnoxjuliank:  "test -z "$2"" feels bogus.09:50
xnoxbecause for the first time, we started to catch errors and fail install.09:50
xnoxand clearly installing grub-pc in a chroot, is bogus, and shouldn't attempt to grub-install things.09:50
Laneythere's already a running_in_container, you could add a running_in_chroot too or something09:52
xnoxor maybe I added one too many "exit 1"09:53
xnoxcause i assert on "failed to install to a device" and "no devices to install to"09:53
xnoxLaney:  people often chroot into systems, to rescue them, though.09:54
Laneyvia like dpkg-reconfigure?09:55
Laneymaybe they do09:55
xnoxvia both apt install or dpkg-reconfigure. For example, they purged grub-pc because they are silly.09:55
xnoxand realized that oh wait, no this system does need bios to boot.09:55
xnoxboot of usb stick, chroot, apt install grub-pc.09:55
xnoxbut then they would call grub-install09:55
xnoxyeah, it's weird. how could you have booted, if you are installing grub-pc for the first time.09:56
xnoxi shall check what the installers do09:59
Laneycall time!10:00
xnoxjuliank:  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
xnoxi will drop the "$2" test.11:46
juliankxnox: that's correct, my understanding was that grub-* should only update systems, not do initial install11:46
juliankxnox: but I don't understand why this regressed _now_?11:47
juliankxnox: nothing changed there11:47
xnoxjuliank:  i changed things!11:48
xnoxjuliank:  i made postinst exit 1, instead of break && exit 0.11:49
xnoxjuliank:  when installing non-interactive11:49
xnoxjuliank:  but i see that grub-multi-install has the same bugs!11:49
xnoxi.e. break && exit 0, instead of exit 1 upon non-interactive upgrade with invalid devices.11:49
juliankxnox: It is a copy of postinst after all11:52
juliankAlso maybe we should add triggers on /etc/default/grub.d11:52
juliankre snippets other packages drop in there11:52
juliankbut hard11:53
julianknext cycle we really need to work on reducing delta with debian11:53
xnoxjuliank:  ok11:54
ahasenackgood morning12:05
rafaeldtinocoahasenack: o/12:14
rafaeldtinocomorning all12:14
smoserxnox: was/is there a currently painful bug that motivates the multi-transactional boot discussion ?12:42
Odd_Blokesmoser: 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 being12:51
ubottuLaunchpad bug 1870346 in cloud-init (Ubuntu) "Wifi configuration" [Medium,Triaged]12:51
Odd_Blokecalled by cloud-init, they aren't run on first boot.12:51
Odd_BlokeThis 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
slyonThe other bug is here: https://bugs.launchpad.net/cloud-init/+bug/189285112:54
ubottuLaunchpad bug 1892851 in cloud-init "Staged boot, to fix integration of systemd generators" [Undecided,Confirmed]12:54
smoserOdd_Bloke: oh  yeah.. the ligh-level made me remember why i called it a work around.12:57
smoseri 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
xnoxOdd_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
xnoxfetching 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
smoserxnox: yeah... initrd is kind of the first "transaction"13:03
xnoxi 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
xnoxcause when it runs as a systemd system-generator for real, effectively daemon-reload & start network.target is what happens next.13:03
xnoxsmoser:  yes, indeed.13:04
xnoxi need to experiment more with this, to like find bugs in systemd.13:04
xnoxcause 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
xnoxand 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
xnoxcc: Odd_Bloke slyon ^^^^13:05
=== gusnan is now known as Guest91337
Odd_Blokexnox: Can you point at a PR or whatever for "inflight transactions"?  I don't really know what that means.13:12
Odd_Blokemwhudson: 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
xnoxOdd_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
rafaeldtinocoahasenack: 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
rafaeldtinocoweren't you dealing with update-motd lately ?14:12
rafaeldtinocoim triaging wednesday queue and there is a new bug about it14:12
rafaeldtinocosaying 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
ahasenacknot related to that, no14:13
ahasenack("dealing with update-motd")14:13
rafaeldtinocoah ok14:13
rafaeldtinocoso its a new thing14:13
rafaeldtinocook, let me triage it normally then14:14
ahasenackI know that landscape-sysinfo, one of the processes that were mentioned in the bug, the wrapper that launches it checks for load before doing so14:14
ahasenackit may be the only motd script that actually runs something on logon, all the others just cat files to stdout14:14
ahasenackfiles that were prepared by a cron job, or systemd timer, in advance14:14
Odd_Blokexnox: Ack, we can catch up next week; have a good weekend!14:24
smoseri'd really recommend not writing ds-identify.cfg *anywhere*.14:32
smoserfrom an upstream cloud-init perspective... its not something that we desire to support.  from a downstream perspective, it should not be needed.14:32
xnoxsmoser:  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
smoserthat surprises me.14:54
xnoxmaybe i should open a bug report then! =)15:07

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!