Hello kernel team, the systemd packages will soon need the kernel headers package to ship a generated vmlinux.h to build BPF programs (using BTF). This is already implemented in Debian, Centos, Fedora and Arch.
Would it be possible for the kernel team to have a quick look at Bug #2050083 “generate and ship vmlinux.h to allow packages to b...” : Bugs : linux package : Ubuntu please? Thanks!
Due to the whole xz debacle, the devs have taken the precaution of rebuilding everything published since February 26th.
Hi, I have a situation here…
I am currently trying to get this working:
https://github.com/torvalds/linux/blob/master/drivers/thunderbolt/icm.c#L2445
Looks like all I should have to do is change one line of code, rebuild the existing kernel that I’m running, and everything should work…unfortunately I am new to this, so something is not working.
I am going by these instructions here (Kernel/BuildYourOwnKernel - Ubuntu Wiki), and I am currently running the OEM kernel 6.5.0-1019
I am running this kernel on Jammy because I also have an Intel Wifi7 adapter that requires this (I think…it doesn’t work on older kernels)
Anyway, I follow the build instructions for “quicker build” and it fails after 25 minutes or so, the error is
Debug: /home/nick/linux-oem-6.5-6.5.0/debian/stamps/stamp-install-generic kernel_file arch/x86/boot/bzImage kernfile arch/x86/boot/bzImage install_file vmlinuz instfile vmlinuz
dh_testdir
dh_prep -plinux-image-unsigned-6.5.0-1019-generic
dh_prep: error: Requested unknown package linux-image-unsigned-6.5.0-1019-generic via -p/–package, expected one of: linux-oem-6.5-headers-6.5.0-1019 linux-oem-6.5-tools-6.5.0-1019 linux-oem-6.5-tools-host linux-image-unsigned-6.5.0-1019-oem linux-modules-6.5.0-1019-oem linux-modules-extra-6.5.0-1019-oem linux-headers-6.5.0-1019-oem linux-oem-6.5-lib-rust-6.5.0-1019-oem linux-image-unsigned-6.5.0-1019-oem-dbgsym linux-tools-6.5.0-1019-oem linux-cloud-tools-6.5.0-1019-oem linux-buildinfo-6.5.0-1019-oem linux-modules-ipu6-6.5.0-1019-oem linux-modules-ivsc-6.5.0-1019-oem linux-modules-iwlwifi-6.5.0-1019-oem linux-modules-usbio-6.5.0-1019-oem
dh_prep: error: unknown option or error during option parsing; aborting
make: *** [debian/rules.d/2-binary-arch.mk:132: /home/nick/linux-oem-6.5-6.5.0/debian/stamps/stamp-install-generic] Error 255
I am a total newb with Ubuntu so I would ask maybe is there an easier way to change that thunderbolt driver code without having to recompile? If not, any clues as to why the build is failing?
edit:
Okay I’m dumb. I needed to build binary-oem, not binary-generic. Lol. Works now.
Using Ubuntu Server 24.04 LTS for Raspberry Pi, I noticed it has not been built with BTF support. Was this intentional? Can it be compiled with BTF in the future. We need it to load BPF programs for XDP sockets.
It’s more of an organizational question - but how it currently looks when somebody from community/outside would want to contribute?
Trying to install proposed kernel on Ubuntu Oracular from PPA Kernels as in Proposed : “Canonical Kernel Team” team I see:
Err:4 Index of /canonical-kernel-team/proposed/ubuntu oracular InRelease
The following signatures were invalid: 110E21D8B0E2A1F0243AF6820856F197B892ACEA (untrusted public key algorithm: rsa1024) The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 9B5F34077FA4288A
Hit:5 Index of /ubuntu oracular-backports InRelease
Warning: GPG error: Index of /canonical-kernel-team/proposed/ubuntu oracular InRelease: The following signatures were invalid: 110E21D8B0E2A1F0243AF6820856F197B892ACEA (untrusted public key algorithm: rsa1024) The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 9B5F34077FA4288A
Error: The repository ‘Index of /canonical-kernel-team/proposed/ubuntu oracular InRelease’ is not signed.
Notice: Updating from such a repository can’t be done securely, and is therefore disabled by default.
Notice: See apt-secure(8) manpage for repository creation and user configuration details.
Why aren’t Canonical’s AppArmor patchsets in the kernel officially?
I saw on reddit about Solus removing Snaps support.
I heard on a podcast (I think it was Destination Linux 376) that Canonical’s in charge of AppArmor already, so why the separate thing?
They are. They just land in Ubuntu first before they’re upstreamed.
So how does Snaps’ confinement work, and how come some distros only get partial confinement?
And how come Solus sees it as a burden?
Read the article you linked, it explains their rational. Let’s just stop the snap pros/cons discussion right here, I’m not going there.
I did read it, but I’m confused. If they’re already upstreamed, why the partial confinement? Is it that the app armor patches in upstream kernels are outdated or something?
And I’m not trying to going there. I just wanted to understand (I like Snaps and even went out of my way to enable it on my Tuxedo OS gaming PC and on my laptop with Pop!_OS).
@YamiYukiSenpai this isn’t the proper forum to discuss the whys and wheres of snaps or apparmor in general as both are developed outside of the kernel team, and definitely not the forum to discuss the rationale behind decisions made by other distributions. @jjohansen would be the best to answer your apparmor questions but he is not a member of the kernel team.
The partial confinement for snaps largely comes from the extended af_unix mediation missing in upstream apparmor, this also which includes the labeling necessary for the dbus interface. Parts of this have been upstreamed but it is not yet complete, the final parts should land in 6.12.
The 6.12 version will be a bit different than what has been carried in Ubuntu so far (24.10 should have the new version) as there was regression against upstream discovered, forcing an abi change causing this to miss 6.11.
A new version of the apparmor userspace will be required to support the abi change. However with snapd now vendoring apparmor, once it pulls in an update it will be able to support the upsteam version.
I realized that it was not a bug. So the issue “solved” …