=== scoobydoo_ is now known as scoobydoo
[07:48] <ExeciN> Hi people. I recently deployed 7 servers (VMs) on upcloud by importing ubuntu live server 22.04.1 iso. I went through the TUI installer and kept things mostly vanilla. I increased the / partition to the max possible to take over the whole disk and imported some ssh pub keys to allow key authentication. Other than that, the only difference was the hostname.
[07:50] <ExeciN> after that I used input broadcast (a feature of iTerm and probably others too that allows sending the same keystrokes to multiple terminals) and set up docker using the official docker repo (not canonical's snap/packages)
[07:52] <ExeciN> after a reboot of all 7 VMs, one of them refuses to get an IP from any of the 3 interfaces (one is configured to get a public ipv4 from upcloud's dhcp server, the other is configured to get a private ipv4 from upcloud's dhcp server and the other is configured to get a public ipv6 from upcloud's dhcp server)
[07:55] <ExeciN> I checked dmesg for anything weird but the logs of the VM that has no network matches the logs of the other 6 VMs that networking works
[07:56] <ExeciN> upcloud's support suggest a redeploy since this is a newly setup server but I'm afraid that this might happen later to any other VM again so I prefer to at least find out what went wrong instead of redeploy that one VM.
[07:56] <ExeciN> can anyone suggest on what/where to look for on how to debug this issue?
[08:11] <samy1028c> ExeciN: are you able to connect to a console on the VM?  So it's not getting a DHCP address at all?  Can you look in syslog and other things to see what DHCP is reporting compared to the other systems?
[08:24] <ExeciN> samy1028c: yes, I'm able to connect to a console. This is how I checked the dmesg. It looks identical to the other 6 servers. I will try and check /var/log/syslog and see if it differs from the other 6 VMs
[08:27] <samy1028c> if you do an "ifconfig"  or "ip addr" is it showing the 3 nics and is showing anything for the actual IP addresses?  Or is it 127.0.0.1 or 169.??? link-local type addresses?
[08:50] <ExeciN> I tried sudo dhclient -r and dhclient and I got ip on all 3 interfaces
[08:51] <ExeciN> samy1028c: sorry, didn't see on time. I was getting no ip addresses
[08:53] <ExeciN> since releasing the IP and requesting again using DHCP worked. Is it safe to assume that this is DHCP server's fault?
[09:05] <samy1028c> possibly.  Though I'd try rebooting again and seeing if it picks up the address again properly.
[09:21] <ExeciN> it doesn't pick up the address
=== MJCD is now known as Wubulub
[12:40] <skeer> Morning! So recently I stood up a few Ubuntu 22.04LTS hosts as Splunk forwarders using rsyslog to collect source device log data. For the past week every morning I've had .backup files after log rotation. I wanted to ask if, in 22.04, should I rely on the cron.daily rotation or the timer/service in systemd? Like they both exist by default, and it seems like one might be clobbering the other.
[12:42] <rbasak> On 22.04, /etc/cron.daily/logrotate doesn't run if systemd is detected.
[12:43] <rbasak> Sorry, that's unclear. It runs, but tests for systemd and exits if systemd is running.
[12:44] <skeer> Interesting, no no I got you :) So, maybe the cron.daily still exists as a backup of sorts.
[12:45] <skeer> Well I def appreciate the info.. I do wish maybe that <was> the cause of this lol. But yeah.. thanks rbasak 
=== y0sh- is now known as y0sh_
=== scoobydoo_ is now known as scoobydoo
[15:49] <znf> I'll never understand who the hell made the Subiquity text installer ask for SUBNET first on the network ipv4 config
=== scoobydoo_ is now known as scoobydoo
[15:50] <znf> And just why doesn't it take an IP address in CIDR notation
[15:53] <znf> ...and why I can't skip the user creation...
[15:53] <znf> ...and why I can't set mount options anymore
[16:46] <znf> also, my favorite is the installer creating a netplan config with gateway4
[16:46] <znf> but then netplan itself complains about gateway4 being deprecated
[16:50] <patdk-lap> oh, mine wouldn't even work till I removed gateway4 for a route
[19:45] <Odd_Bloke> Hmm, not really sure where to go with this problem: we import `main` packages from $dist, $dist-updates and $dist-security into a single internal `main` repository.  We're using debootstrap to create chroots from that single `main` repository, and we're running into a problem now that a new `libext2fs2` version is present: `e2fsprogs` Pre-Depends on an exact version of of `libext2fs2` so, despite the
[19:46] <Odd_Bloke> fact that the chroot is created OK, debootstrap errors out because it attempts to install the "missing" Pre-Depends package for e2fsprogs (the new version, which is not what's installed in the chroot), but the package is already installed.
[19:47] <ahasenack> no idea, *but*, could it be related to the phasing issues?
[19:48] <ahasenack> like what happened here: https://bugs.launchpad.net/bugs/1990586
[19:48] <ubottu> Launchpad bug 1990586 in apt (Ubuntu) "22.04: python3* mismatched phasing breaks dist-upgrades" [Critical, In Progress]
[19:48] <Odd_Bloke> Nope, this is pointing at our own repos, which are internally consistent (we have scripting around britney2 to make sure!)
[19:48] <ahasenack> you caged britney2!
[19:48] <ahasenack> :)
[19:49] <sarnold> Odd_Bloke: I don't actually understand debootstrap all so well, but I've heard that mmdebstrap has relaxed some constraints from debootstrap that might make this easier to handle
[19:49] <sarnold> leave britney2 alone!! *sob*
[19:49] <Odd_Bloke> Part of the problem here is that `debootstrap` doesn't use the most recent versions available to generate the chroot: this is because `pkgdetails_field` emits the first stanza for a package it finds, and exits once it has emitted stanzas for all the packages requested.
[19:50] <Odd_Bloke> I have a fix for that which makes it emit the _last_ stanza it finds, which works for our use case (evidently Artifactory just appends new packages to the metadata files).
[19:51] <sarnold> yeah that's one of the things I've heard mmdebstrap does better
[19:53] <Odd_Bloke> And there is already logic present which will select the last of stanzas in the first sequence of stanzas it finds for a package: my logic is effectively an extension of that to the whole file.
[19:53] <Odd_Bloke> sarnold: Yeah!  mmdebstrap is basically my backup plan if I can't figure out how to get this fixed in debootstrap.
[19:54] <Odd_Bloke> Or possibly maintaining an internal, patched debootstrap, though I'd like to avoid that if possible.
[19:54] <sarnold> heh yeah. open source is great because you *can*, but it'd sure be nice to avoid it ;)
[19:57] <Odd_Bloke> The lines of code I've modified haven't been touched in ~10 years, so I'm not _too_ worried about repeated merge conflicts :D
[19:57] <Odd_Bloke> But yeah, still, haha
[19:59] <Odd_Bloke> xnox: o/ I see you uploaded the most recent debootstrap to Debian: perhaps you have some thoughts on whether a fix like this would be acceptable upstream?
[20:01] <Odd_Bloke> https://pastebin.ubuntu.com/p/pGmKGTXPQW/ is the patch
[20:01] <rbasak> Odd_Bloke: I was going to say - both Debian and Ubuntu only publish one version of a package per apt suite, I think. It's a relatively new thing that I've noticed some third party apt repositories do otherwise. I'm not surprised that it only works with apt and not debootstrap.
[20:03] <rbasak> I'm not sure it's really valid, though the format isn't really specified formally anywhere.
[20:09] <Odd_Bloke> rbasak: I don't think that's true, there are 56 `linux-tools-common` stanzas in focal-updates main, e.g., amongst others: https://pastebin.ubuntu.com/p/3xy2npFP7w/
[20:10] <Odd_Bloke> (I expect it _is_ true of Ubuntu release suites, which is the usual Ubuntu debootstrap target, of course!)
[20:12] <Odd_Bloke> (Though, in fact, kinetic has two samba-commons at the moment, so emphasis on the _release_ :p)
[20:14] <Odd_Bloke> And jammy universe has two versions of a bunch of GCC -cross packages (though, again, not a debootstrap target).
[20:16] <rbasak> That's interesting. And odd.
[20:17] <rbasak> I wonder if it's deliberate. I can't think of any reason for this to occur.
[20:18] <rbasak> If I remember, I might ask in #laucnhpad about this on Monday
[20:19] <rbasak> Specifically, why is Ubuntu publishing these duplicates and not always or never?
[20:26] <Odd_Bloke> It's also worth noting that debootstrap's existing code (c. 2010) handles multiple stanzas for the same package: https://salsa.debian.org/installer-team/debootstrap/-/commit/0fbf86aa8fbcd06cb62fddddcfd4605fef2ee8b2
[20:26] <ubottu> Commit 0fbf86a in installer-team/debootstrap "pkgdetails_perl: Use the last of a sequence of stanzas for the same package name, rather than the first (closes: #649319)."
[20:28] <Odd_Bloke> (But only if they're contiguous in the file, which they _aren't_ in our case.)
[20:28] <znf> Our of curiosity, why would you merge repositories? 
[20:28] <znf> What's the point of that?
[20:29] <rbasak> "This is an unusual situation; I think DAK included both perl-modules because it's arch all and different versions are needed on different architectures. It follows that there's no single right version -- a dependency resolver is needed to pick the right one."
[20:29] <rbasak> That might explain things
[20:30] <rbasak> There's some interesting further disucssion in that bug - thanks.
[20:37] <Odd_Bloke> znf: For our downstream consumers, we don't care about the distinction between release, non-security update and security update: we have a single set of package versions that all of our focal nodes should use.
[20:38] <znf> Sounds weird, I don't see the advantage
[20:38] <Odd_Bloke> Well, it's less work to maintain a single repo than multiple repos. :p
[20:39] <Odd_Bloke> We also don't mirror the repos: we have a filtering/import process, so not all of main is available internally, only what we need.
[20:45] <rbasak> Why don't you filter it to only provide the highest versions at the repo end?
[20:46] <rbasak> Or do you need older versions to somehow be available, too?