| alkisg | Hi, the latest netplan broke ltsp booting; we mark the boot interface as "manual" in /etc/network/interfaces (and I tried marking it manual in network manager too), but netplan now somehow manages to remove its ip while the computer netboots | 05:20 |
|---|---|---|
| alkisg | `rm /lib/systemd/system-generators/netplan` bypasses the problem; but what would be the correct way to tell netplan not to touch the netboot interface? | 05:20 |
| alkisg | I think the relevant SRU that caused the regression was this one: https://bugs.launchpad.net/netplan/+bug/1763608 | 05:23 |
| ubottu | Launchpad bug 1763608 in netplan "Netplan ignores Interfaces without IP Addresses" [Undecided,Fix committed] | 05:23 |
| alkisg | cyphermox: ? (sorry for the ping, please ignore me if busy or if it's inappropriate) | 05:26 |
| alkisg | Netplan generates this file, while AFAIK it shouldn't, as enp0s3 is declared manual in /etc/network/interfaces: /run/systemd/network/10-netplan-enp0s3.network ==> https://termbin.com/51oc | 05:31 |
| alkisg | I commented in https://bugs.launchpad.net/netplan/+bug/1763608/comments/43 | 05:47 |
| ubottu | Launchpad bug 1763608 in netplan "Netplan ignores Interfaces without IP Addresses" [Undecided,Fix committed] | 05:47 |
| tkamppeter | seb128, thanks, have already seen the posts from slangasek on the bugs yesterday. | 11:58 |
| seb128 | tkamppeter, np | 11:59 |
| tkamppeter | seb128, kenvandine, looks a little bit like that the upstream version update from 1.10.6 to 1.10.14 is of too high impact (whereas a raise of only the micro release number should only add bug fixes). | 12:00 |
| tkamppeter | Seems we need to carefully select the upstream commits which only fix the bugs the users have complained about and make an SRU out of these. | 12:01 |
| seb128 | tkamppeter, it's trying to address difficult problems, we did discuss other ways but those were not easier | 12:01 |
| seb128 | I don't think that's true | 12:01 |
| seb128 | we need to figure out that specific regression and sort it out and try again | 12:01 |
| Laney | yep | 12:02 |
| seb128 | upstream seems supportive/ready to help but we need someone who understands the topic to have the conversation | 12:02 |
| seb128 | dwmw2 seems to be engaged and to understand the problem, so maybe he's that person | 12:03 |
| seb128 | but we should still engage/worth with him/them | 12:03 |
| tkamppeter | seb128, I have also tried one thing: I have asked the posters of the regression whether it helps to also install the systemd SRU (which I have therefore uploaded to my PPA), but got two negative answers on that (was simply trying a low-hanging fruit). | 12:05 |
| seb128 | tkamppeter, you should probably be on #nm btw, that's the upstream channel | 12:06 |
| seb128 | they discussed it a bit earlier and said that | 12:06 |
| seb128 | "<thaller> dwmw2_gone, bengal, the discussion there is long and not clear (to me). Also, there is a lack of logfiles to even understand what is actually happening. Anyway, to my understanding, setting "dns-priority=-1,dns-search=~." is not a "workaround". By default, NM's VPN profiles want to do split-dns and not full-tunnel. So, you need to explicitly configure avoiding "dns leaks". Whether that default is good or not is a separate question he | 12:06 |
| seb128 | re." | 12:06 |
| seb128 | anyway, I think what we lack at this point is someone on our side who understands the topic/components and can figure out what's going on exactly and talk with upstream | 12:08 |
| seb128 | I'm not sure how we solve that gap | 12:08 |
| seb128 | either by doing the needed studying or by involving people on our side who have the expertise I guess | 12:09 |
| seb128 | 12:09 | |
| seb128 | is error.u.c timing out for others? | 12:09 |
| seb128 | ah, it's back | 12:09 |
| seb128 | I just had to ask, it was failing to load for 10 min or so :p | 12:10 |
| === ricab is now known as ricab|lunch | ||
| === ricab|lunch is now known as ricab | ||
| === gusnan is now known as Guest54496 | ||
| === gusnan_ is now known as gusnan | ||
| rbalint | juliank, i think apt should tell me if i just ran apt update or apt upgrade on a release which left the standard support period | 18:38 |
| rbalint | juliank, i think it would be helpful on systems not showing motd, such as docker or wsl | 18:38 |
| juliank | ack | 18:38 |
| juliank | we can add that to ua client | 18:38 |
| juliank | I think | 18:39 |
| juliank | It's a bit tough to figure out if you're unsupported or not | 18:39 |
| juliank | (from C++) | 18:39 |
| juliank | oh hang on | 18:40 |
| juliank | With trusty esm it basically hints very strongly after upgrade, as it will tell you there are ESM updates | 18:41 |
| juliank | It might be worth telling people there release is in ESM now, or especially if it is EOL | 18:41 |
| rbalint | juliank, i think we should cover interim releases, too | 18:41 |
| rbalint | juliank, and clearly telling it is maybe better than just hinting it | 18:42 |
| rbalint | juliank, on zesty i see ... old-releases.ubuntu.com ... in apt update's log which is a hint, but i share rcj's concern that some users are still left on unsupported releases because the did not notice the hints | 18:45 |
| rcj | rbalint: how did you get that? shouldn't it just try archive.ubuntu.com and fail due to lack of Release files? What changed your zesty machine to old-releases.ubuntu.com? | 18:47 |
| rbalint | rcj, maybe me, just forgot that :-) | 18:50 |
| === gusnan is now known as Guest30687 | ||
| === gusnan_ is now known as gusnan | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!