Re: Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
On 07/17/2013 04:12 PM, Collinson.Shannon wrote: Yep, CPFMTXA works great, but our workaround (using dirmaint to remove then add the disks) is just a little quicker for us and we can do multiple disks at the same time easily. We also tried a %pre script that just whacked the first 1024 then 4096 bytes (used "dd" to zero them out) but that apparently didn't kill enough data to wipe out the "memory" of datavg-- I don't remember exactly but it might be that anaconda actually zeroes as much as 100 to 200 MB at the beginning of a disk/partition to wipe e.g. LVM metadata and another 100 to 200 MB at the end of a disk/partition to wipe e.g. mdraid metadata. dasdfmt works, but is pretty slow due to it doing the full minidisk one at a time. I saw several similar "solutions" for rhel4 and rhel5, so it seems like they oddly fixed it in early RHEL6 then backed off the fix for RHEL6.4! -Original Message- From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of carr...@nationwide.com Sent: Tuesday, July 16, 2013 5:10 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? FWIW and if I've understood the original problem as being Kickstart was not formatting disks even though you specify --clearpart Just to avoid misunderstandings: What's your definition of "formatting"? clearpart only removes partitioning entries (and initializes the disk label in the master boot record if --initlabel is specified in order to e.g. switch from DOS MBR to GPT on x86) https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html#idp22946368 zerombr overwrites the master boot record with all zeroes, which probably requires a "clearpart --initlabel" to end up with a new valid MBR signature. On System z, it also performs a low-level format, i.e. dasdfmt, if the disk does not already have a valid low-level format. The fact that you cannot seem to unconditionally low-level format any ECKD disk, is a different issue. A quick circumvention for the latter is destroying the disk layout, e.g. from Linux by running dasdfmt and shortly after it began (sorry for the vague wording) terminating it by sending an interrupt signal (SIGINT); this leaves the disk seemingly unformatted, so zerombr would low-level format it subsequently. Under z/VM there are other ways of quickly destroying the disk layout as a "preparation" for zerombr's low-level format. https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html#idp31208368 The creation of file systems is sometimes also referred to as "formatting". File systems are created by other kickstart commands. 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? I think, your issue was what I describe above for dasdfmt as part of zerombr, while Shannon just needs to kill metadata inside partition(s). 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. Even if the terminal code in Linux would learn to interpret this in the future as David already mentioned, the installer would also have to be tought such new feature. As of today the Linux installers on System z use: 1 Linux console on 3270 (zVM) or operating system messages (LPAR) [VT3]. 2 An ssh session to provide a full screen capable text terminal [VT1]. 3 Optionally, GUI in/output by means of VNC or X11 [VT1]. (4 And potentially arbitrary many root ssh sessions for problem determination or workarounds [VT2].) The corresponding CTRL+ALT+Fx VTs on x86 are in square brackets. I took the x86 documentation for the VT numbers from here: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/sn-guimode-virtual-consoles-x86.html VT4 and VT5 for different log output only gets written to files in /tmp on System z. With PDB on System z the mapping is slightly different because it does not appear on item 4 [VT2] but on item 2 [VT1]. RUNKS=1 drops the necessity for item 2. cmdline drops the necessity for item 3. Sandra From: "Co
Re: Any idea how to get into RedHat "PDB" mode on a kickstart through a TN3270 console in z/VM?
> It is true that DIRMAINT's support for "regions" dates back to when your > "DASD Analyst" studied the hot spots on the disk using the SEEK data from > the Monitor. But these days there are no worries about RPS delays or how > far the heads have to move. What you focus on today is I/O queuing. And spreading that stuff out tends to even that out too. > That said, DIRMAINT regions remain useful to protect things like warm start, > checkpoint, XLINK map records, and anything else that you don't > want DIRMAINT to allocate. Alternatively, you can use the $WARM$, > $CKPT$, etc. users to identify reserved space. My wish list contains an > update to CP QUERY ALLOC to include these other CP-owned extents. Then > DIRMAINT could dynamically create .WARM., .CKPT., etc. users as it does for > the things currently in QUERY ALLOC MAP. Would be nice - someday when the dev folks have a spare afternoon. I find the "dummy userid" ($WARM$, etc) approach is a lot simpler than coding it in DIRM control files -- that approach works regardless of what directory management tool you use -- even if you don't have one -- and it's one less thing to forget about when you do directory migration. -- 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?
On Wednesday, 07/17/2013 at 12:14 EDT, David Boyes wrote: > > Yep, CPFMTXA works great, but our workaround (using dirmaint to remove > > then add the disks) is just a little quicker for us and we can do multiple > > disks at the same time easily. > > It also tends *over time* to redistribute load more evenly over the physical > disk farms -- assuming that you have a sufficiently large number of volumes and > disk subsystems so that you're not totally oversubscribed at the start and you > have groups/pools defined with disk in different subsystems. There's some risk > management benefit too; data gets moved around to different places, which can > reduce the impact of a failure. > > DIRMAINTs disk allocation algorithm works pretty well, albeit these days we're > typically talking about full volumes so there's not that much placement > optimization going on at a micro level. It is true that DIRMAINT's support for "regions" dates back to when your "DASD Analyst" studied the hot spots on the disk using the SEEK data from the Monitor. But these days there are no worries about RPS delays or how far the heads have to move. What you focus on today is I/O queuing. That said, DIRMAINT regions remain useful to protect things like warm start, checkpoint, XLINK map records, and anything else that you don't want DIRMAINT to allocate. Alternatively, you can use the $WARM$, $CKPT$, etc. users to identify reserved space. My wish list contains an update to CP QUERY ALLOC to include these other CP-owned extents. Then DIRMAINT could dynamically create .WARM., .CKPT., etc. users as it does for the things currently in QUERY ALLOC MAP. Alan Altmark Senior Managing z/VM and Linux Consultant IBM System Lab Services and Training ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott -- 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?
> or you could use the wipefs utility, which should care of all signatures Any way to force Kickstart to use that when executing clearfs directives if it detect that a disk is already Linux formatted? -- 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?
On Wed, 17 Jul 2013 11:08:19 -0600 Mark Post wrote: > >>> On 7/17/2013 at 10:12 AM, "Collinson.Shannon" > >>> > wrote: > > We also tried a %pre script that just whacked the first 1024 then > > 4096 bytes (used "dd" to zero them out) but that apparently didn't > > kill enough data to wipe out the "memory" of datavg > > From some recent experimentation, it looks like the LVM metadata ends > somewhere around the 1MB mark into the volume. So, try writing 2MB > over the device and see if that works. or you could use the wipefs utility, which should care of all signatures Dan -- 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?
>>> On 7/17/2013 at 10:12 AM, "Collinson.Shannon" >>> wrote: > We also tried a %pre script that just whacked the first 1024 then 4096 bytes > (used "dd" to zero them out) but that apparently didn't kill enough data to > wipe out the "memory" of datavg >From some recent experimentation, it looks like the LVM metadata ends >somewhere around the 1MB mark into the volume. So, try writing 2MB over the >device and see if that works. Mark Post -- 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?
> Yep, CPFMTXA works great, but our workaround (using dirmaint to remove > then add the disks) is just a little quicker for us and we can do multiple > disks > at the same time easily. It also tends *over time* to redistribute load more evenly over the physical disk farms -- assuming that you have a sufficiently large number of volumes and disk subsystems so that you're not totally oversubscribed at the start and you have groups/pools defined with disk in different subsystems. There's some risk management benefit too; data gets moved around to different places, which can reduce the impact of a failure. DIRMAINTs disk allocation algorithm works pretty well, albeit these days we're typically talking about full volumes so there's not that much placement optimization going on at a micro level. -- 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?
Yep, CPFMTXA works great, but our workaround (using dirmaint to remove then add
the disks) is just a little quicker for us and we can do multiple disks at the
same time easily. We also tried a %pre script that just whacked the first 1024
then 4096 bytes (used "dd" to zero them out) but that apparently didn't kill
enough data to wipe out the "memory" of datavg--dasdfmt works, but is pretty
slow due to it doing the full minidisk one at a time. I saw several similar
"solutions" for rhel4 and rhel5, so it seems like they oddly fixed it in early
RHEL6 then backed off the fix for RHEL6.4!
-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of
carr...@nationwide.com
Sent: Tuesday, July 16, 2013 5:10 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?
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 id
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 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
> tak
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/
