[01:11] <Maxwell175> Hello all, I am trying to build the 5.13 kernel from https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.13/ but the cloned git repo doesn't have a debian folder.
[01:14] <Maxwell175> sorry for the probably stupid question
[01:28] <JanC> I assume you mean you want to build kernel packages (because to build the kernel itself you don't need a debian folder)
[01:30] <Maxwell175> yes, correct
[01:31] <Maxwell175> I'd like to build the image and header packages
[02:02] <Maxwell175> so, after some further research, I stumbled across https://wiki.ubuntu.com/KernelTeam/GitKernelBuild
[02:03] <Maxwell175> I tried to follow those instructions, but after the `make deb-pkg` command, I ended up with:
[02:03] <Maxwell175> make[2]: *** [debian/rules:7: build-arch] Error 2
[02:03] <Maxwell175> dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
[02:05] <Maxwell175> and there doesn't seem to be any more verbose error no matter how far I scroll up. and if I do try to re-run it, I get "dpkg-source: error: unrepresentable changes to source" so I can't even retry it apparently
[03:33] <Maxwell175> so, I ended up figuring out that I can run "debian/rules binary" directly and that gave me an error about not being able to find zstd, so I installed it and did a distclean, re copied the config, set SYSTEM_TRUSTED_KEYS to "" as I found on a random askubuntu thread and re-ran the `make bindeb-pkg` and so far there aren't any errors, although it has been stuck after linking a bunch of stuff. Hopefully it'll finish 
[03:33] <Maxwell175> whatever its doing soon.
[08:10] <nibbon_> question: for kernel dump coming from 5.4.0-58 can I use >=  linux-image-5.4.0-74-generic-dbgsym or I do need the specific package linux-image-5.4.0-58-generic-dbgsym?
[10:58] <xnox> Maxwell175:  you should do `fakeroot ./debian/rules clean` prior to trying to call `./debian/rules build` and then `fakeroot ./debian/rules binary`
[10:58] <xnox> Maxwell175:  the clean step, actually generates lots of build files. Including for example the files that are references by SYSTEM_TRUSTED_KEYS among other things.
[11:40] <Maxwell175> xnox, Yeah, its been stuck all night at the same place with no progress
[11:41] <Maxwell175> I actually ran make bindeb-pkg which I thought does everything
[11:51] <Maxwell175> huh, I actually had to kill the innermost make process for it to stop. just Ctrl-C did nothing
[11:51] <Maxwell175> ^C^Cmake[4]: *** [scripts/Makefile.modpost:156: __modpost] Killed
[12:25] <Maxwell175> `fakeroot ./debian/rules binary` got the build to finally finish! thanks!
[12:26] <dijuremo> Have LACP bonding problems on an Ubuntu 20.04 machine, is this the right channel to ask about it, given bonding it is a kernel module?
[12:27] <Maxwell175> hmm, wait, something didn't work right. I tried to install the linux-libc package but ended up with "package linux-libc-dev:amd64 5.13.0-rc6-md-1 cannot be configured because linux-libc-dev:i386 is at a different version (5.4.0-77.86)"
[12:28] <Maxwell175> how would I also build an i386 version?
[13:03] <dijuremo> We have a new ASUS 2U server ESC4000A-E10, it uses the ASUS KRPG-U8 Server board. It comes with two 1Gbit NICS and remote management interface.
[13:05] <dijuremo> The NICS are Intel I350-AM2 and use the igb module. When we configure them for bonding using netplan, the partner interfaces always come up as Churned. We can get it to work by unplugging another server that is already working OK in LACP in two different ports. Then moving our server nics to those ports. At that point things worked just fine.
[13:05] <dijuremo> However, if we reboot the server, then the bond breaks and things no longer work.
[13:11] <dijuremo> It seems as if the initial negotiation phase for LACP to establish the bond fails. How may I be able to fix this? Running on ubuntu 20.04 with 5.4.0-77 and had tried 5.4.0-74 as well.
[13:21] <nibbon_> o/
[13:21] <nibbon_> (reposting, sorry for the duplicate) question: for kernel dump coming from 5.4.0-58 can I use >=  linux-image-5.4.0-74-generic-dbgsym or I do need the specific package linux-image-5.4.0-58-generic-dbgsym?
[13:30] <cascardo> nibbon_: you should use the specific package. you need matching debug symbols for the dumped kernel
[14:53] <nibbon_> cascardo: thanks, that confirms what I was thinking
[15:20] <dijuremo> In an attempt to try something different, we upgraded to the linux-generic-hwe-20.20 kernel which gives the 5.8.0-59 kernel, but the LACP problem persists. The interface partners are Churned on a cold boot. If I move the cables to a set of port where another server is working OK with LACP already, then the bond works until I reboot the server.
[16:00] <dijuremo> That should had read ***linux-generic-hwe-20.04*** kernel...
[17:50] <TJ-> dijuremo: I presume it's actually systemd-networkd handling the network config (netplan just writes config files)
[17:56] <juergh> Maxwell175, how did you end up with linux-libc-dev:i386?? And you typically don't need to install a matching linux-libc-dev with a new kernel.
[17:56] <dijuremo> Yes, we have this set in config: renderer: networkd
[18:00] <dijuremo> Interestingly enough, we have gotten it to work on a different switch as a test. It does *not* work on a pair of Cisco N9K-C93108TC-EX switches, where a vpc is created in between same port numbers, i.e. vpc10 port 10 on both switches. We move the network connections to a Cisco 2960X and it worked on that one after a reboot.
[18:29] <TJ-> dijuremo: check what the actual generated config is, /run/systemd/network/ 
[18:31] <TJ-> dijuremo: there are some 'man systemd.network' options you can use to modify the bond directly - if these are static hardware I'd dump netplan and write systemd-networkd configuration statically to /etc/systemd/network/ so there is full access to all options
[18:32] <TJ-> dijuremo: here's an example of a 4-port 802.11ad 'bandwidth' bond I use https://iam.tj/projects/ubuntu/systemd-networkd-bonding.txt
[18:32] <TJ-> opos, 802.3ad even!
[23:07] <Maxwell175> juergh, no idea how I got the i386 version. i definitely didnt install it manually, but if I remove it, I end up having to also remove "libc6-dev:i386 libncurses-dev:i386 libncurses5-dev:i386 libreadline-dev:i386 linux-libc-dev:i386 zlib1g-dev:i386"
[23:08] <Maxwell175> that train doesn't look too long so maybe its worth removing and getting the new version... or should I just not install the new version for now