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