Posted request for review on the devel list.

Why leave all the manual work now? The simple way would be to call 'kernel-install add' for installation and 'kernel-install remove' for the removal. This will take care of all of the relevant bits, and is exactly what the kernel.spec does for install or removal.

It actually looks as though most of the doc needs to be rewritten. It does not take into account the kernel-ark workflow that Fedora has been using for quite some time now.

Why leave all the manual work now? The simple way would be to call 'kernel-install add' for installation and 'kernel-install remove' for the removal. This will take care of all of the relevant bits, and is exactly what the kernel.spec does for install or removal.

I see where kernel-install is used in the specfile, but I'll be darned if I can figure out how to use it to install a kernel built from git:

$ sudo kernel-install add 5.18.0-rc6-installtest arch/x86_64/boot/bzImage
dracut: Cannot find module directory /lib/modules/5.18.0-rc6-installtest/
dracut: and --no-kernel was not specified

It actually looks as though most of the doc needs to be rewritten. It does not take into account the kernel-ark workflow that Fedora has been using for quite some time now.

The section being edited here is specifically targeted at building from Linus' tree for testing patches. Does the kernel-ark workflow make this easier or more intuitive for a regular user? It feel to me like documenting building and running a kernel directly from Linus' git tree (possibly with patches applied) still has value, but I could be wrong.

I am guessing you skipped the:

sudo make modules_install
sudo make install

bits from above in this document. You still have to do that. kernel-install handles dracut, the boot entries, etc but it does expect the files already exist in /lib/modules

It actually looks as though most of the doc needs to be rewritten. It does not take into account the kernel-ark workflow that Fedora has been using for quite some time now.

The section being edited here is specifically targeted at building from Linus' tree for testing patches. Does the kernel-ark workflow make this easier or more intuitive for a regular user? It feel to me like documenting building and running a kernel directly from Linus' git tree (possibly with patches applied) still has value, but I could be wrong.

Yes in that linus' tree is already in the kernel-ark tree as master, as are the upstream stable trees as linux-5.x.y branches, and there is a separate branch that can be merged onto any kernel git tree that adds the fedora config and build tools, but the comment was not directed at this PR directly. The kernel-install comments were directed at this PR, the other comment was directed at the fact that this document should have never migrated from the wiki to here to begin with.

Yes in that linus' tree is already in the kernel-ark tree as master, as are the upstream stable trees as linux-5.x.y branches, and there is a separate branch that can be merged onto any kernel git tree that adds the fedora config and build tools, but the comment was not directed at this PR directly. The kernel-install comments were directed at this PR, the other comment was directed at the fact that this document should have never migrated from the wiki to here to begin with.

Are you saying there is other documentation that should have been migrated instead, or that the wiki page content should have been updated when it migrated to quick-docs?

At first blush I'm not sure it wouldn't be better if I added a bit of installation guidance to the kernel-ark documentation and then made this whole quick-doc point at the kernel-ark documentation.

Yes in that linus' tree is already in the kernel-ark tree as master, as are the upstream stable trees as linux-5.x.y branches, and there is a separate branch that can be merged onto any kernel git tree that adds the fedora config and build tools, but the comment was not directed at this PR directly. The kernel-install comments were directed at this PR, the other comment was directed at the fact that this document should have never migrated from the wiki to here to begin with.

Are you saying there is other documentation that should have been migrated instead, or that the wiki page content should have been updated when it migrated to quick-docs?

Well, the kernel-ark documentation is slightly more useful though it needs a little bit of work to catch up to the full intent of this doc, but by the time the wiki was migrated to quick docs, this document should not have been included as it is pretty out of date. It points to trees that are not longer updated, etc.

At first blush I'm not sure it wouldn't be better if I added a bit of installation guidance to the kernel-ark documentation and then made this whole quick-doc point at the kernel-ark documentation.

That may be the better path forward.

@nielsenb Can we chat about how to proceed here?

@pboy I have unfortunately had very little time to commit to Fedora lately, hopefully things should be clearing up soon.

I will say this went pretty far outside my wheelhouse once it changed from "making the documentation in Quick Docs work again" to "learn how to actually use Kernel Ark, update that documentation, then circle back here". I'm still glad to do it, but it won't happen fast. Any guidance given would probably make it happen faster.

@nielsenb many thanks for reply! I'm just (desperately) trying to fix (or organize a fix to) all the longstanding issues and to revive the docs team. At least we have some success with that. The next time you will hopefully contribute, to my best effort, there will be no more such delays and non-observance as occurred in the last 2–3 years.

Regarding this article, unfortunately, the last kernel I build was about a decade ago. So I can't decide, what to do here.

I also contacted @jforbes, but he didn't answer so far.

Another objective of mine is not to waste any effort made by community members. To that extent, at the moment I'm leaning towards running the PR, unless you as the author advise against it or want to update something beforehand. Or if concrete suggestions come from jforbes.

Merged the pull request based on the 14 days rule. Attempts to obtain further information (devel mailing list, direct inquiries) were unsuccessful. There is no specific rejection of the proposed changes, but general criticism of the timeliness of the article with regard to current developments.