=== esv_ is now known as esv
=== chris14_ is now known as chris14
[09:24] <jdarnley> Is it possible to instruct systemd to stop a particular service first on shutdown?
[09:26] <ogra> you can use Before= and After= in the unit files ... (just dont forget on shutdown the order is indeed reversed) 
[09:26] <jdarnley> damn
[09:27] <jdarnley> I need to check but I think it is first to start
[09:36] <nibbon_> o/ do you have a bug for this qemu's issue https://gitlab.com/qemu-project/qemu/-/issues/774
[09:36] -ubottu:#ubuntu-server- Issue 774 in qemu-project/qemu "Win(PE) NIC issue with pc-q35-6.1" [Opened]
[09:45] <cpaelzer> nibbon_: no there isn't
[09:50] <nibbon_> cpaelzer: do you think it's worth opening one? I can reproduce with 1:6.2+dfsg-2ubuntu6.9 (I looked at 6.10 and 6.11; however, haven't seen patches that might fix that issue)
[09:52] <cpaelzer> nibbon_: sadly the referred version to work on the case (https://git.proxmox.com/?p=pve-qemu.git;a=blob;f=debian/changelog;h=71160269225065ba75a1c621e959864efb451f8b;hb=refs/heads/master#l75) doesn't fix anything in the area this is supposed to be caused
[09:52] <cpaelzer> so it is hard to directly act if you'd report
[09:53] <cpaelzer> I think the problem atm is that the person that most actively tried/reported got it fixed and since then the upstream case fell silent
[09:53] <cpaelzer> but there is a chance (since it was fixed, but not mentioned as backport) that it got fixed by upstream - yet no one realized it is
[09:53] <cpaelzer> identifying that patch (if it exists) would be the most important next step, for the upstream report as well as a potential Ubuntu but
[09:54] <cpaelzer> nibbon_: is your repro setup good enough to a) test qemu in lunar (7.2) and mantic (8.0) and b) consider bisecting qemu git where it was fixed?
[09:54] <nibbon_> cpaelzer: afaict qemu 7.2 fixes that issue; in fact the goto response of upstream is: use 7.2 or master
[09:54] <cpaelzer> so it would be fixed in lunar and later indeed
[09:55] <cpaelzer> have I scrolled over the fix in this lengthy bug ? Did anyone point at the fixing commit already?
[09:55] <cpaelzer> re-reading
[09:55] <cpaelzer> nibbon_: but e.g. this says not all 7.2 is good https://gitlab.com/qemu-project/qemu/-/issues/774#note_1161360884
[09:55] -ubottu:#ubuntu-server- Issue 774 in qemu-project/qemu "Win(PE) NIC issue with pc-q35-6.1" [Opened]
[09:56] <cpaelzer> later on same report for later 7.2 - only the pvetest repo have them a fix there
[09:57] <nibbon_> cpaelzer: I haven't tried 7.2 yet (and honestly cannot backport even if that would solve the issue)
[09:57] <cpaelzer> but that repo doesn't mention anything in that regard - so either it is a false report or a fix got in without realizing it is a fix for this problem
[09:58] <nibbon_> cpaelzer: let's say it's hard to reproduce. I had several recurrences with Windows with the German localization, but also with Windows US
[09:58] <cpaelzer> bryceh: will soon update the qemu in https://launchpad.net/~canonical-server/+archive/ubuntu/server-backports to the 7.2 in lunar - that would ease things
[09:58] <cpaelzer> for you to test 7.2 in the same env at least
[09:58] <cpaelzer> nibbon_: once you have a failing setup, is it 100% reproducible then?
[09:58] <nibbon_> cpaelzer: not a big deal building 7.2 for Jammy
[09:59] <nibbon_> cpaelzer: still investigating, at the moment I'm not sure it's 100% reproducible 
[09:59] <cpaelzer> hmm, ok
[09:59] <nibbon_> that's why I came here asking, perhaps you heard of it already
[10:00] <cpaelzer> knowing if our 7.2/8.0 are affected helps, but really the critical step will be to be able to bisect it
[10:00] <cpaelzer> once you have concluded your analysis please file a bug
[10:00] <cpaelzer> we'd certainly want to track things and have a look ourselves
[10:00] <cpaelzer> as always - the most important aspect will be good steps to reproduce
[10:00] <cpaelzer> hence my ask on reproducibility
[10:02] <nibbon_> cpaelzer: ack and agreed
[10:02] <cpaelzer> Thanks for your effort to coordinate reporting this well! 
=== JanC_ is now known as JanC
=== cpaelzer_ is now known as cpaelzer
[12:31] <athos> paride: thanks for merging the kea MR in salsa :) should we go ahead and prepare a new debian release?
[12:45] <paride> athos, hi! yes, let's prepare one. I added a remote for the git-ubuntu imported version and did a git diff between debian/unstable and ubuntu/devel. Looks like we have all the changes in the debian packaging repo
[12:46] <paride> athos, there is a slight difference in the "strict symbols file" diff, looks like you improved it a bit when forwarding it to Debian
[12:46] <paride> athos, with a command + different quoting / variable expansion. Does this sound right?
[13:27] <athos> paride: yes!
[13:28] <athos> that was a result of one of (your?) review comments on the salsa MP IIRC. We should be good to release in debian and sync in ubuntu \o/
[13:42] <athos> paride: should we close https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033367 with this release or shall it remain open for further discussions?
[13:42] -ubottu:#ubuntu-server- Debian bug 1033367 in kea-ctrl-agent "kea-ctrl-agent: Unrestricted default RESTful interface on 127.0.0.1:8000" [Normal, Open]
[13:44] <paride> athos, I think it's OK to close it with the upload
=== JanC is now known as Guest5729
=== JanC_ is now known as JanC
[14:23] <athos> paride: ack. I am running autopkgtest locally and will file another MR soon then :)
[14:24] <paride> athos, thanks!
[15:06] <OutOfService> hi
[16:41] <athos> paride: done. the pipeline is failing due to https://bugs.debian.org/1040316
[16:41] -ubottu:#ubuntu-server- Debian bug 1040316 in python3-minimal "python3-minimal fails to install" [Grave, Open]
[16:41] <athos> https://salsa.debian.org/debian/isc-kea/-/merge_requests/30
[16:41] -ubottu:#ubuntu-server- Merge 30 in debian/isc-kea "Prepare for 2.2.0-7 release" [Opened]
[17:20] <OutOfService> hi
[17:35] <OutOfService> I'm trying to configure ubuntu autoinstall. Everything seems to be working fine. But I'm afraid to forget that autoinstall uses to get the biggest disk in order to install ubuntu on it, and connect the raid controller (connect it using vmware vsphere passthrough).. I'd need some kind of trick so as autoinstall detects the SN of the raid controller, and prevent to install ubuntu on any 
[17:35] <OutOfService> of these disks. Can anybody help me with this? Thanks in advance!
[17:39] <OutOfService> for example, something that put the raid controller offline while being inthe install part