Yarda's devel blog: How to recompile Fedora kernel with the custom patch

neděle 22. října 2017

How to recompile Fedora kernel with the custom patch

I has been asked how to recompile Fedora kernel with the custom patch, so here is the tutorial:

At first install the needed packages:

# dnf install fedpkg dnf-plugins-core

Install build requirements for the kernel package:

# dnf builddep kernel

Clone the kernel dist-git module for the desired Fedora version, i.e. if you want to recompile the kernel for the Fedora 26, add the '-b f26' or respective version (--anonymous is used for the anonymous checkout, i.e. read only checkout):

$ fedpkg co --anonymous -b f26 kernel

Change the working directory to the cloned dist-git module:

$ cd kernel

Copy the desired patch (e.g. my.patch) to the working directory:

$ cp DIR/my.patch .

Make sure your my.patch has been generated by the 'git format-patch' if not, you need to manually add the header containing lines From:, Subject:, so proceed the following step just only if such header is not presented in your patch (of course edit the strings as needed):

$ echo "From: Joe Hacker <joe.hacker@hacker.org>" > header
$ echo "Subject: My patch" >> header
$ echo >> header
$ cat header my.patch > patch
$ mv patch my.patch

Edit the kernel.spec, locate the string '# END OF PATCH DEFINITIONS', and add the following string just before it:

Patch9999: my.patch

where make sure that the number 9999 is not used by any previous Patch keyword. If it's already used, keep increasing the number until you will find the highest unused number and use it with your patch. Save the spec file.

Recompile the kernel:

$ fedpkg local

Install/re-install the newly builds kernel RPMs from the ARCH directory, i.e. if you compiled the kernel for the x86_64, the ARCH directory is x86_64.

Reverted patch

In case you have upstream kernel patch you need to revert (let's say upstream.patch, do the previous steps up-to the installation of the my.patch, then unpack the kernel sources:

$ fedpkg prep

Make the reverted patch of the upstream.patch (replace the DIR in commands below by directory where you store your patches):

$ pushd kernel-*/linux-*
$ git commit -am Flush
$ cp DIR/upstream.patch .
$ patch -p1 -R < upstream.patch
$ git commit -am "Upstream reverted patch"
$ git format-patch --stdout HEAD~1 > DIR/upstream-reverted.patch
$ popd

Then install the upstream-reverted.patch instead of the my.patch and proceed with the compilation as described above.

23 komentářů:

Kydd23. října 2017 v 15:46
Thanks for writing this! First, typo on the word "bellow". Then my question is from this step:
"patch -p1 -R my-patch.patch"
I'm not clear on what "my-patch.patch" should be if I'm just reverting a committed patch. In this instance we are referring to https://marc.info/?l=linux-kernel&m=150703479427738&w=2.

I believe the contents of "my-patch-reverted.patch" should just be:
---
fs/cifs/smb2pdu.c | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)

--- a/fs/cifs/smb2pdu.c
+++ b/fs/cifs/smb2pdu.c
@@ -644,15 +644,22 @@ int smb3_validate_negotiate(const unsign

/*
* validation ioctl must be signed, so no point sending this if we
- * can not sign it. We could eventually change this to selectively
+ * can not sign it (ie are not known user). Even if signing is not
+ * required (enabled but not negotiated), in those cases we selectively
* sign just this, the first and only signed request on a connection.
- * This is good enough for now since a user who wants better security
- * would also enable signing on the mount. Having validation of
- * negotiate info for signed connections helps reduce attack vectors
+ * Having validation of negotiate info helps reduce attack vectors.
*/
- if (tcon->ses->server->sign == false)
+ if (tcon->ses->session_flags & SMB2_SESSION_FLAG_IS_GUEST)
return 0; /* validation requires signing */

+ if (tcon->ses->user_name == NULL) {
+ cifs_dbg(FYI, "Can't validate negotiate: null user mount\n");
+ return 0; /* validation requires signing */
+ }
+
+ if (tcon->ses->session_flags & SMB2_SESSION_FLAG_IS_NULL)
+ cifs_dbg(VFS, "Unexpected null user (anonymous) auth flag sent by server\n");
+
vneg_inbuf.Capabilities =
cpu_to_le32(tcon->ses->server->vals->req_capabilities);
memcpy(vneg_inbuf.Guid, tcon->ses->server->client_guid,

So is there an extra step here? I guess my question really is, with regards to this patch, what should the contents of "my-patch.patch" be?
OdpovědětVymazat
Odpovědi
Kydd23. října 2017 v 20:31
I'm doing it under /root. Does 'fedpkg local' need to be run in the /root/kernel directory?
OdpovědětVymazat
Odpovědi
Kydd23. října 2017 v 20:56
Hm stil errors with "RPM build errors:
Could not execute local: rpmbuild --define '_sourcedir /root/kernel' --define '_specdir /root/kernel' --define '_builddir /root/kernel' --define '_srcrpmdir /root/kernel' --define '_rpmdir /root/kernel' --define 'dist .fc26' --define 'fedora 26' --eval '%undefine rhel' --define 'fc26 1' -ba /root/kernel/kernel.spec | tee .build-4.13.9-200.fc26.log"
OdpovědětVymazat
Odpovědi
Kydd23. října 2017 v 22:17
Yep: Package rpm-build-4.13.0.1-7.fc26.x86_64 is already installed, skipping. See https://pastebin.com/DP2rhz0b for the fedpkg prep results
OdpovědětVymazat
Odpovědi
Kydd31. října 2017 v 14:54
I was able to create the kernel RPMs. They installed and rebooted just fine. However I believe our issue is slightly different. It's not a Windows 10 host. It's a Drobo backup unit. So even though we specify version 1 for SMB we are still getting this error with autofs: kernel: No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
Oct 31 09:48:45 me kernel: CIFS VFS: cifs_mount failed w/return code = -112
OdpovědětVymazat
Odpovědi

Okomentovat