[09:36] <cpaelzer> utkarsh2102: doko has asked if you could look at https://launchpad.net/ubuntu/+source/ruby2.7/2.7.2-4ubuntu1 ?
[09:37]  * doko is on leave ...
[10:03] <utkarsh2102> cpaelzer: absolutely, the arm64 failure I suppose?
[10:24] <utkarsh2102> ah, that and also regression on s390x: https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ruby2.7
[10:27] <sil2100> cpaelzer: hey! I have been poked about a chrony ADT regression for s390x with the new dpkg - was wondering if maybe you or someone from the server team could take a look to see what could be happening there?
[10:45] <cpaelzer> sil2100: you are the second to ask, it seems to be LTO
[10:45] <cpaelzer> sil2100: and I'm already on it
[10:54] <sil2100> cpaelzer: excellent to hear!
[11:18] <cpaelzer> sil2100: this case is ugly, it tries to throw red herrings at me in every possible step *sigh*
[11:42] <cpaelzer> thanks for the bug filing sil2100
[11:42] <cpaelzer> you'll smile when you see al my updates that are incoming to that ... :-)
[11:54] <sil2100> cpaelzer: wow, thanks for the detailed investigation! ;)
[11:54] <sil2100> This is really a good read
[11:59] <cpaelzer> sil2100: if you could maybe have a look for silly mistakes on https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/400182 and ack it if ok ?
[11:59] <cpaelzer> I'll make cross arch build and cross arch test a requirement for uploading anyway - so consider that covered
[12:19] <utkarsh2102> doko: fwiw, this test in ruby-ferret is known to be problematic; we previously hit that on arm64 and it seems now on s390x but unfortunately, I can't seem to reproduce the failure (using canonistack VM); 7/7 passing, no failures :(
[12:20] <utkarsh2102> that said, c_paelzer has re-triggered the tests twice on my request. so let's see. (Ik you did already)
[12:33] <utkarsh2102> doko: passing both, yay! \o/
[12:44] <sil2100> cpaelzer: looking in a moment!
[13:45] <eoli3n_> is there a way to make sure that avahi-daemon can't run ? if i remove the package and hold it in my ansible playbook, it seems to come back as dep of another package. If i disable avahi-daemon.socket and avahi-daemon.service, reboot, it is still running...
[14:23] <rbasak> eoli3n_: https://askubuntu.com/a/816378/7808
[14:24] <rbasak> I think you want "mask" rather than "disable".
[14:25] <rbasak> You could also pin avahi-daemon to something negative in apt.
[14:25] <rbasak> But I would investigate why you need a package that depends on it first.
[15:05] <eoli3n_> thanks rbasak
[15:55] <eoli3n_> xnox i face this again : https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1882232
[15:56] <eoli3n_> with desktop iso live system, my ansible playbook hangs, then fail at the task of installing chromium-browser
[15:56] <eoli3n_> (just a sec for logs)
[15:57] <xnox> eoli3n_:  fun.
[15:57] <eoli3n_> not sure if i would use that word but... :)
[15:57] <xnox> eoli3n_:  where is your playbook running? cause i thought we fixed that, to detect that things are well not running.
[15:58] <eoli3n_> in a chroot
[15:58] <eoli3n_> i fixed that
[15:58] <eoli3n_> s/i/we
[15:58] <eoli3n_> s/we/you
[15:58] <eoli3n_> :)
[15:58] <xnox> eoli3n_:  however, since that was fixed, we did add preseeding support => so chroot has many snaps things prepopulated.
[15:58] <xnox> eoli3n_:  maybe open a new bug report? and say that this previous bug, has now regressed?
[15:59] <xnox> eoli3n_:  i can't remember what your desired end state was; and what was done to get there.
[15:59] <eoli3n_> i don't think that it has regressed
[15:59] <eoli3n_> because it is still working with kickstart
[15:59] <eoli3n_> and the netboot iso
[16:00] <eoli3n_> i just want to install chromium-browser with ansible in a chroot with a ubiquity late command
[16:00] <eoli3n_> success command*
[16:00] <xnox> and there is no way today to otherwise tell the installer "and please install these snaps"
[16:01] <xnox> cause in the future we'd need to grow that capability.
[16:01] <xnox> eoli3n_:  yeah, we did changes in focal, that may not result in that working anymore correctly..
[16:01] <xnox> let me open a new bug report about that.
[16:01] <eoli3n_> https://x0.at/BwI.txt
[16:01] <eoli3n_> but i don't get what difference between preseeding desktop main iso, and kickstarting netboot iso
[16:02] <xnox> lots
[16:02] <eoli3n_> oh ok
[16:02] <xnox> desktop already has some snaps in partially installed state
[16:02] <eoli3n_> but it should concern the package, and not the installer, doesn't it ?
[16:02] <xnox> where snapd is paused, at half-preseeded state.
[16:02] <eoli3n_> ok ok, you know better :)
[16:02] <xnox> with many snaps preinstalled.
[16:02] <xnox> the netboot.iso has no snaps.
[16:03] <xnox> opened https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1921405
[16:03] <eoli3n_> you can add the task log in the bug report if you want
[16:04] <eoli3n_> you're fast ! thanks again for your help
[16:38] <eoli3n_> shouldn't the installer create an efi entry in boot manager automatically ?
[17:11] <xnox> eoli3n_:  yes, no, maybe. it doesn't matter.
[17:11] <xnox> eoli3n_:  it can do it on first boot too.
[17:11] <xnox> eoli3n_:  also, who knows if your firmware honors it.
[17:11] <xnox> if you force it to always netboot, it may ignore BootNext / BootOrder.
[17:16] <eoli3n_> at the first boot, i get my firmware configuration screen, if i select my hard drive, then it "creates ubuntu entry" but it doesnt use grubx64.efi
[17:28] <xnox> why should it use grubx64.efi ?! =)
[17:28] <xnox> eoli3n:  also sounds like your firmware is buggy, if you want to select a hard drive => if you are in OVMF qemu KVM, did you set bootoder on your drives / network card?
[17:29] <xnox> we never boot with grub directly.
[17:29] <eoli3n_> the firmware is ipxe used by qemu as main one
[17:30] <eoli3n_> " if you are in OVMF qemu KVM, did you set bootoder on your drives / network card?" in the firmware ?
[17:30] <eoli3n_> nop
[17:31] <eoli3n_> problem is that i configured netplan to use networkd for "eth0" and i configured my cmdline in /etc/default/grub
[17:31] <eoli3n_> to use old dev names
[17:32] <eoli3n_> "18:29 xnox: we never boot with grub directly." I don't understand what you mean
[17:32] <eoli3n_> the firmware chainloads grub, then grub loads kernel and initramfs
[17:38] <xnox> false
[17:38] <xnox> firmware should chainload shim, which chainloads grub.
[17:38] <xnox> and shim can choose if it will boot fwupdate, fb, mm, or grub.
[17:39] <xnox> or even reset again.
[17:39] <xnox> eoli3n_:  if you configured things right, there shouln't be a problem. If there is a problem, maybe some of the config is missing.
[17:40] <xnox> eoli3n_:  and i would recommend you to _not_ force eth0 names. Becuase netplan & networked can match on all ethernet device irrespective of how they are named. And it is best to use stable names, rather than eth0.
[17:40] <xnox> eth0 breaks a lot.
[17:41] <eoli3n_> stable names on a host is not a stable name on 800 hosts
[17:42] <eoli3n_> but why not drop this and configure netplan without hard configure a net card
[17:44] <xnox> eoli3n:  that's the point. 800 hosts should have 800 different ethernet names, and that should be ok.
[17:44] <xnox> eoli3n_:  hi?
[17:44] <xnox> there are two of you and you had a netsplit?
[17:44] <xnox> eoli3n:  that's the point. 800 hosts should have 800 different ethernet names, and that should be ok.
[17:45] <xnox> for example, what's your kernel commandline? and did you specify your cmdline changes are `---` such that it gets copied into target too?
[17:46] <eoli3n_> xnox something strange happened here :)
[17:47] <eoli3n_> BOOT_IMAGE=/boot/vmlinuz-5.4.0-67-generic root=UUID=cfd0c620-61ab-4887-977c-5138febf933e ro net.ifnames=0 biosdevname=0 ipv6.disable=1 quiet splash
[17:47] <xnox> there are rolling restarts of freenode at the moment.
[17:48] <xnox> eoli3n_:  is that how you boot the installer, or how you boot the installed system?
[17:48] <xnox> eoli3n_:  looks ok.
[17:48] <eoli3n_> ah no
[17:48] <eoli3n_> that's how i boot my hosts
[17:48] <xnox> eoli3n_:  how do you boot the installer?
[17:48] <eoli3n_> on the first boot
[17:48] <eoli3n_> without this
[17:49] <eoli3n_> the unmatch is problematic i guess
[17:49] <xnox> without what?
[17:49] <eoli3n_> net.ifnames=0 biosdevname=0
[17:50] <eoli3n_> here my installer cmdline : imgargs vmlinuz initrd=initrd rootfstype=nfs netboot=nfs nfsroot=162.38.151.26:/exports/focal-desktop boot=casper ip=dhcp fsck.mode=skip automatic-ubiquity debian-installer/language=fr console-setup/layoutcode=fr console-setup/variantcode=oss url=http://162.38.151.26/preseed/fds/focal-efi.seed quiet
[17:50] <xnox> i expect you to boot the installer as " linux /boot/vmlinuz-xyz ip=dhcp <anything installer related> --- net.ifnames=0 biosdevname=0 ipv6.disable=1 quiet splash
[17:50] <xnox> "
[17:50] <eoli3n_> ah ok, but i don't get what it does
[17:50] <xnox> because then things after "---" will not only be active during the installation, but will also be copied into target's installed system.
[17:50] <eoli3n_> ok ! good to know
[17:50] <xnox> such that you don't need to manually configure custom kernel cmdline.
[17:51] <eoli3n_> where will it be written ?
[17:51] <eoli3n_> on the target ?
[17:51] <xnox> cause it's like "my systems need these kernel args and copy them into target too"
[17:51] <xnox> eoli3n_:  i think it like modifies /etc/defaut/grub* something
[17:51] <eoli3n_> that's what ansible does
[17:51] <eoli3n_> for me
[17:51] <eoli3n_> that's the strange part
[17:52] <eoli3n_> when i first boot the hard drive in qemu/kvm, then it "creates ubuntu entry" but i runs with shim file
[17:52] <eoli3n_> s/i/it
[17:52] <eoli3n_> so grub cannot append cmdline
[17:52] <eoli3n_> or i misunderstand something