On Wed, 29 Sep 2004 16:27:01 +0200, Peter Oberparleiter
[EMAIL PROTECTED] wrote:
Michael MacIsaac [EMAIL PROTECTED] wrote:
Is there any way to extract/dump the parameters in
/boot/zipl/bootmap?
Yes, there is, but the question is: why would you want to? The bootmap
format is only used
Yes, there is, but the question is: why would you want to?
Because I forgot about:
cat /proc/cmdline
Yes, this would be better. Thanks.
-Mike MacIsaac, IBM [EMAIL PROTECTED] (845) 433-7061
--
For LINUX-390 subscribe /
Post, Mark K [EMAIL PROTECTED] wrote:
Which leads to the question, if two sources of information conflict
in some way, which one wins? The first one? The last one?
Something else? Can we have some specific examples that can be put
into a HOWTO? :)
The answer to your first question would
Michael MacIsaac [EMAIL PROTECTED] wrote:
Is there any way to extract/dump the parameters in
/boot/zipl/bootmap?
Yes, there is, but the question is: why would you want to?
It might be useful for configuration management tools like Intelligent
Orchestrator or Tivoli Provisioning Mgr to be
David Boyes [EMAIL PROTECTED] wrote:
Seems a bit risky -- if that's the only way to do this, and it generates
an actual update, it might be useful to provide an option that just
interprets the current parameter set list and prints it out without the
update. Something to put in the hopper for
Seems reasonable (-t0, anyone..?:). I'll consider including a
respective
parameter in a future version of zipl.
How about -n (do all the validation you're going to do anyway, but skip
actually doing anything, a la make)? Offhand, dunno whether -n is
already taken for something else, though.
On Thu, 30 Sep 2004 15:17:48 +0200, Peter Oberparleiter
[EMAIL PROTECTED] wrote:
I think the most reasonable solution for scenarios where configuration
management tools are used would be to impose a policy, only to use
configurations supplied in the zipl.conf file.
That's theory only. Even
in there and will go into effect on
a reboot.
Mark Post
-Original Message-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of David
Boyes
Sent: Thursday, September 30, 2004 9:56 AM
To: [EMAIL PROTECTED]
Subject: Re: VM Shutdown
-snip-
Would it make sense to force updates into zipl.conf
David Boyes [EMAIL PROTECTED] wrote:
How about -n (do all the validation you're going to do anyway, but skip
actually doing anything, a la make)? Offhand, dunno whether -n is
already taken for something else, though.
'-n'is already taken, I'm rather thinking of --dry-run like in the 'patch'
On Thu, 30 Sep 2004 18:03:57 +0200, Peter Oberparleiter
[EMAIL PROTECTED] wrote:
'-n'is already taken, I'm rather thinking of --dry-run like in the 'patch'
tool.
Maybe useful too, but different from what I was asking about ;-)
I thought -t 2 was the --dry-run from Boeblingen?
--
Rob van der
Rob van der Heij [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
I think the most reasonable solution for scenarios where configuration
management tools are used would be to impose a policy, only to use
configurations supplied in the zipl.conf file.
That's theory only. Even when you
Rob van der Heij [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
'-n'is already taken, I'm rather thinking of --dry-run like in the
'patch'
tool.
Maybe useful too, but different from what I was asking about ;-)
Patience.. :)
I thought -t 2 was the --dry-run from Boeblingen?
Actually
-
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of Peter
Oberparleiter
Sent: Thursday, September 30, 2004 6:44 AM
To: [EMAIL PROTECTED]
Subject: Re: VM Shutdown
Post, Mark K [EMAIL PROTECTED] wrote:
Which leads to the question, if two sources of information conflict in
some way, which
On Thu, 30 Sep 2004 18:31:00 +0200, Peter Oberparleiter
[EMAIL PROTECTED] wrote:
Trust zipl :) If it exits with a return code of 0, it should be safe
to assume that the IPL record was written according to the provided
configuration. If you're not sure about a new configuration, use the
I suppose it should not be that hard to include the relevant
information in the bootmap - say after the first word of 0 (or
whatever signals the loader the end of the list). And zipl -q could
retrieve that by reading the bootmap from the IPL records?
I agree that putting the information
'-n'is already taken, I'm rather thinking of --dry-run like
in the 'patch'
tool.
Drat. --dry-run is OK, though (if a bit verbose). C'est la vie.
From my point of view, I'd say yes. I would suggest using the command
line parameters only to prepare a new or broken installation for IPL.
If
On Thursday, 09/30/2004 at 02:42 AST, David Boyes [EMAIL PROTECTED]
wrote:
Sounds like the multiboot gadget needs to become the unmodifiable
default. 8-)
Cha-ching!
Royalty payment of $10 on copyrighted phrase unmodifiable default is now
due. Terms: Net 30, 10%.
Chuckie
wasn't the actual copyrighted phrase unchangeable default? Looks like
Chuckie loses out again...
Regards,
Miguel Diaz
Staff Software Engineer
TCP/IP for z/VM
Linux on 390 Port [EMAIL PROTECTED] wrote on 09/30/2004 02:55:40
PM:
On Thursday, 09/30/2004 at 02:42 AST, David Boyes
[EMAIL
On Thu, 2004-09-30 at 14:01, Miguel Diaz wrote:
wasn't the actual copyrighted phrase unchangeable default? Looks like
Chuckie loses out again...
Unmodifiable default is clearly a Derivative Work of unchangeable
default. Therefore, David owes Chuckyten TRILLION DOLLARS! And a
pony.
This
Ahh...but there are plenty of instances of prior art
(http://bumppo.net/lists/macperl/1999/04/msg00189.html for one)
Regards,
Miguel Diaz
Staff Software Engineer
TCP/IP for z/VM
Linux on 390 Port [EMAIL PROTECTED] wrote on 09/30/2004 03:16:23
PM:
On Thu, 2004-09-30 at 14:01, Miguel Diaz
On Thu, 2004-09-30 at 14:21, Miguel Diaz wrote:
Ahh...but there are plenty of instances of prior art
(http://bumppo.net/lists/macperl/1999/04/msg00189.html for one)
Bumppo.net owes Chuckie...TEN TRILLION DOLLARS! And a pony.
SCO+DB
Sounds like the multiboot gadget needs to become the unmodifiable
default. 8-)
Cha-ching!
Royalty payment of $10 on copyrighted phrase unmodifiable
default is now
due. Terms: Net 30, 10%.
Chuckie
It's Univac Data Systems intellectual property, which you have *clearly*
released into
And a
pony.
If there is a pony involved here, there is undoubtedly a container of
something unpleasant nearby
It is indeed a container of that which promotes growth, and it is very
strong.
-- db
--
For LINUX-390
3:27 PM
To: [EMAIL PROTECTED]
Subject: [Possible Spam] Re: VM Shutdown
And a
pony.
If there is a pony involved here, there is undoubtedly a container of
something unpleasant nearby
It is indeed a container of that which promotes growth, and it is very
strong.
-- db
habetur, quomodo habenda est
Rob van der Heij [EMAIL PROTECTED]
Sent by: Linux on 390 Port [EMAIL PROTECTED]
28/09/2004 08:06 PM
Please respond to Rob van der Heij
To: [EMAIL PROTECTED]
cc:
Subject:Re: VM Shutdown
On Tue, 28 Sep 2004 08:05:21 -0600
Rob van der Heij [EMAIL PROTECTED] wrote:
The parmfile is generated by zipl, so any changes to the kernel
command line must be in the /etc/zipl.conf and then run zipl before
reboot.
Note that starting with version 1.2.0, zipl no longer modifies the
parmfile.
Instead, all sources for kernel
which is then written to the bootmap file
Is there any way to extract/dump the parameters in /boot/zipl/bootmap?
-Mike MacIsaac, IBM [EMAIL PROTECTED] (845) 433-7061
--
For LINUX-390 subscribe / signoff / archive access
PROTECTED] On Behalf Of Peter
1 Oberparleiter
Sent: Wednesday, September 29, 2004 5:09 AM
To: [EMAIL PROTECTED]
Subject: Re: VM Shutdown
Rob van der Heij [EMAIL PROTECTED] wrote:
The parmfile is generated by zipl, so any changes to the kernel
command line must be in the /etc/zipl.conf and then run
]
Subject: Re: VM Shutdown
which is then written to the bootmap file
Is there any way to extract/dump the parameters in /boot/zipl/bootmap?
-Mike MacIsaac, IBM [EMAIL PROTECTED] (845) 433-7061
--
For LINUX-390 subscribe
Michael MacIsaac [EMAIL PROTECTED] wrote:
Is there any way to extract/dump the parameters in
/boot/zipl/bootmap?
Yes, there is, but the question is: why would you want to? The bootmap
format is only used internally by zipl, i.e. it can change without
notice, therefore you shouldn't rely on its
Do you add this to the file /boot/zipl/parmfile and the run the zipl command and
reboot.
-Cameron Seader
-Original Message-
From: Malcolm Beattie [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 15, 2004 15:12
To: [EMAIL PROTECTED]
Subject: Re: VM Shutdown
Post, Mark K writes
On Tue, 28 Sep 2004 08:05:21 -0600, Seader, Cameron
[EMAIL PROTECTED] wrote:
Do you add this to the file /boot/zipl/parmfile and the run the zipl command and
reboot.
The parmfile is generated by zipl, so any changes to the kernel
command line must be in the /etc/zipl.conf and then run zipl
, September 28, 2004 2:06 PM
To: [EMAIL PROTECTED]
Subject: Re: VM Shutdown
On Tue, 28 Sep 2004 08:05:21 -0600, Seader, Cameron [EMAIL PROTECTED]
wrote:
Do you add this to the file /boot/zipl/parmfile and the run the zipl
command and reboot.
The parmfile is generated by zipl, so any changes
Rich Smrcina wrote:
I get the desired effect and the nice message without the vmpoff as
well.
Right. See http://www.mail-archive.com/[EMAIL PROTECTED]/msg20673.html
The vmpoff only applies when you issue 'shutdown -h' yourself.
Contrasting the recommendation from Malcolm, I do *not* use vmpoff=
On Wednesday, 09/15/2004 at 10:12 CET, Malcolm Beattie
[EMAIL PROTECTED] wrote:
Change that -r (meaning reboot) into -h (meaning halt)
so that the SIGNAL SHUTDOWN magic described elsewhere in this
thread behaves as expected. For cleanliness, it's also good to
include vmpoff=LOGOFF into the
What is the easiest way to setup the Linux guests so that when VM
shutsdown, the Linux guests under VM all shutdown cleanly also?
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED]
:[EMAIL PROTECTED] On Behalf Of Bob
Sent: Wednesday, September 15, 2004 9:17 AM
To: [EMAIL PROTECTED]
Subject: VM Shutdown
What is the easiest way to setup the Linux guests so that when VM shutsdown,
the Linux guests under VM all shutdown cleanly also
thanks, I have done that to all the systems, just haven't tried it yet
On Wed, 15 Sep 2004 11:35:48 -0400, Post, Mark K [EMAIL PROTECTED] wrote:
Depending on what version of z/VM and Linux you're running, updating
/etc/inittab to have something like this:
# What to do at the Three Finger
z/VM 4.3 and higher have a feature called Signal Shutdown, which will
send a Linux guest a shutdown signal when a command is issued or when
z/VM itself is shutdown. For SLES8, you need at least Service Pack 2 (I
think). Changes to /etc/inittab are also required.
On Wed, 2004-09-15 at 08:17, Bob
Bob wrote:
thanks, I have done that to all the systems, just haven't tried it
yet
You also need to SET SIGNAL SHUTDOWN to enable the CP option that makes
the FORCE (either through command or as part of shutdown) send the
signal to all guests that have enabled it and wait for them to go down
Post, Mark K writes:
Depending on what version of z/VM and Linux you're running, updating
/etc/inittab to have something like this:
# What to do at the Three Finger Salute.
ca::ctrlaltdel:/sbin/shutdown -t5 -r now
Change that -r (meaning reboot) into -h (meaning halt)
so that the SIGNAL
I get the desired effect and the nice message without the vmpoff as
well.
On Wed, 2004-09-15 at 16:12, Malcolm Beattie wrote:
Post, Mark K writes:
Depending on what version of z/VM and Linux you're running, updating
/etc/inittab to have something like this:
# What to do at the Three Finger
On Wed, Sep 15, 2004 at 09:17:10AM -0400, Bob wrote:
What is the easiest way to setup the Linux guests so that when VM
shutsdown, the Linux guests under VM all shutdown cleanly also?
Use the SYSVINIT code I announced. That's
exactly the kind of thing it's intended to do.
It already has a set of
On Wed, 2004-09-15 at 18:06, David Boyes wrote:
On Wed, Sep 15, 2004 at 09:17:10AM -0400, Bob wrote:
What is the easiest way to setup the Linux guests so that when VM
shutsdown, the Linux guests under VM all shutdown cleanly also?
Use the SYSVINIT code I announced. That's
exactly the kind
44 matches
Mail list logo
