[08:22] Hi [08:23] https://bugs.launchpad.net/subiquity/+bug/1905296 [08:23] Launchpad bug 1905296 in subiquity "autoinstall crash with python3[1872]: segfault" [Undecided,New] [08:23] i'm on it [08:27] mwhudson is there a way to stop for subiquity to loop on errors ? [08:27] sometimes it loops, sometimes not [08:28] eoli3n: i don't really understand, sorry [08:28] to be able to test correctly, i need subiquity to attempt only one run [08:28] mwhudson when subiquity crash, it restart itself [08:28] in a endless loop [08:28] oh right yes [08:28] well it shouldn't for a non-interactive install [08:29] maybe i need to open a bug for this too [08:29] ? [08:31] CTRL+C doesnt work [08:31] it works, but it restarts anyway [08:32] hmm yes a bug would be good [08:32] eoli3n: which version are you using? [08:33] ok, if i chroot when install is goiing on it fails to restart installer with "/target is in use" [08:33] mwhudson https://github.com/eoli3n/vagrant-pxe/blob/dev/roles/ubuntu/tasks/main.yml#L4 [08:33] thanks [08:33] forget the chroot way, it's not ok [08:35] so yes it really shouldn't be crashing for a non-interactive install, it should stop and wait [08:35] if you can get logs for when it's crashing that would be great [08:35] but it doesn't :/ [08:36] mwhudson -> https://bugs.launchpad.net/subiquity/+bug/1905296 [08:36] Launchpad bug 1905296 in subiquity "autoinstall crash with python3[1872]: segfault" [Undecided,New] [08:36] first file [08:36] is that what you want ? [08:36] yesterday, i took a screenshot, just before it loops [08:36] wait a min [08:36] no [08:37] because that file is written by the installer before it exits/waits/whatever [08:37] mwhudson written where ? [08:38] what's the path of that file [08:38] eoli3n: i mean, i want to know what is written to the console as the process crashes [08:39] eoli3n: are you running this on tty1 or over serial? [08:39] ok that's what i'm searching [08:39] tty1 [08:39] that one : https://x0.at/5eL.png [08:40] on the topic of the other bug, can you try "chroot /target apt -o Debug::Acquire::file=true update" [08:40] just after that, terminal clears itself i can see tty1 prompt then it restart [08:40] not sure it will be useful, but worth a try perhaps [08:40] mwhudson anyway, unless i can stop the loop, i can't test anything [08:40] hmm that's not quite enough [08:40] as /target is clear at each iteration [08:40] yes [08:41] sometimes, when python crash, it stops then i can test, [08:41] i guess you could kill -STOP it while the crash report is being generated or something? [08:41] but i want to be able to reproduce that behaviour [08:41] from tty2 [08:41] mwhudson the screenshot state is 0,5s [08:41] maybe less [08:42] alternatively if you can run on serial it might be easier to capture the output [08:42] eoli3n: is this a VM or bare metal? [08:42] both [08:43] i use kvm [08:43] i don't get what you ask [08:43] eoli3n: do you have error commands in your autoinstall config? [08:43] kvm is an type1 hypervisor so both [08:43] wait no i've seen your config, it doesn't [08:43] yes [08:43] yes i don't [08:43] ^^ [08:43] what should i add [08:43] eoli3n: right but KVM vs an actual server in a rack [08:44] mwhudson: yesterday we did test with Debug::Acquire::cdrom=true but it didn't reveal much more [08:44] i'm just looking at the code trying to understand why it could be misbehaving [08:44] hm for me no differences, but yes qemu/kvm on my host [08:44] TJ-: it's not using the cdrom method though, the sources.list has file:/// urls in it [08:45] mwhudson you can fully reproduce if you want to : https://github.com/eoli3n/vagrant-pxe/tree/dev [08:45] mwhudson: did it? I thought we saw cdrom! ... shows how tired I was then [08:45] mwhudson: that'd explain why there wasn't more info :D [08:46] TJ-: it is a bit confusing [08:46] mwhudson: yeah, what gets me is, it successfully reads Release{,.gpg} but then fails on Packages.gz ! [08:46] mwhudson lets focus just a min on the loop thing, because without workaround this, i can't test anything [08:46] wait the title of the bug report is python segfaulting [08:47] oh no loop at this run: i'm ready to test [08:47] that would explain some things [08:47] it seems that just opening tty breaks the loop [08:47] although why it would segfault i have no idea [08:48] that's the first problem of that issue, that error needs to be catch [08:48] by python [08:48] whatever is going on [08:49] eoli3n: so what commands do i type to reproduce this? [08:49] that's what i get stuck on when it crash : https://github.com/eoli3n/vagrant-pxe/tree/dev [08:49] (i don't use vagrant) [08:49] mwhudson with my env ? follow the readme [08:49] you can't if you don't [08:49] do you use libvirt on your host ? [08:49] well i mean i've never used vagrant [08:49] mwhudson: I had a running theory yesterday this could be due to the fork into a separate PID namespace, but couldn't put my finger on anything. eoli3n did test using 'unshare' manually - eoli3n can you recall if when we tried 'unshare' that apt-get update failed or succeeded ? [08:50] mwhudson you use libvirt/qemu/kvm on ubuntu right ? [08:50] i use libvirt or just kvm on the command line [08:50] so install qemu and vagrant packages [08:50] then vagrant install the plugin [08:50] then nothing to do [08:50] just vagrant up [08:50] open virt-manager [08:51] you will see server ploping [08:51] then vagrant up client, to create a pxe client [08:51] just follow the readme [08:51] its as simple as it is, i will help if something goes wrong [08:51] but nothing should [08:52] it's downloading a debian10 image now, is that right? [08:52] yes it does [08:52] ok [08:52] thats the box for the server [08:52] ah i see [08:52] pxe server runs on debian 10 [08:52] anyway it's nearly 10pm here so i'll have to drop soon [08:52] but if i can reproduce i'll have a look [08:53] did you install ovmf too ? [08:53] lets finish the vagrant env, that will be useful for you, if you want [08:53] you need ovmf package to be able to run client in EFI mode [08:54] i have that already yes [08:54] then confirm me that the file : /usr/share/qemu/OVMF.fd [08:54] exists [08:54] does it ? [08:54] yes [08:54] ok [08:54] wait for the server's ansible to finish [08:54] then "vagrant up client" [08:55] ok [08:55] biab [08:55] you will be able to connect to server with "vagrant connect ssh" then "sudo -i" [08:55] oups [08:55] vagrant ssh server [08:56] one thing we will need to ensure is that you client VM use same IF name than me [08:56] (open virt-manager) [08:56] if not, i will force IF names [08:58] eoli3n: launching here as well [09:00] please open VM in virt-manager then go to tty2 with menu [09:00] i don't know the name of the menu in english [09:01] but at the top of VM you should be able to send CTRL+ALT+2 [09:01] then sudo ip a, and please give me IF names, just to be sure [09:01] eoli3n: on client it starts at tty1 asking for a login [09:01] no subiquity launch ? [09:02] that not client, that's your server i think [09:02] eoli3n: no [09:02] eoli3n: client [09:02] ok [09:02] did you see PXE booting ? [09:02] you do, if not, no system [09:03] waveform, hey, did you see the regression comment on bug #1903048 ? [09:03] bug 1903048 in bluez (Ubuntu Hirsute) "[SRU] Bluetooth won't activate on the pi 400" [High,Triaged] https://launchpad.net/bugs/1903048 [09:03] sil2100, ^ [09:03] reboot your client and describe a bit what steps you see ? [09:03] it should be nothing [09:03] eoli3n: yes, in the launch shell on the host, currently at "==> pxe_client: Waiting for domain to get an IP address..." [09:03] that's normal [09:04] ah no its not [09:04] eoli3n: I've checked both server and client guests are on the pxe_network [09:04] eoli3n: we should move to #ubuntu-server to avoid cluttering -devel with this debug chatter [09:04] TJ- vagrant destroy client [09:04] then vagrant up client just to be sure [09:05] mwhudson is not on #ubuntu-server [09:05] bah i am now [09:05] hey TJ- [09:05] you're not on the dev branch ! [09:05] git checkout dev [09:05] mwhudson too [09:06] vagrant destroy -f && git checkout dev && vagrant up [09:06] eoli3n: Heya, it seems you missed the part about -o Debug::PkgAcquire::Worker=1; although I'm not sure why there's no cdrom debug output :/ [09:07] eoli3n: Oh, you do not actually use the cdrom method [09:07] you use file: [09:07] i don't use anything, the installer does [09:07] well you use the installer :D [09:07] I'm not sure if debug::acquire::file would add anything [09:08] i don't see debugging comments in there [09:09] Oh I see you guys moved to #-server [09:32] seb128: looking! === sem2peie- is now known as sem2peie [10:12] doko: apt is blocked by gcc-snapshot E: Unable to locate package gdc-11 [10:12] (i'm looking at you sicherboot, i will try this on archlinux) [10:13] not sure i can, because i use zfs and bootenv managed by zectl (https://github.com/johnramsden/zectl) [10:13] juliank: thanks, will fix it later === sem2peie- is now known as sem2peie [10:20] rbalint: There are a lot of kodi addons in release pocket that build-depend on kodi-addons-dev, which is not in the archive, as can be seen in https://magenta.jak-linux.org/ubuntu-archive/distcheck/hirsute/release.txt [10:20] rbalint: What should we do about those? [10:20] Should I request removal? [10:30] was kodi-addons-dev removed? did it exist before? [10:31] doko: kodi itself was removed from hirsute [10:31] doko: So yeah, remove all kodi-* and kodiplatform [10:31] removed from Debian testing, depends on removed python-pil; Debian bug #936805 [10:31] Debian bug 936805 in src:kodi "kodi: Python2 removal in sid/bullseye" [Serious,Fixed] http://bugs.debian.org/936805 [10:32] yep, then remove it as well [10:32] OR: demote to proposed so they can migrate again when new kodi enters [10:49] juliank: eoli3n's issue was wrong file-system permissions on the server-side NFS export; only UID was allowed, and in the PXE client we believe apt-get was dropping to _apt user. In any event, the fix on server-side was to simply apply go+x to directories and go+r to files in the exported unpacked ISO installer file-system === guiverc2 is now known as guiverc [11:43] doko, juliank i'd have kept python-pil until the new kodi upstream release is out [11:51] since kodi 19 beta is already out most likely we can have all the packages back soon [11:58] rbalint: yeah, that's why I think demoting them to proposed so they can migrate when kodi is back makes most sense [12:01] rbalint: Having them around in the release pocket doesn't help much, and they might have regressions with kodi 19 [12:01] But they probably don't have autopkgtests either [12:01] but I assume they need to be rebuilt anyway [12:01] ? [12:02] I need to get lunch and write my +1 status down [12:52] juliank, all the addons need to be updated for the new upstream, so they can't come back [12:53] juliank, new upstream is already in experimental, imo it is ok to not have kodi for some time in devel [12:56] ack [13:08] TJ- juliank mwhudson maybe thoses perms need to be applied in futur isos [13:08] ? [13:10] and a "try except" should be added [13:13] because using nfsroot should be a default handled way to go, the "fix" looks actually a workaround to me [13:26] Cinnamon Desktop (upstream) 4.8.0 has been released [13:26] choo choo, I'll go tell Norbert to get it in experimental [15:37] sil2100, mhudson: I've updated the information for Bug #1882375 (SRU), got some time to help? [15:37] bug 1882375 in cinnamon (Ubuntu Focal) "[SRU Patch Available] Cinnamon custom keyboard shortcuts don't work until logout" [Low,In progress] https://launchpad.net/bugs/1882375 [15:47] ItzSwirlz: sure! The same debdiff as before? [15:47] Yes, debdiff has been the same-it's the regression potential [15:48] regression pot has changed [15:51] Awesome, on it in a few minutes! [15:51] thx [16:11] sil2100, vorlon, L_aney, could one of you review https://code.launchpad.net/~seb128/debian-cd/layerfs-canary-option/+merge/394137 ? (I'm fine doing the style change Dimitri suggested if that's a oreferred style) [16:29] seb128: the change is obviously correct, and we must have it back to unbreak canary images.... [16:29] seb128: but yeah, i can't merge it. [16:29] seb128: I can take a look at that and merge once I finish this thing here real quick [16:29] * xnox ponders if i should apply to be in ~ubuntu-cdimage [16:30] xnox, right, I was just pointing out that I don't care about the shell syntax so whoever wants to merge it just feel free to change to suit your taste: ) [16:30] sil2100, thanks! [16:30] xnox: Would always appreciate extra help for UCR's iso-builder [16:30] :P [16:40] seb128: done o/ [16:40] sil2100, thanks! [16:40] seb128: I'll deploy the change on ancientminister so that it gets picked up with the next build [16:41] sil2100, speaking of which, the canary image was commented out from the cronjob since unmaintained and failing to build, with the recent livecd-rootfs and that one merged it should build again, could be get it enabled again? [16:55] seb128: oh, I didn't know (or forgot) about that! Sure [16:56] seb128: is it still done via a SUBPROJECT? [16:59] seb128: done [17:00] I remember that it being done via a SUBPROJECT but still using the same image type as regular Ubuntu was a bit problematic, with those double-timestamps etc. [17:01] Would be nice if that got re-visited, so we can properly publish the images === ijohnson is now known as ijohnson|lunch === ijohnson|lunch is now known as ijohnson [19:42] sil2100, yes, still a subproject, I just fixed the problems that impacted build and ack for changing to a proper image, we will try to do that this cycle [22:49] Are SRU's allowed if it is just basically making sure that the program doesn't divide by 0? [22:49] because it essentially may or may not have a user impact [23:41] ItzSwirlz: does the program divide by 0 because of user input / misconfiguration? Or is this a bug [23:58] It can happen due to user input/misconfig [23:59] It is a bug, but I can't find any possible way to replicate it [23:59] If it can be replicated somehow and I'm not aware, regardless of wether it is a problem or not should it just never div by 0