The following metadata was found in MoinMoin that could not be converted to a useful value in MediaWiki:
- : END OF PATCH APPLICATIONS
- %: define buildid .local
2/6/2011 RAF - Recommend in the "build the kernel" option: since you told us to rename .local to .mycustomkernel (or what have you), just tell us to go build the firmware right away. As it is now, you have to get down to the "install the kernel" section before I realized that I had to rebuild the firmware.
2/6/2011 RAF - In "install the new kernel," suggest putting the paragraph, "If you changed the name of your kernel as requested,..." in order first, above the one-liner that just installs the kernel. For the one-liner, say "If you just rebuilt the kernel only, do this..."
2/6/2011 RAF - The full kernel build process took 1hr 45min on a OptiPlex 755 w/reasonably fast SATA drive and dual core processor.
10-apr-2011 aakolov - should the pure vanilla kernel be built the same way or there is a special approach for that ?
--Smouch (talk) 11:45, 21 February 2015 (UTC)I would really like to see a page describing how to do non-fedora specific kernel development on a Fedora machine. IOW, I wish to be able submit patches into the non-Fedora specific kernel development tree - you know, torvalds git repo - but, am constantly fighting to reconcile the generic instructions (for example: [1]) and performing testing of those modifications on my Fedora machine. For some reason, the two sets of instructions (this and that) are somehow subtly conflicting.
DNF vs. YUM
Ilmostro (talk) I'm not sure when/why the references to pre-Fedora22 systems were removed and replaced with dnf-specific instructions. It would be wise to leave yum-specific instructions as well, even if it's for historical purposes.
Outdated?
I think that ".$subver" should be removed and patches should be created using git format-patch, otherwise build fails. Sections 3.3, 3.4 and 3.5 should be updated. Frafra (talk) 13:34, 23 December 2015 (UTC)
- Eha (talk) 11:19, 24 January 2016 (UTC) I agree, I have tried to build a kernel with the reiser4 patch and the guide completely misses on how to get it to compile.
It fails due to the format of the patch, which isn't a 'git' patch (and nowhere is it mentioned on the Howto).
Proposed Changes
Eha (talk) 11:19, 24 January 2016 (UTC) The following is what I found during my attempt to build a kernel with reiser4-for-4.3.0.patch (I have not changed the Wiki as I'm not sure I am on the right track to get it to build):
- In section 3.5 it says: 'The patch then needs to be applied..'
I could not find any place where the ApplyPatch was called in thekernel.specfile, and it seems to be done 'automatically' as long as the patch is listed in the patch section ofkernel.spec- so these lines can be removed. - A description of how to convert an 'ordinary' diff generated patch to a git patch
- An example on this may be a good idea, here the
reiser4-for-4.3.0.patchcould be used (but it's a bit large, so maybe some smaller patch would be better).
- An example on this may be a good idea, here the
- Add a section describing the actual disk space requirements to build the kernel
It is hard to guess, and you can only see that you didn't have enough, if you have enough the build process removes a number of intermediate files, so it doesn't leave any clues of what you need.
I found that a partition with 20475272 1k blocks was NOT enough when I used ext3 filesystem (using reiserfs, it provided apx 1.1GB more available, and was enough to build - without pae and zen).