Re: Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
> David > I would think you would have to modify the inittab so that a signal sent > would emulate the key sequence RH is asking for, I recall doing that some > time back for something else I was working on. You're probably thinking about the cntrl-alt-del hack that SIGNAL SHUTDOWN uses. That works because the kernel/init map the signal. They're trying to get an alternate console, and a) the console driver for the HMC/3215/3270 doesn't support those, and b) a 3270 can't generate that sequence -- there's no terminal event for it in the base 3270 architecture. You'd have to modify the terminal emulator or the console driver to accept some magic sequence to emulate it (like the VM telnet command does with the logical not (^) char plus a char. You could probably modify the console driver to parse PA2 as "switch console".. .hmm. Would depend on the model of 3270, I guess; the data entry assist feature in the 3x74s had a session switch keystroke (IIRC if you were in SNA mode), but that's pretty arcane and not implemented in most 3270 emulators. It also might be worth looking into whether the IUCV console initialization could move earlier. That would give (with the help of a terminal server appliance guest) a true ASCII console session much earlier on, and I think the "usual" process for multiple consoles could be convinced to work much earlier (X3.64/VTxxx terminals do have PF key sequences that could be defined as the switch code for virtual terminals). Re: disks. This seems to be a perennial problem in the installers; it keeps popping back up release after release. It'd be nice if the installer just overwrote the designated disks as you describe (you told it explicitly what to nuke, so your gun your foot), and then proceeded to do the regular fdasd/dasdfmt combination (bonus if you provide an option to flash a preformatted disk onto the new one if your hw can do it and just fix the UUID). -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
FWIW and if I've understood the original problem as being Kickstart was
not formatting disks even though you specify --clearpart
I had a similar problem to this in the past.
The issue was the volumes being used where not wiped so still contained
formatted data which kickstart interpreted as not needing to be formatted.
Our solution was to reformat only the first few cylinders of the volume
before the server was kickstarted, which forced kickstart to reformat the
volume correctly.
This was a pain and we had opened a ticket with Redhat on it back in RHEL
4 days.
I am wondering if that maybe somehow that change has gotten lost in 6.4?
Have you tried CPFMTXA or even a CMS Format on the volume to wipe it out
then tried to kickstart it?
David
I would think you would have to modify the inittab so that a signal sent
would emulate the key sequence RH is asking for,
I recall doing that some time back for something else I was working on.
Sandra
From: "Collinson.Shannon"
To: LINUX-390@VM.MARIST.EDU
Date: 07/16/2013 04:19 PM
Subject:Re: Any idea how to get into RedHat "PDB" mode on a
kickstart through a TN3270 console in z/VM?
Sent by:Linux on 390 Port
I'm actually using both of those (RUNKS=1 and cmdline) already. And I
think we know "where" in the code there's a problem--the clearpart
--initlabel --all/zerombr is not getting run against all disks, just disks
mentioned later in the kickstart. In 6.2, we could use it to wipe out the
header info from every disk the linux OS could see, but in RHEL 6.4, it
misses what I call "extra disks"--minidisks we use to have a single
kickstart file for multiple-sized linux servers that still have the same
base requirements. We build out a default of two minidisks in volume
group "datavg" for every server, but since that only adds up to 20G, we
wanted to be able to have a random number of "additional disks" that'd get
added into the datavg in a kickstart %post script for servers whose
application code will need more than 20G. Works great on a brand-new
carved-straight-from-z/VM server, but when we're rebuilding a server
that's already been built once, since the extra disks aren't wiped clean,
linux senses that "datavg" already exists when the kickstart tries to
create it. Under RHEL 6.2, since everything was wiped, a rebuild was just
as easy as a new build. We can get around it by recreating (deleting and
re-adding) the extra minidisks, or by running a %pre "dasdfmt" against any
extra disk sensed (which, since it single-threads how I coded it, can take
way longer than the z/VM minidisk recreate), but that won't help RedHat
figure out the bug in their code.
That's just a little background, but I figured it might shed some light on
what we're doing. I've tried the "enter/enter" thing mentioned below and
in the RHEL note, but it doesn't seem to take, which makes me wonder if
the real problem isn't that the connection to the linux bootstrap-OS is
gone when it spits out the error. I seem to get a prompt that expects
only a certain handful of responses, but I haven't figured out how to
enter them either:
Storage Activation Failed
An error was encountered while activating your storage
configuration.
vgcreate failed for datavg: 15:46:23,603 ERROR : A volume
group called datavg already exists.
('custom', ['_File Bug', '_Exit installer'])
If I enter "custom" or "_File Bug" or "_Exit installer", nothing happens.
Really, when the error pops up, I don't seem to have any recourse from the
z/VM guest console except logging off or entering "#CP I CMS" to restart
the process...
FYI--I've attached the below email to the redhat ticket. I'm hoping some
of the stuff I didn't understand in here might spark ideas in the RedHat
support staff. Thanks to both you (Steffen) and David, as well as Rick
Troth (who sent a straight-up) email for your responses so far. And if
you think of anything else, please let me know!
Shannon
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
Steffen Maier
Sent: Tuesday, July 16, 2013 1:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Any idea how to get into RedHat "PDB" mode on a kickstart
through a TN3270 console in z/VM?
On 07/16/2013 05:25 PM, David Boyes wrote:
>
>> We're trying to research an issue with our kickstarting that cropped
>> up in
>> RHEL6.4 (worked perfectly in RHEL6.2). RedHat support has asked us
>> to wait till the kickstart fails then issue "CNTL+ALT+F1" to get into
>> "pdb" mode so they can debug the anaconda stuff, but since we boot in
>> z/VM, the terminal doesn't appear to translate those keys
>> correctly--at least, I issue them and nothing happens.
>
> Call RH back and insist on talking to someone who can understand "This
> is not an Intel system. Those keys don't exist on System z".
>
>> Does anyone know how to send those to the host operating system
>> through a t
Re: Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
I'm actually using both of those (RUNKS=1 and cmdline) already. And I think we
know "where" in the code there's a problem--the clearpart --initlabel
--all/zerombr is not getting run against all disks, just disks mentioned later
in the kickstart. In 6.2, we could use it to wipe out the header info from
every disk the linux OS could see, but in RHEL 6.4, it misses what I call
"extra disks"--minidisks we use to have a single kickstart file for
multiple-sized linux servers that still have the same base requirements. We
build out a default of two minidisks in volume group "datavg" for every server,
but since that only adds up to 20G, we wanted to be able to have a random
number of "additional disks" that'd get added into the datavg in a kickstart
%post script for servers whose application code will need more than 20G. Works
great on a brand-new carved-straight-from-z/VM server, but when we're
rebuilding a server that's already been built once, since the extra disks
aren't wiped clean, linux senses that "datavg" already exists when the
kickstart tries to create it. Under RHEL 6.2, since everything was wiped, a
rebuild was just as easy as a new build. We can get around it by recreating
(deleting and re-adding) the extra minidisks, or by running a %pre "dasdfmt"
against any extra disk sensed (which, since it single-threads how I coded it,
can take way longer than the z/VM minidisk recreate), but that won't help
RedHat figure out the bug in their code.
That's just a little background, but I figured it might shed some light on what
we're doing. I've tried the "enter/enter" thing mentioned below and in the
RHEL note, but it doesn't seem to take, which makes me wonder if the real
problem isn't that the connection to the linux bootstrap-OS is gone when it
spits out the error. I seem to get a prompt that expects only a certain
handful of responses, but I haven't figured out how to enter them either:
Storage Activation Failed
An error was encountered while activating your storage configuration.
vgcreate failed for datavg: 15:46:23,603 ERROR : A volume group
called datavg already exists.
('custom', ['_File Bug', '_Exit installer'])
If I enter "custom" or "_File Bug" or "_Exit installer", nothing happens.
Really, when the error pops up, I don't seem to have any recourse from the z/VM
guest console except logging off or entering "#CP I CMS" to restart the
process...
FYI--I've attached the below email to the redhat ticket. I'm hoping some of
the stuff I didn't understand in here might spark ideas in the RedHat support
staff. Thanks to both you (Steffen) and David, as well as Rick Troth (who sent
a straight-up) email for your responses so far. And if you think of anything
else, please let me know!
Shannon
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Steffen
Maier
Sent: Tuesday, July 16, 2013 1:23 PM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Any idea how to get into RedHat "PDB" mode on a kickstart through
a TN3270 console in z/VM?
On 07/16/2013 05:25 PM, David Boyes wrote:
>
>> We're trying to research an issue with our kickstarting that cropped
>> up in
>> RHEL6.4 (worked perfectly in RHEL6.2). RedHat support has asked us
>> to wait till the kickstart fails then issue "CNTL+ALT+F1" to get into
>> "pdb" mode so they can debug the anaconda stuff, but since we boot in
>> z/VM, the terminal doesn't appear to translate those keys
>> correctly--at least, I issue them and nothing happens.
>
> Call RH back and insist on talking to someone who can understand "This
> is not an Intel system. Those keys don't exist on System z".
>
>> Does anyone know how to send those to the host operating system
>> through a tn3270e console? Or know of a different way that we could
>> get an ascii-based terminal for the automated kickstart if needed?
>> When I ssh into the guest at the failure time, I can hop on as root
>> but I'm not "breaking into" the install process--I can't enter
>> anything that'd change the flow of the install.
>>
>> Really hoping someone on this forum might have an idea, since IBM
>> won't respond (not a "zVM issue", apparently, that their console
>> doesn't work) and RedHat doesn't seem to know...
>
> The only way you could get an ASCII console that early in the process
> would be from the HMC, and it's still not going to help you.
>
> Try adding the "cmdline" option to the kickstart parm line. That will
> take you through the install line by line, which should help you
> findthe problem.
>
> If this is 6.4, there are known bugs in kickstart. Have them search
> for "kickstart RHEL6.4" in their issue tracker.
cmdline will only allow you to roughly determine the point in the installation
process but might make debugging the anaconda python code (pdb is the
integrated Python DeBugger) harder or even impossible.
Also, you typically need RUNKS=1 along with cmdline (which is mutually
e
Re: Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
On 07/16/2013 05:25 PM, David Boyes wrote: We're trying to research an issue with our kickstarting that cropped up in RHEL6.4 (worked perfectly in RHEL6.2). RedHat support has asked us to wait till the kickstart fails then issue "CNTL+ALT+F1" to get into "pdb" mode so they can debug the anaconda stuff, but since we boot in z/VM, the terminal doesn't appear to translate those keys correctly--at least, I issue them and nothing happens. Call RH back and insist on talking to someone who can understand "This is not an Intel system. Those keys don't exist on System z". Does anyone know how to send those to the host operating system through a tn3270e console? Or know of a different way that we could get an ascii-based terminal for the automated kickstart if needed? When I ssh into the guest at the failure time, I can hop on as root but I'm not "breaking into" the install process--I can't enter anything that'd change the flow of the install. Really hoping someone on this forum might have an idea, since IBM won't respond (not a "zVM issue", apparently, that their console doesn't work) and RedHat doesn't seem to know... The only way you could get an ASCII console that early in the process would be from the HMC, and it's still not going to help you. Try adding the "cmdline" option to the kickstart parm line. That will take you through the install line by line, which should help you findthe problem. If this is 6.4, there are known bugs in kickstart. Have them search for "kickstart RHEL6.4" in their issue tracker. cmdline will only allow you to roughly determine the point in the installation process but might make debugging the anaconda python code (pdb is the integrated Python DeBugger) harder or even impossible. Also, you typically need RUNKS=1 along with cmdline (which is mutually exclusive with interactive TUI or GUI installation). https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-parmfiles-Kickstart_parameters.html Since System z does not have the typical multiple x86 VGA Linux virtual terminals (VT), some features are packed into the ssh session or the Linux console and other features (such as the installer text logs) cannot be viewed directly (but indirectly through ssh as root and looking at the files in /tmp). IIRC, the PDB for anaconda pops up in the ssh session you made as user "install" when moving from install phase 1 (linuxrc) to 2 (loader). That's basically the stdin/stdout on System z (as opposed to VT 1) for the anaconda process and thus the python interpreter with integrated pdb. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-s390-Phase_1.html [end of section] https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-Installation_Phase_2-s390.html https://git.fedorahosted.org/cgit/anaconda.git/commit/?h=rhel6-branch&id=5df5401f9d35a2da441a92372b7c3e36c2ebd386 There should also be some tools in pykickstart to (syntax) check your kickstart file, in case you suspect something wrong in the unattended installation answer file. This won't help if you suspect an anaconda code bug. For the sake of completeness even though it might not help with the issue at hand: During the RHEL installation, the Linux console sits there waiting for a linefeed to be entered. On doing so, it'll spawn a root shell (which, in contrast to ssh login(s) as root, even works if the network to the guest OS is down). The (default) Linux console is the 3270 terminal under z/VM or the HMC operating system messages panel on the HMC for LPAR. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-s390-Phase_1.html#ch-s390-Phase_1-terminals -- Mit freundlichen Grüßen / Kind regards Steffen Maier Linux on System z Development IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Re: Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
<><><><><>
Re: Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
> We're trying to research an issue with our kickstarting that cropped up in > RHEL6.4 (worked perfectly in RHEL6.2). RedHat support has asked us to > wait till the kickstart fails then issue "CNTL+ALT+F1" to get into "pdb" mode > so they can debug the anaconda stuff, but since we boot in z/VM, the > terminal doesn't appear to translate those keys correctly--at least, I issue > them and nothing happens. Call RH back and insist on talking to someone who can understand "This is not an Intel system. Those keys don't exist on System z". > Does anyone know how to send those to the > host operating system through a tn3270e console? Or know of a different > way that we could get an ascii-based terminal for the automated kickstart if > needed? When I ssh into the guest at the failure time, I can hop on as root > but I'm not "breaking into" the install process--I can't enter anything that'd > change the flow of the install. > > Really hoping someone on this forum might have an idea, since IBM won't > respond (not a "zVM issue", apparently, that their console doesn't work) and > RedHat doesn't seem to know... The only way you could get an ASCII console that early in the process would be from the HMC, and it's still not going to help you. Try adding the "cmdline" option to the kickstart parm line. That will take you through the install line by line, which should help you find the problem. If this is 6.4, there are known bugs in kickstart. Have them search for "kickstart RHEL6.4" in their issue tracker. -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
We're trying to research an issue with our kickstarting that cropped up in RHEL6.4 (worked perfectly in RHEL6.2). RedHat support has asked us to wait till the kickstart fails then issue "CNTL+ALT+F1" to get into "pdb" mode so they can debug the anaconda stuff, but since we boot in z/VM, the terminal doesn't appear to translate those keys correctly--at least, I issue them and nothing happens. Does anyone know how to send those to the host operating system through a tn3270e console? Or know of a different way that we could get an ascii-based terminal for the automated kickstart if needed? When I ssh into the guest at the failure time, I can hop on as root but I'm not "breaking into" the install process--I can't enter anything that'd change the flow of the install. Really hoping someone on this forum might have an idea, since IBM won't respond (not a "zVM issue", apparently, that their console doesn't work) and RedHat doesn't seem to know... Thanks! Shannon Collinson, AVP, Mainframe Engineering SunTrust Bank Office: 404.827.6070 | Mobile: 404.642.1280 | Mail Code GA-MT-1750 | 245 Peachtree Center Ave Suite 1700 | Atlanta, GA 30303 How Can We Help You Shine Today? LEGAL DISCLAIMER The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer. By replying to this e-mail, you consent to SunTrust's monitoring activities of all communication that occurs on SunTrust's systems. SunTrust is a federally registered service mark of SunTrust Banks, Inc. [ST:XCL] -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 -- For more information on Linux on System z, visit http://wiki.linuxvm.org/
