Use case is to create images using livemedia-creator where we wont be running on the target platform
Signed-off-by: Dennis Gilmore dennis@ausil.us --- anaconda | 4 ++++ pyanaconda/iutil.py | 3 +++ 2 files changed, 7 insertions(+)
diff --git a/anaconda b/anaconda index fc679c9..c37dd72 100755 --- a/anaconda +++ b/anaconda @@ -222,6 +222,7 @@ def parseOptions(argv=None, cmdline=None): op.add_option("--kickstart", dest="ksfile") op.add_option("--rescue", dest="rescue", action="store_true", default=False) op.add_option("--targetarch", "rpmarch", dest="targetArch", type="string") + op.add_option("--targetplatform", "platform", dest="targetPlatform", type="string")
op.add_option("-m", "--method", dest="method", default=None) op.add_option("--repo", dest="method", default=None) @@ -803,6 +804,9 @@ if __name__ == "__main__": if opts.targetArch: flags.targetarch = opts.targetArch
+ if opts.targetPlatform: + flags.platform = opts.targetPlatform + # set flags flags.dmraid = opts.dmraid flags.mpath = opts.mpath diff --git a/pyanaconda/iutil.py b/pyanaconda/iutil.py index ed6d098..aef4cc6 100644 --- a/pyanaconda/iutil.py +++ b/pyanaconda/iutil.py @@ -627,6 +627,9 @@ def getARMMachine(): if not isARM(): return 0
+ if flags.platform: + return flags.platform + armMachine = os.uname()[2].rpartition('.' )[2]
if armMachine.startswith('arm'):
On Mon, Jul 16, 2012 at 09:04:10AM -0500, Dennis Gilmore wrote:
Use case is to create images using livemedia-creator where we wont be running on the target platform
Signed-off-by: Dennis Gilmore dennis@ausil.us
anaconda | 4 ++++ pyanaconda/iutil.py | 3 +++ 2 files changed, 7 insertions(+)
diff --git a/anaconda b/anaconda index fc679c9..c37dd72 100755 --- a/anaconda +++ b/anaconda @@ -222,6 +222,7 @@ def parseOptions(argv=None, cmdline=None): op.add_option("--kickstart", dest="ksfile") op.add_option("--rescue", dest="rescue", action="store_true", default=False) op.add_option("--targetarch", "rpmarch", dest="targetArch", type="string")
- op.add_option("--targetplatform", "platform", dest="targetPlatform", type="string")
Ideally this would be generic enough that it would apply to any arch. But that's going to be fairly difficult given how tightly Anaconda is integrated with the system it is running on. So for now I guess this is ok, but I'd like so see the option renamed to --armplatform since it is specific to arm.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Mon, 23 Jul 2012 13:35:24 -0700 "Brian C. Lane" bcl@redhat.com escribió:
On Mon, Jul 16, 2012 at 09:04:10AM -0500, Dennis Gilmore wrote:
Use case is to create images using livemedia-creator where we wont be running on the target platform
Signed-off-by: Dennis Gilmore dennis@ausil.us
anaconda | 4 ++++ pyanaconda/iutil.py | 3 +++ 2 files changed, 7 insertions(+)
diff --git a/anaconda b/anaconda index fc679c9..c37dd72 100755 --- a/anaconda +++ b/anaconda @@ -222,6 +222,7 @@ def parseOptions(argv=None, cmdline=None): op.add_option("--kickstart", dest="ksfile") op.add_option("--rescue", dest="rescue", action="store_true", default=False) op.add_option("--targetarch", "rpmarch", dest="targetArch", type="string")
- op.add_option("--targetplatform", "platform",
dest="targetPlatform", type="string")
Ideally this would be generic enough that it would apply to any arch. But that's going to be fairly difficult given how tightly Anaconda is integrated with the system it is running on. So for now I guess this is ok, but I'd like so see the option renamed to --armplatform since it is specific to arm.
right the way its implemented it could be used to overwrite things like making a uefi only livecd on a non uefi system or for different ppc system types. I do only see it being used initially for ARM but its not implemented so that its the only way to use it. id rather not rename it but if you insist that is how its done ill do it.
Dennis
On Wed, Aug 01, 2012 at 04:15:14AM -0500, Dennis Gilmore wrote:
El Mon, 23 Jul 2012 13:35:24 -0700 "Brian C. Lane" bcl@redhat.com escribió:
On Mon, Jul 16, 2012 at 09:04:10AM -0500, Dennis Gilmore wrote:
Use case is to create images using livemedia-creator where we wont be running on the target platform
Signed-off-by: Dennis Gilmore dennis@ausil.us
anaconda | 4 ++++ pyanaconda/iutil.py | 3 +++ 2 files changed, 7 insertions(+)
diff --git a/anaconda b/anaconda index fc679c9..c37dd72 100755 --- a/anaconda +++ b/anaconda @@ -222,6 +222,7 @@ def parseOptions(argv=None, cmdline=None): op.add_option("--kickstart", dest="ksfile") op.add_option("--rescue", dest="rescue", action="store_true", default=False) op.add_option("--targetarch", "rpmarch", dest="targetArch", type="string")
- op.add_option("--targetplatform", "platform",
dest="targetPlatform", type="string")
Ideally this would be generic enough that it would apply to any arch. But that's going to be fairly difficult given how tightly Anaconda is integrated with the system it is running on. So for now I guess this is ok, but I'd like so see the option renamed to --armplatform since it is specific to arm.
right the way its implemented it could be used to overwrite things like making a uefi only livecd on a non uefi system or for different ppc system types. I do only see it being used initially for ARM but its not implemented so that its the only way to use it. id rather not rename it but if you insist that is how its done ill do it.
That was my point. We have a variety of ways we interact with the platform so for now it is better to make it clear this is just for ARM.
On 08/02/2012 04:38 PM, Brian C. Lane wrote:
On Wed, Aug 01, 2012 at 04:15:14AM -0500, Dennis Gilmore wrote:
El Mon, 23 Jul 2012 13:35:24 -0700 "Brian C. Lane" bcl@redhat.com escribió:
On Mon, Jul 16, 2012 at 09:04:10AM -0500, Dennis Gilmore wrote:
Use case is to create images using livemedia-creator where we wont be running on the target platform
Signed-off-by: Dennis Gilmore dennis@ausil.us
anaconda | 4 ++++ pyanaconda/iutil.py | 3 +++ 2 files changed, 7 insertions(+)
diff --git a/anaconda b/anaconda index fc679c9..c37dd72 100755 --- a/anaconda +++ b/anaconda @@ -222,6 +222,7 @@ def parseOptions(argv=None, cmdline=None): op.add_option("--kickstart", dest="ksfile") op.add_option("--rescue", dest="rescue", action="store_true", default=False) op.add_option("--targetarch", "rpmarch", dest="targetArch", type="string")
- op.add_option("--targetplatform", "platform",
dest="targetPlatform", type="string")
Ideally this would be generic enough that it would apply to any arch. But that's going to be fairly difficult given how tightly Anaconda is integrated with the system it is running on. So for now I guess this is ok, but I'd like so see the option renamed to --armplatform since it is specific to arm.
right the way its implemented it could be used to overwrite things like making a uefi only livecd on a non uefi system or for different ppc system types. I do only see it being used initially for ARM but its not implemented so that its the only way to use it. id rather not rename it but if you insist that is how its done ill do it.
That was my point. We have a variety of ways we interact with the platform so for now it is better to make it clear this is just for ARM.
Ok. I'm keen that we get at least the first 2.5 (2+the trivial kernel style fix from Dennis) ARM patches in that do the platform stuff for F18. I'd like to see the U-Boot stuff land as well, but the arm platform stuff is critical. Therefore, Brian, can you confirm that if Dennis changes that platform name to whatever you prefer and rebases tonight (his tomorrow - he's in AU right now) you can ACK/pull tomorrow?
Jon.
Jon Masters wrote:
On 08/02/2012 04:38 PM, Brian C. Lane wrote:
On Wed, Aug 01, 2012 at 04:15:14AM -0500, Dennis Gilmore wrote:
El Mon, 23 Jul 2012 13:35:24 -0700 "Brian C. Lane" bcl@redhat.com escribió:
On Mon, Jul 16, 2012 at 09:04:10AM -0500, Dennis Gilmore wrote:
Use case is to create images using livemedia-creator where we wont be running on the target platform
Signed-off-by: Dennis Gilmore dennis@ausil.us
anaconda | 4 ++++ pyanaconda/iutil.py | 3 +++ 2 files changed, 7 insertions(+)
diff --git a/anaconda b/anaconda index fc679c9..c37dd72 100755 --- a/anaconda +++ b/anaconda @@ -222,6 +222,7 @@ def parseOptions(argv=None, cmdline=None): op.add_option("--kickstart", dest="ksfile") op.add_option("--rescue", dest="rescue", action="store_true", default=False) op.add_option("--targetarch", "rpmarch", dest="targetArch", type="string")
- op.add_option("--targetplatform", "platform",
dest="targetPlatform", type="string")
Ideally this would be generic enough that it would apply to any arch. But that's going to be fairly difficult given how tightly Anaconda is integrated with the system it is running on. So for now I guess this is ok, but I'd like so see the option renamed to --armplatform since it is specific to arm.
right the way its implemented it could be used to overwrite things like making a uefi only livecd on a non uefi system or for different ppc system types. I do only see it being used initially for ARM but its not implemented so that its the only way to use it. id rather not rename it but if you insist that is how its done ill do it.
That was my point. We have a variety of ways we interact with the platform so for now it is better to make it clear this is just for ARM.
Ok. I'm keen that we get at least the first 2.5 (2+the trivial kernel style fix from Dennis) ARM patches in that do the platform stuff for F18. I'd like to see the U-Boot stuff land as well, but the arm platform stuff is critical. Therefore, Brian, can you confirm that if Dennis changes that platform name to whatever you prefer and rebases tonight (his tomorrow - he's in AU right now) you can ACK/pull tomorrow?
If we change the command line option, we also need to ensure the lorax patch is changed as well to match it.
https://www.redhat.com/archives/anaconda-devel-list/2012-July/msg00060.html
I will be happy to rebase this one, if needed. Please let me know.
Thank you,
d.marlin ========
Jon.
anaconda-patches mailing list anaconda-patches@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
On Thu, Aug 02, 2012 at 04:42:21PM -0400, Jon Masters wrote:
Ok. I'm keen that we get at least the first 2.5 (2+the trivial kernel style fix from Dennis) ARM patches in that do the platform stuff for F18. I'd like to see the U-Boot stuff land as well, but the arm platform stuff is critical. Therefore, Brian, can you confirm that if Dennis changes that platform name to whatever you prefer and rebases tonight (his tomorrow - he's in AU right now) you can ACK/pull tomorrow?
Not until I see them. At this point I haven't seen any of my concerns being addressed. I really would like to see the code in the UBOOT class driven by something easier to maintain than a stack of if/then statements.
On 08/02/2012 05:43 PM, Brian C. Lane wrote:
On Thu, Aug 02, 2012 at 04:42:21PM -0400, Jon Masters wrote:
Ok. I'm keen that we get at least the first 2.5 (2+the trivial kernel style fix from Dennis) ARM patches in that do the platform stuff for F18. I'd like to see the U-Boot stuff land as well, but the arm platform stuff is critical. Therefore, Brian, can you confirm that if Dennis changes that platform name to whatever you prefer and rebases tonight (his tomorrow - he's in AU right now) you can ACK/pull tomorrow?
Not until I see them. At this point I haven't seen any of my concerns being addressed. I really would like to see the code in the UBOOT class driven by something easier to maintain than a stack of if/then statements.
Let me rephase. I'm keen to separate the minimal bits needed for platform/kickstart from the U-Boot bits, in order to advance this more quickly. If the platform naming is taken care of, what other blockers are there to pulling those bits in while the U-Boot stuff is worked out? They are better together, but with just the platform bits it becomes possible to kickstart systems, which is an advance.
Jon.
On Thu, Aug 02, 2012 at 06:05:45PM -0400, Jon Masters wrote:
Let me rephase. I'm keen to separate the minimal bits needed for platform/kickstart from the U-Boot bits, in order to advance this more quickly. If the platform naming is taken care of, what other blockers are there to pulling those bits in while the U-Boot stuff is worked out? They are better together, but with just the platform bits it becomes possible to kickstart systems, which is an advance.
That's fine, as long as they can stand on their own.
Brian C. Lane wrote:
On Thu, Aug 02, 2012 at 06:05:45PM -0400, Jon Masters wrote:
Let me rephase. I'm keen to separate the minimal bits needed for platform/kickstart from the U-Boot bits, in order to advance this more quickly. If the platform naming is taken care of, what other blockers are there to pulling those bits in while the U-Boot stuff is worked out? They are better together, but with just the platform bits it becomes possible to kickstart systems, which is an advance.
That's fine, as long as they can stand on their own.
They can. I am running these patches applied to the latest F17 versions of anaconda and lorax now in the Huntsville build farm. I have successfully created disk images with livemedia-creator, install trees using lorax, and performed anaconda kickstart installs on highbank and mvebu systems.
d.marlin ========
anaconda-patches mailing list anaconda-patches@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/anaconda-patches
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El Fri, 3 Aug 2012 10:52:03 -0700 "Brian C. Lane" bcl@redhat.com escribió:
On Thu, Aug 02, 2012 at 06:05:45PM -0400, Jon Masters wrote:
Let me rephase. I'm keen to separate the minimal bits needed for platform/kickstart from the U-Boot bits, in order to advance this more quickly. If the platform naming is taken care of, what other blockers are there to pulling those bits in while the U-Boot stuff is worked out? They are better together, but with just the platform bits it becomes possible to kickstart systems, which is an advance.
That's fine, as long as they can stand on their own.
They can only if you use kickstart, you can not do an interactive install.
Dennis
anaconda-patches@lists.fedorahosted.org
-
Brian C. Lane -
d.marlin -
Dennis Gilmore -
Jon Masters