| Summary: | sys-apps/kexec-tools: update config files for new linux-4.3 kexec knobs | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Terra <gentoo.org> |
| Component: | [OLD] Core system | Assignee: | Gentoo's Team for Core System packages <base-system> |
| Status: | CONFIRMED --- | ||
| Severity: | enhancement | CC: | liaoyuan, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
New ebuild that supports KEXEC_FILE loading
New /etc/conf.d/kexec file New /etc/init.d/kexec init file Patch for existing kexec.init-2.0.4-r3 init file full kexec-tools patch for 2.0.4-r3 (bugfix) and 2.0.9-r3 (new ebuild) kexec.init-2.0.9-r3 |
||
|
Description
Terra
2016-02-07 01:21:04 UTC
Created attachment 424796 [details]
New ebuild that supports KEXEC_FILE loading
Created attachment 424798 [details]
New /etc/conf.d/kexec file
Created attachment 424800 [details]
New /etc/init.d/kexec init file
Created attachment 424802 [details, diff]
Patch for existing kexec.init-2.0.4-r3 init file
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 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 please post diffs rather than entire files so it's easy for us to evaluate/apply Created attachment 425086 [details, diff]
full kexec-tools patch for 2.0.4-r3 (bugfix) and 2.0.9-r3 (new ebuild)
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... (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. 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... :) 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. 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 ?
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 ? (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. |
