Test
by Vratislav Podzimek
Does it work now?
--
Vratislav Podzimek
Anaconda Rider | RHCE | Red Hat, Inc. | Brno - Czech Republic
9 years, 1 month
[PATCH] Use the correct format for IPMI messages.
by Chris Lumens
Related: rhbz#782019
Resolves: rhbz#1201174
---
pyanaconda/iutil.py | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/pyanaconda/iutil.py b/pyanaconda/iutil.py
index f096619..6798c41 100644
--- a/pyanaconda/iutil.py
+++ b/pyanaconda/iutil.py
@@ -1204,10 +1204,11 @@ def ipmi_report(event):
# EVM revision - always 0x4
# Sensor type - always 0x1F for Base OS Boot/Installation Status
- # Sensor num - passed in event
- # Event dir & type - always 0x0 for anaconda's purposes
- # Event data 1, 2, 3 - 0x0 for now
- eintr_retry_call(os.write, fd, "0x4 0x1F %#x 0x0 0x0 0x0 0x0\n" % event)
+ # Sensor num - always 0x0 for us
+ # Event dir & type - always 0x6f for us
+ # Event data 1 - the event code passed in
+ # Event data 2 & 3 - always 0x0 for us
+ eintr_retry_call(os.write, fd, "0x4 0x1F 0x0 0x6f %#x 0x0 0x0\n" % event)
eintr_retry_call(os.close, fd)
execWithCapture("ipmitool", ["sel", "add", path])
--
2.2.2
9 years, 1 month
New: [rhinstaller/lorax/pulls/8 master] Add ability for external templates to graft content into boot.iso
by dashea
I originally added --add-template to support doing something similar
to pungi, which injects content into the system to be used by default.
However, this causes the content to be part of the squashfs, which
means PXE installations have to download significantly more data that
they may not need (if they actually want to pull the tree data from
the network, which is not an unusual case).
What I actually need is to be able to modify *both* the runtime image
and the arch-specific content. For the runtime, I need to change
/usr/share/anaconda/interactive-defaults.ks to point to the new
content. (Although, potentially we could patch Anaconda itself to
auto-detect an ostree repository configured in disk image, similar to
what it does for yum repositories)
For the arch-specfic image, I want to drop my content into the ISO
root.
So this patch adds --add-arch-template and --add-arch-template-var
in order to do the latter, while preserving the --add-template
to affect the runtime image.
Further, the templates will automatically graft in a directory named
"iso-graft/" from the working directory (if it exists).
(I suggest that external templates create a subdirectory named
"content" to avoid clashes with any future lorax work)
Thus, this will be used by the Atomic Host lorax templates to inject
content/repo, but could be used by e.g. pungi to add content/rpms as
well.
I tried to avoid code deduplication by creating a new template for the
product.img bits and this, but that broke because the parent boot.iso
code needs access to the `${imggraft}` variable. I think a real fix
here would involve turning the product.img, content/, *and* boot.iso
into a new template.
--
To view this pull request on github, visit https://github.com/rhinstaller/lorax/pull/8
9 years, 1 month
New: [rhinstaller/lorax/pulls/11 f22-branch] Add ability for external templates to graft content into boot.iso
by dashea
I originally added --add-template to support doing something similar
to pungi, which injects content into the system to be used by default.
However, this causes the content to be part of the squashfs, which
means PXE installations have to download significantly more data that
they may not need (if they actually want to pull the tree data from
the network, which is not an unusual case).
What I actually need is to be able to modify *both* the runtime image
and the arch-specific content. For the runtime, I need to change
/usr/share/anaconda/interactive-defaults.ks to point to the new
content. (Although, potentially we could patch Anaconda itself to
auto-detect an ostree repository configured in disk image, similar to
what it does for yum repositories)
For the arch-specfic image, I want to drop my content into the ISO
root.
So this patch adds --add-arch-template and --add-arch-template-var
in order to do the latter, while preserving the --add-template
to affect the runtime image.
Further, the templates will automatically graft in a directory named
"iso-graft/" from the working directory (if it exists).
(I suggest that external templates create a subdirectory named
"content" to avoid clashes with any future lorax work)
Thus, this will be used by the Atomic Host lorax templates to inject
content/repo, but could be used by e.g. pungi to add content/rpms as
well.
I tried to avoid code deduplication by creating a new template for the
product.img bits and this, but that broke because the parent boot.iso
code needs access to the `${imggraft}` variable. I think a real fix
here would involve turning the product.img, content/, *and* boot.iso
into a new template.
Conflicts:
src/sbin/lorax
--
To view this pull request on github, visit https://github.com/rhinstaller/lorax/pull/11
9 years, 1 month