Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 574054 - sys-apps/kexec-tools: update config files for new linux-4.3 kexec knobs
Summary: sys-apps/kexec-tools: update config files for new linux-4.3 kexec knobs
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-07 01:21 UTC by Terra
Modified: 2016-04-01 18:59 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
New ebuild that supports KEXEC_FILE loading (kexec-tools-2.0.9-r3.ebuild,1.54 KB, text/plain)
2016-02-07 01:22 UTC, Terra
Details
New /etc/conf.d/kexec file (kexec.conf-2.0.9-r3,1.10 KB, text/plain)
2016-02-07 01:23 UTC, Terra
Details
New /etc/init.d/kexec init file (kexec.init-2.0.9-r3,3.73 KB, text/plain)
2016-02-07 01:24 UTC, Terra
Details
Patch for existing kexec.init-2.0.4-r3 init file (0001-files-kexec.init-2.0.4-r3-Fix-comparison-bug-in-load.patch,1.14 KB, patch)
2016-02-07 01:25 UTC, Terra
Details | Diff
full kexec-tools patch for 2.0.4-r3 (bugfix) and 2.0.9-r3 (new ebuild) (kexec-tools.patch,13.63 KB, patch)
2016-02-09 20:25 UTC, Terra
Details | Diff
kexec.init-2.0.9-r3 (file_574054.txt,1.63 KB, text/plain)
2016-03-25 02:43 UTC, Terra
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terra 2016-02-07 01:21:04 UTC
Linux kernel 4.3 introduced a true split between KEXEC and KEXEC_FILE resulting in KEXEC_CORE that can be shared by either.  This is significant for hardened-sources users as the following is now possible:
CONFIG_KEXEC=n
CONFIG_KEXEC_FILE=y
CONFIG_GRKERNSEC_KMEM=y

Prior to 4.3, you had to have GRKERNSEC_KMEM=n in order to use KEXEC and friends...

I am submitting the following new files:
1) kexec-tools-2.0.9-r3.ebuild
2) kexec.conf-2.0.9-r3
3) kexec.init-2.0.9-r3

I am also submitting a patch for an initramfs comparison bug in files/kexec.init-2.0.4-r3:
1) 0001-files-kexec.init-2.0.4-r3-Fix-comparison-bug-in-load.patch


Reproducible: Always
Comment 1 Terra 2016-02-07 01:22:46 UTC
Created attachment 424796 [details]
New ebuild that supports KEXEC_FILE loading
Comment 2 Terra 2016-02-07 01:23:42 UTC
Created attachment 424798 [details]
New /etc/conf.d/kexec file
Comment 3 Terra 2016-02-07 01:24:12 UTC
Created attachment 424800 [details]
New /etc/init.d/kexec init file
Comment 4 Terra 2016-02-07 01:25:08 UTC
Created attachment 424802 [details, diff]
Patch for existing kexec.init-2.0.4-r3 init file
Comment 5 Terra 2016-02-07 01:32:34 UTC
Comment on attachment 424802 [details, diff]
Patch for existing kexec.init-2.0.4-r3 init file

In my /etc/conf.d/kexec file, BOOTPART was commented out using the default '/boot', and:
INITRD="/boot/initramfs.cpio.gz"

as I use better-initramfs
https://github.com/slashbeast/better-initramfs
Comment 6 Terra 2016-02-07 01:36:45 UTC
You may want to bump this ebuild and included new files to the latest: kexec-tools-2.0.11
https://www.kernel.org/pub/linux/utils/kernel/kexec/

Of note:
1) 2.0.9-r3 has been stable for me
2) manually compiled 2.0.11 has been stable for me as well
* both with: sys-kernel/hardened-sources-4.3.3-r4
Comment 7 SpanKY gentoo-dev 2016-02-09 18:29:22 UTC
please post diffs rather than entire files so it's easy for us to evaluate/apply
Comment 8 Terra 2016-02-09 20:25:50 UTC
Created attachment 425086 [details, diff]
full kexec-tools patch for 2.0.4-r3 (bugfix) and 2.0.9-r3 (new ebuild)
Comment 9 Terra 2016-02-09 20:26:48 UTC
My apologies, I did not realize you wanted new ebuild and files/* additions in patch form since their lineage was somewhat obvious...

Add full patch:  git format-patch --stdout master..HEAD -- . > kexec-tools.patch

This includes (in patch form):
1) new kexec-tools-2.0.4-r3.ebuild
2) new kexec-tools-2.0.9-r3.ebuild
3) new confd and initd files

If you need these as broken out as separate patches (7 total), please let me know...  I figured the 'Diff' feature of the Attachments section would show them split out and that would be acceptable...
Comment 10 SpanKY gentoo-dev 2016-02-09 21:54:04 UTC
(In reply to Terra from comment #9)

files often change in the tree independently, so unless people fix bugs immediately, when they do get around to looking at the submission later on, creating a diff manually will often include all the changes since.  conversely, if it's only a diff here, it's much easier to apply/update in the future.

it also makes it easier to do review in bugzilla so you can post updates right away.

we don't want to see the new ebuild as a full diff ... we want to see it as a diff compared to the existing ebuild in the tree.  so don't add a new kexec-tools-2.0.4-r3.ebuild file, update the existing one, and post the patch for it.
Comment 11 Terra 2016-02-09 23:04:10 UTC
understood...  I was looking at it from the perspective of doing a local branch of the portage tree, doing all the work for fixing 2.0.4-r2 (with 2.0.4-r3) and adding 2.0.9-r3 along with supporting confd and initd files...

This way I had full ebuilds to test against and also to emerge my fixed up 2.0.0-r3 for our immediate needs...  I was also thinking in terms of 'emerge -uav kexec-tools' instead of 'emerge -av kexec-tools'...

So what you are saying, is I should have done all the work inline on 2.0.4-r2 and 2.0.9-r2 and not created any new files at all (unless needed)...

I will try to change my perspective of the portage tree when fixing up or enhancing existing ebuilds and submit them patch proper in the future...

In the end, I thought I was helping out more by creating all the new files and bundling it up as an easy bundled drop into the portage tree (after review of course)...  So instead of me playing Santa, I ended up being Krampus...  :)
Comment 12 SpanKY gentoo-dev 2016-02-11 16:57:04 UTC
if you want to submit a request directly, then doing the revbump makes sense.  but for the purpose of review, we want to see just the changes you're making.  full new files hides that and we have to reverse things by hand.
Comment 13 SpanKY gentoo-dev 2016-03-24 21:22:02 UTC
in that patchset, i see two one line changes of relevance:

(1) in kexec.conf you do:
+#KEXEC_LOAD_FILE="no"
... but nowhere do you actually check that variable, and kexec-tools itself doesn't use that env var

(2) in kexec.init you do:
-		! [ "${BOOTPART}/${INITRD#${BOOTPART}}" = "${initrd}" ]; then
+		! [ "${BOOTPART}/${INITRD#${BOOTPART}/}" = "${initrd}" ]; then
this is tracked in bug 577496 and is orthogonal to kexec file loading in newer kernel features

so let's get this bug back on track: what exactly do you think needs to change in the init script to cater to the new linux kernel settings ?
Comment 14 Terra 2016-03-25 02:43:50 UTC
Created attachment 428980 [details]
kexec.init-2.0.9-r3

(In reply to SpanKY from comment #13)
> in that patchset, i see two one line changes of relevance:
> 
> (1) in kexec.conf you do:
> +#KEXEC_LOAD_FILE="no"
> ... but nowhere do you actually check that variable, and kexec-tools itself
> doesn't use that env var
> 

My mistake, I must have done a git reset on the tree and clobbered my changes before making the patch.  I've pulled it from backups and attaching the patch showing changes from:
kexec.init-2.0.4-r3 ==> kexec.init-2.0.9-r3

> (2) in kexec.init you do:
> -		! [ "${BOOTPART}/${INITRD#${BOOTPART}}" = "${initrd}" ]; then
> +		! [ "${BOOTPART}/${INITRD#${BOOTPART}/}" = "${initrd}" ]; then
> this is tracked in bug 577496 and is orthogonal to kexec file loading in
> newer kernel features
> 

Fair enough, I'll pull the changes from kexec.init-2.0.9-r3

> so let's get this bug back on track: what exactly do you think needs to
> change in the init script to cater to the new linux kernel settings ?
Comment 15 SpanKY gentoo-dev 2016-04-01 18:59:53 UTC
(In reply to Terra from comment #14)

you'll want to use kexec.init-2.0.12 now actually ;)

the KEXEC_LOAD_FILE default should be hoisted to the top of the file like the other defaults

i'm not sure why the -s flag is even exposed to the user though.  really looks like it should be something kexec itself handles internally.