vmur reader uevent patch upstream
Dear all,
based on discussions on this mailing list [1], and a request that
reached me via the OpenMainframeProject mailing list [2], I've
implemented the functionality of generating a kernel uevent that can be
used as a trigger e.g. for processing newly arrived VM reader files in
Linux.
This function has now been added into the upstream Linux kernel source
repository as commits [3][4]
bf18140d3054 ("s390/vmur: generate uevent on unsolicited device end")
f3e59ff348c0 ("s390/vmur: remove unnecessary BUG statement")
and is queued for integration into Linux kernel v6.1. From there it will
likely be picked up by future Linux distribution versions that will be
based on that kernel level. Note that there are currently no plans by
IBM to back-port this feature to older distribution versions.
For your reference, here's the associated commit message containing some
usage details. Please let me know if you have additional questions, or
comments. Thanks!
==
s390/vmur: generate uevent on unsolicited device end
When a traditional channel-attached device transitions from not-ready to
ready state, an unsolicited DEVICE END I/O interrupt is raised. This
happens for example when a new file arrives in the z/VM virtual reader
device.
Change the Linux kernel to generate a change uevent when such an
interrupt occurs for any online unit record devices supported by the
vmur driver. This can be useful to automatically trigger processing of
files as they arrive in the reader device.
A sample udev rule for running a program when this event occurs looks as
follows:
ENV{DRIVER}=="vmur", ACTION=="change", ENV{EVENT}=="unsol_de", \
RUN{program}="/path/to/program"
The rule can be tested using the following steps:
1. Set reader device online (assuming default reader device number 000c)
$ chzdev -ea 0.0.000c
2. Force a ready-state transition using z/VM's READY CP command
$ vmcp ready 000c
==
Regards,
Peter
[1] http://www2.marist.edu/htbin/wlvtype?LINUX-VM.97664
[2] https://lists.openmainframeproject.org/g/wg-linux-distros/message/59
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/s390/char/vmur.c?id=bf18140d30541c2c1e5c0f57879634f3d0d04912
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/s390/char/vmur.c?id=f3e59ff348c077a6afd4edb23d7e69e9cba62fdc
--
Peter Oberparleiter
Linux on IBM Z Development - IBM Germany R
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: LUN ID - Filesystem
On 04.07.2022 06:13, Jake Anderson wrote: > Is it possible to know the LUN ID where a specific filesystem is residing? You can use 'lszdev --by-path ' to display information about the device that provides a specific filesystem path. Regards, Peter -- Peter Oberparleiter Linux on IBM Z Development - IBM Germany R -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: Warning if upgrading SLES12 to SLES15 SP3
On 08.10.2021 18:08, Aria Bamdad wrote:
> Quoting Peter Oberparleiter :
>
> Peter, thank you for your excellent analysis and clarification of how
> this works. It now makes perfect sense to me.
I'm glad that you found the information I provided to be helpful.
[...]
> I tested the what you said above. Sure enough, if you have dasda1 as
> your root device for the active system, you will find properly defined
> device names in by-id, by-path and by-uuid for this disk. Then if you
> were to activate/enable a clone of that disk, say as dasdf1, what
> happens is that by-id and by-path are still correct (they point to
> dasdf1) but chzdev will replace the existing symbolic link in by-uuid
> pointing to dasda1 with a new one pointing to dasdf1 (as it should) so
> now you will overwrite the previous UUID symbolic link that pointed to
> dasda1 with one that points to dasdf1.
Small correction: the links are not created by chzdev, but by udev which
is a core part of Linux OS distributions.
> We no longer have one for
> dasda1 which is the true root file system since we can't have two
> files with the same name here. chzdev does this without any warning.
> Shouldn't it at least give a message or better yet, no replace the
> file in by-uuid?
Unfortunately there's no easily consumable way for udev to issue
warnings like that. And chzdev cannot check a device's UUID without
activating it - and then it would already be too late.
> Perhaps it would be good to present the same warning
> as it currently does when you try to disable/deactivate a disk and it
> detects conflicting UUIDs. In my opinion, that would be a good thing
> as it prompts the user that they are about to do something that may
> result in a system being in a inconsistent state. Not creating the
> link in by-uuid in situations like this would avoid the problem all
> together.
Indeed udev *does* provide a level of control over how the situation
with conflicting UUIDs - or more generally: conflicting link targets -
is handled. A udev rule can assign a link-priority value to a device. If
two devices with the same symlink target are found, the device with the
higher link-priority value will take precedence.
>From my own experience writing a udev rule isn't always
straight-forward, so I'll provide an example to support the discussion.
This example assumes two DASDs, each with a single partition containing
an ext-filesystem:
- 0.0.1000: dasdb1
- 0.0.2000: dasdc1
By default all devices are assigned a link-priority of 0. To quote the
udev man page:
If no link_priority is specified, the order of the devices
(and which one of them owns the link) is undefined.
The usual effect though will be that the device that is registered last
will take precedence.
The following sequence of commands demonstrates the problem by assigning
the same file system label first to dasdb1, then to dasdc1. The output
of readlink shows the resulting link target:
$ e2label /dev/dasdb1 test
$ readlink /dev/disk/by-label/test
../../dasdb1
$ e2label /dev/dasdc1 test
$ readlink /dev/disk/by-label/test
../../dasdc1
As you can see, dasdc1 overwrites the previous dasdb1 link target.
Now if you create a udev rule that assigns a different link-priority,
the device with the higher value will take precedence.
Here's an example udev rule file that assigns a link-priority of -1 to
all partitions on the DASD with device number 2000.
ACTION=="add|change", KERNEL=="dasd*", ENV{DEVTYPE}=="partition",
ENV{ID_PATH}=="ccw-0.0.2000", OPTIONS="link_priority=-1"
The rule can be activated by storing it as a single line to a file with
a name ending in .rules in /etc/udev/rules.d, e.g.
/etc/udev/rules.d/99-dasd-link-prio.rules
How this rule works:
1. ACTION=="add|change"
If a new device was registered, or an existing one was modified
2. KERNEL=="dasd*"
and the device node name starts with "dasd"
3. ENV{DEVTYPE}=="partition"
and the device type is a partition
4. ENV{ID_PATH}=="ccw-0.0.2000"
and the device ID path that includes the device number matches
the specified value "ccw-0.0.2000"
5. OPTIONS="link_priority=-1"
then assign a link-priority value of -1 which is lower than the
default value of 0
In our example setup, the rule will match the udev change events
generated when modifying the label for the file system on device dasdc1
(device number 2000), and assign a lower-than-default priority of -1 to
it. As a result if you repeat the sequence from before, you'll find that
the symlink for dasdb1 is no longer overwritten:
$ e2label /dev/dasdb1 test2
$ readlink /dev/disk/by-label/test2
../../dasdb1
$ e2label /dev/dasdc1 test2
$ readlink /dev/disk/by-label/test2
../../dasdb1
The consumability of writing udev rules is of course limited, but the
flexibility
Re: Warning if upgrading SLES12 to SLES15 SP3
me problems both with > chzdev and boot issue. The evaluation of file system UUIDs by chzdev was specifically added to support correct handling of multi-disk btrfs file systems. Also given that a file system UUID is supposed to uniquely identify a file system, I don't consider the current behavior a problem in chzdev. Regards, Peter -- Peter Oberparleiter Linux on Z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: integrated console overflow from the Linux installer
> On 10.06.2021 22:43, Alan Altmark wrote: >> A colleague is installing RHEL 8.4 in an LPAR via ftp server. The system >> loads, but early in the installer boot process there's a network error >> that he can't scroll back to look at because the Operating System Messages >> console "rolls off" after about 475-500 messages. >> >> Can he update the generic.prm file to reference the integrated ASCII >> console instead? > > Add > > console=ttyS1 > > to have Linux use the integrated ASCII console as main console (input > and output), or > > console=ttyS1 console=ttyS0 > > to copy console messages to the ASCII console while keeping the > OS-Message console as main console. > >> And will that give him better console management to let >> him see early boot errors? > > No. The Integrated ASCII console HMC task does not provide a scroll-back > function. I need to correct my statement here - the Integrated ASCII console HMC task does indeed provide a scrolling capability that can be accessed by using the Shift+PageUp/PageDown keys. Thanks to Alan Altmark and the HMC team for following up on this! Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on Z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: integrated console overflow from the Linux installer
On 10.06.2021 22:43, Alan Altmark wrote: > A colleague is installing RHEL 8.4 in an LPAR via ftp server. The system > loads, but early in the installer boot process there's a network error > that he can't scroll back to look at because the Operating System Messages > console "rolls off" after about 475-500 messages. > > Can he update the generic.prm file to reference the integrated ASCII > console instead? Add console=ttyS1 to have Linux use the integrated ASCII console as main console (input and output), or console=ttyS1 console=ttyS0 to copy console messages to the ASCII console while keeping the OS-Message console as main console. > And will that give him better console management to let > him see early boot errors? No. The Integrated ASCII console HMC task does not provide a scroll-back function. Some additional ideas: 1. Add rd.break=cmdline to the parmfile to get a controlled stop early in the boot process (hopefully before the relevant data is scrolled away) Enter CTRL-D (enter ^d on the OS message input line) to continue 2. Stream console messages to a local terminal using SNIPL (SLES only) https://www.ibm.com/docs/pl/linux-on-systems?topic=shutdown-snipl-control-virtual-hardware or zhmcclient https://github.com/zhmcclient/zhmccli Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on Z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: SYSASCII Console for Linux images
On 03.03.2021 16:36, Alan Altmark wrote: > On Wednesday, 03/03/2021 at 02:25 GMT, Peter Oberparleiter > wrote: >> 3. Use the ASCII Console as Linux console >> >> - add "console=ttyS1" to kernel parameters in /etc/zipl.conf >> (mind the upper-case S) >> - run zipl + reboot >> >> During boot you should see all Linux console output on the ASCII >> Console. > > Is there a way to tell Linux, "Use the ascii console unless there isn't > one, in which case use the 3215 console instead."? You can tell Linux to print console output to both ASCII and 3215 consoles by repeating the console= statement for ttyS0 (3215) and ttyS1 (ASCII). You can also configure Linux to provide a login prompt that works independently on both consoles. The one thing that's not possible with the current implementation is to control the Linux init process from both consoles. This is typically necessary if there's an error during early boot - like a root file system corruption - that requires manual intervention to resolve. The input device that is connected to the init process is determined once during kernel initialization depending on the order of console= statements (the last one will be used for input) and it cannot be changed without a reboot. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on Z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: SYSASCII Console for Linux images
On 01.03.2021 21:26, Davis, Larry (National VM Capability) wrote: > What are people doing when the local Linux people are wanting ASCII Consoles > available for performing reboots or problem resolution > > I know I can attach the SYSASCII (HMC ASCII vt220 console) to a Linux image > > Does the Linux image need to include "ttys1" in the /etc/zipl.conf file for > RHEL 7.5 and above? > console=ttyS1 console=ttyS0 You can specify "console=ttyS1" as additional kernel parameter if you want to have console output written to the ASCII Console, and also to use that console as input device for early boot problems (e.g. dracut rescue shell). > We tested attaching it to a Running Linux but the device never really worked > when attached, we probably missed something > > Any Suggestions on using this properly? I just tried this on an RHEL 7.5 z/VM guest and everything seemed to work without problems. Some things to try out (requires root privileges): 1. Attach ASCII console to guest from within Linux guest $ vmcp att sysascii to '*' 2. To check the connection to the ASCII console: open the "Integrated HMC ASCII Console" task for the z/VM LPAR. Then issue in Linux: $ echo test > /dev/ttysclp0 The result should be "test" being displayed on the ASCII Console. 3. Use the ASCII Console as Linux console - add "console=ttyS1" to kernel parameters in /etc/zipl.conf (mind the upper-case S) - run zipl + reboot During boot you should see all Linux console output on the ASCII Console. You can also check this connection using the following command: $ echo test > /dev/console The "test" message should again be displayed on the ASCII Console. 4. Enable login from the ASCII Console $ systemctl start serial-getty@ttysclp0.service When this command completes, there should be a login prompt shown on the ASCII Console. You can also check the status of this systemctl unit using: $ systemctl status serial-getty@ttysclp0.service Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on Z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: Linux and 5 digit address
On 14.01.2021 02:11, Marcy Cortes wrote: > I tried to bring it up today, but it failed to find the ipl volume. > I figured out that it was because we are on site 2 disk this week and the > real address to use in the HMC is 5 digit, starting with a 1, say 10F57. > I need to add that to the linux config. Linux sees things as > 0.0.0f57 under VM.Is the 5 digit Linux address in the LPAR going to > be 0.1.0F57 or 1.0.0F57? The first digit in a 5 digit device number as entered on the HMC load panel is the SSID (Subchannel Set ID). In Linux this is reflected in the second number of the device number triplet. To put it another way: X (HMC) => 0.X. (Linux) > I think I’ll need to make another udev rule for that (this is SLES 15 SP2). That should work as udev rules are only triggered for devices that Linux can see. The extra rule should have no adverse effect in the z/VM guest where the device in subchannel set 1 is missing. Something like the following should do the trick: $ chzdev -ep dasd-eckd 0.1.0f57 -- Peter Oberparleiter Linux on Z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: Issues trying to install RHEL 8
On 01.08.2019 14:44, Martha McConaghy wrote: > Thanks for the links. They didn't pan out though. > > FYI - another person on the team (at another location) tried to do an > install using the same image I have and got the same results. This was > in his test environment, completely different from the one I have. So, > we seem to have stumbled into a new problem. The install image we are > using is dated April 4. He checked and it seems to be the latest one > available. My guess would be a problem with the installation parmfile. Does your installation parmfile contain an "enccw0.0." parameter? If so this needs to be changed (as pointed out in a previous post by Christian). Example for RHEL 7: ip=x.x.x.x::x.x.x.x:x:x:enccw0.0.bdf0:none How it needs to look like in RHEL 8: ip=x.x.x.x::x.x.x.x:x:x:encbdf0:none If this doesn't solve the problem, could you share the installation parmfile contents (minus the sensitive data). Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on Z Development - IBM Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www2.marist.edu/htbin/wlvindex?LINUX-390
Re: Moving zLinux to a bigger disk
On 29.06.2018 00:10, Donald Russell wrote:
> On Thu, Jun 28, 2018 at 14:27 Donald Russell wrote:
>> The dasdfmt -b 4096 --mode=expand worked great. Started formatting the
>> disk at track 150240 as expected. But then fdasd choked saying only the
>> first 10016 cylinders are formatted so I can’t create the new larger
>> partition.
>>
>> How can I coerce fdasd into doing the right thing? Whatever fdasd is
>> looking at for that cylinder count I expected dasdfmt to update.
>>
>> Where is that data, maybe I can just zap it with some other tool like cms
>> pipe read/write track.
fdasd is looking at the DASD's VTOC, specifically at the format 5 DSCB
that is supposed to list free space extents on the volume. The 'dasdfmt
--mode expand' call doesn't add the newly formatted extent to this DSCB,
therefore fdasd assumes that that it is not formatted.
This is a bug/limitation in dasdfmt/fdasd and we plan to fix this in a
future version of s390-tools.
In the meantime, you can try the following:
# fdasd /dev/dasd...
u ('re-create VTOC re-using existing partition sizes')
y ('yes')
w ('write table to disk and exit')
You need to perform these steps TWICE, or fdasd will terminate with a
"BUG..." statement when you try to create/change partitions afterwards.
Regards,
Peter Oberparleiter
--
Peter Oberparleiter
Linux on Z Development - IBM Germany
--
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: chzdev in SLES?
On 03.05.2016 20:24, Mark Post wrote: >>>> On 5/3/2016 at 02:16 PM, Michael MacIsaac <mike99...@gmail.com> >>>> wrote: >> Hello list, >> >> I stumbled on a chzdev command in Ubuntu - a seemingly neat tool >> for creating udev rules files. It seems that's in the 1.33 version >> of s390-tools, so it does not appear to be in my SLES 12 SP1 >> system. Will this be in SLES soon? > > It was going to be in SLES12 until we and IBM abandoned the effort > because the code quality and functionality was so poor. I haven't > looked at the version that will be going into SLES12 SP2 to know if > it's worth using or not. Please note that the zdev tools (chzdev, lszdev) included in s390-tools 1.33 are the result of a full rework. I'm confident that all major issues of earlier versions have been resolved by this new version. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on z Systems Development - IBM Germany -- 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: Find LUN (zfcp) in use from z/VM?
On 11.05.2015 22:08, Alan Altmark wrote: On Monday, 05/11/2015 at 02:57 EDT, Nix, Robert P. nix.rob...@mayo.edu wrote: Plus, even if you could find out if other zVM guests had access to the LUN, that would not tell you what other systems, outside of this zVM (I.E. On other zVM¹s, or on Intel or PowerPC systems, Linux or Windows, or even Solaris or AIX?) had access to the LUN. Same issue as ECKD. An OS cannot tell what other OSes/LPARs have access to an ECKD dasd volume. Well, it can to an extent [1][2]: Query Host Access is a new DS8000 function that reports all LPARs that have established a Path Group Id on a volume, whether in the grouped state or not. z/VM now offers support to query the CPU Serial Number and LPAR ID associated with all LPARs that have established a Path Group Id to a volume, allowing one to determine all LPARs with access to a volume. [1] http://www-01.ibm.com/support/docview.wss?uid=isg1VM65322 [2] http://www-01.ibm.com/support/docview.wss?uid=isg1OA40720 We simply ignore the issue and put the burden on the hardware people to limit access. We're lucky in that we generally trust the accessing systems. A naive trust, perhaps, but still My issue is that I don't understand the job of the SAN storage administrator well enough to judge how hard is is to implement strict zoning and LUN masking rules. They have orders of magnitude more devices to deal with. Alan Altmark Senior Managing z/VM and Linux Consultant Lab Services System z Delivery Practice IBM Systems Technology Group ibm.com/systems/services/labservices office: 607.429.3323 mobile; 607.321.7556 alan_altm...@us.ibm.com IBM Endicott Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on z Systems Development - IBM Germany -- 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: Do you use the Linux Health Checker?
On 13.11.2014 18:55, Marcy Cortes wrote:
I think I found a bug.
Server on a zEC12 with crypto accelerator
zlinux-maint:~ # lszcrypt
card2b: CEX4A
Reports
zlinux-maint:~ # lnxhc run crypto_opencryptoki_ckc -V
Collecting system information
Host 'zlinux-maint'
file::/proc/cpuinfo
[SUCCESS]
program::/bin/rpm -qa
--queryformat='%{name}-%{version}-%{release}.%{arch}\n'
[SUCCESS]
program::/sbin/lszcrypt
[SUCCESS]
program::/usr/sbin/pkcsconf -t
[SUCCESS]
program::ls /dev/z90crypt
[SUCCESS]
Running checks (1 checks)
CHECK NAME HOST
RESULT
crypto_opencryptoki_ckc zlinux-maint
EXCEPTION-MED
EXCEPTION crypto_opencryptoki_ckc.crypto_adapters_not_available(medium)
SUMMARY
Required cryptographic adapters are not available (Cryptographic
Coprocessor, Cryptographic Accelerator)
This is indeed a bug in the corresponding health check (and other crypto
related health checks). It appears that the check program didn't expect
hexadecimal card numbers (such as 2b) and therefore incorrectly assumes
that the hardware is missing. I've added a fix to our code repository.
It will be included in the next release. Thanks for pointing out this issue!
Regards,
Peter Oberparleiter
--
Peter Oberparleiter
Linux on System z Development - IBM Germany
--
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: Do you use the Linux Health Checker?
On 13.11.2014 19:04, Marcy Cortes wrote: One more thing, Checks fs_fstab_fsck_order and fs_usage both fail on a loopback filesystems Example from /etc/fstab for one of those: /apps/distro/sles11sp3/SLES-11-SP3-DVD-s390x-GM-DVD1.iso /apps/distro/sles11sp3/DVD1 iso9660 loop,ro 0 0 To be precise: the error lies in the fact that these health checks report findings for a read-only file system while the associated problems can only really occur on read-writable file systems. I've adjusted the corresponding check programs to exclude iso9660 and read-only mounted file systems. The change will be made available with the next release. Again thanks for pointing this out! Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on System z Development - IBM Germany -- 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: 2014-01-08 Linux on System z - Kernel 3.12 related updates on developerWorks
On 19.03.2014 15:43, Alan Altmark wrote: On Wednesday, 03/19/2014 at 10:30 EDT, Neale Ferguson ne...@sinenomine.net wrote: Wow, there are more caveats than a viagra commercial. I suppose I should have warned that you should not use zdsfs if your auditors have high blood pressure as it may cause their heads to explode. While I agree that the list of restrictions is long, I think it is still fair to point out that once all necessary precautions are taken, zdsfs might provide an opportunity to transfer data from a z/OS instance to a Linux on System z instance faster (given sequential access) and with lower CPU overhead than traditional NFS or FTP transfer methods. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on System z Development - IBM Germany -- 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: dasdfmt slowness
On 04.03.2014 00:18, Marcy Cortes wrote: Back Nov 2012 ... a long discussion ensued. On 08.11.2012 00:58, Marcy Cortes wrote: It takes about 42 minutes here to dasdfmt a volume with 65519 cylinders on it. It takes about 18 minutes to dd an already formatted volume over to a new one. It also takes about 19 minutes to fill it up with zeros by cat /dev/zero to it. Why does dasdfmt take so long? This is a known problem which is currently being investigated. Regards, Peter Oberparleiter Any progress in this area? Yes: Improvements have been made to both the dasdfmt tool and the Linux kernel to speed up the process of formatting a DASD. These changes are available upstream [1][2] (both are needed for an effect to become visible) and work is being done to get them integrated in upcoming distribution releases. The new code makes use of PAV and HyperPAV aliases, but can also provide a noticeable improvement without any aliases. Regards, Peter Oberparleiter [1] http://www.ibm.com/developerworks/linux/linux390/s390-tools-1.23.0.html [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d42e17129b9f473386d67c6a6549c28bd0e2b52e -- Peter Oberparleiter Linux on System z Development - IBM Germany -- 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: Where does Linux store path information for dasd devices?
On 09.07.2013 13:39, Rick Barlow wrote: We have 8 FICON paths to the DASD subsystem shared through switches to 2 z196 machines each having 8 FICON paths to the switches. Of the 8 paths, 4 have been offline from all 8 LPARs for a couple of months while we waited for IODF changes and physical cabling changes to move those 4 paths from old switches to newer switches. Last evening, I varied on the 4 paths that were moved to all 8 LPARs and verified that they were online to the DASD. I only spot checked the paths and not all 1800 volumes. After I confirmed that all 8 paths were online to the DASD, I took the other 4 paths offline. Shortly after that, the small subset of Linux guests began having problems. We only saw issues on about 20 of over 500 Linux guests. The recommended procedure for performing maintenance on a CHPID looks like this: 1. Vary CHPID off in Linux (chchp -v 0 CHPID) 2. Vary path off in z/VM 3. Vary CHPID off in z/VM 4. Perform maintenance 5. Vary CHPID on in z/VM 6. Vary path on in z/VM 7. Vary CHPID on in Linux (chchp -v 1 CHPID) If necessary, step 7 can be used after the fact to tell Linux to update status information for all paths of all devices using that CHPID. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on System z Development - IBM Germany -- 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: RHEL 6.3 DASD configuration
On 21.02.2013 15:57, Davis, Larry (National VM Capability) wrote: I finally got the Graphical installer working using X but now when I try to Install Linux on my DASD I end up with DASD accessed R/O when it was initially all R/W. No Matter what option I use I always end up with this error. Just prior to connecting to the new Linux to perform the install all DASD looks like this Activated DASDs: 0.0.0150(ECKD) dasdb : active, blocksize: 4096, 54000 blocks, 210 MB 0.0.0151(ECKD) dasdc : active, blocksize: 4096, 1746000 blocks, 6820 MB 0.0.0160(FBA ) dasdd : active, blocksize: 512, 524288 blocks, 256 MB 0.0.0161(FBA ) dasde : active, blocksize: 512, 1048576 blocks, 512 MB Initial configuration completed. After I do the basic installation steps and create a custom layout /boot on 150 / on 151 Swapon 160 Swapon 161 In the end I always get an error that a device is R/O and the process can't continue /dev/dasdx is marked as R/O From the available output it is not clear if 0150 and 0151 where formatted with the CDL format (dasdfmt with default options or -d ldl). Please note that the use of partitions is mandatory for CDL formatted DASDs (/dev/dasdx1 instead of /dev/dasdx). By not using a partition, the filesystem on the DASD will get corrupted, which can also result in it being re-mounted read-only. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on System z Development - IBM Germany -- 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: Using dasd_configure in SLES11 SP2
On 13.02.2013 00:38, Leland Lucius wrote:
Create the following file and remove all of your existing 51-dasd*.rules.
cat /etc/udev/rules.d/51-dasd.rules
# Rule to add all eckd devices
ACTION==add, SUBSYSTEM==ccw, DRIVER==dasd-eckd, ATTR{online}=1
Note that adding kernel/module parameter dasd=autodetect should achieve
the same result.
Regards,
Peter Oberparleiter
--
Peter Oberparleiter
Linux on System z Development - IBM Germany
--
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: dasdfmt - why are you so darn slow?
On 08.11.2012 00:58, Marcy Cortes wrote: It takes about 42 minutes here to dasdfmt a volume with 65519 cylinders on it. It takes about 18 minutes to dd an already formatted volume over to a new one. It also takes about 19 minutes to fill it up with zeros by cat /dev/zero to it. Why does dasdfmt take so long? This is a known problem which is currently being investigated. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on System z Development - IBM Germany -- 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: I/O scheduler on sles 11 sp2 on z
On 24.10.2012 18:54, Marcy Cortes wrote: On IBM System z the default I/O scheduler for a storage device is set by the device driver, but trying to query what it is seems to indicate that everything is deadline already (but it must not be or the parm wouldn't have helped). Could it be that you are using LVM which adds its own block devices which are not affected by DASD's elevator defaults? Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on System z Development - IBM Germany -- 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: SCSI/FCP disk size
On 10.10.2012 01:32, Thang Pham wrote: Is there a way to find out the size of a native SCSI device attached via FCP channel? I do not see lszfcp or lsscsi having an option that lets you see the size of the disk you have attached to a VM. You can view the usable size of any block device (not just SCSI) using the following command: # cat /proc/partitions major minor #blocks name 80 10485760 sda 81 10485743 sda1 Note: the #blocks is the size in 1k-blocks Newer distributions provide a tool called 'lsblk' which also shows disk and partition sizes. # lsblk NAME MAJ:MIN RM SIZE RO MOUNTPOINT sda8:0010G 0 └─sda1 8:1010G 0 / Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on System z Development - IBM Germany -- 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: zLinux, IBM XIV, thin provisioning
On 14.06.2012 02:46, Grzegorz Powiedziuk wrote: d2ora000:~ # fstrim /mnt/thin_test_btrfs/ fstrim: /mnt/thin_test_btrfs/: FITRIM ioctl failed: Operation not supported d2ora000:~ # fstrim /mnt/thin_test_xfs/ fstrim: /mnt/thin_test_xfs/: FITRIM ioctl failed: Operation not supported [...] /dev/mapper/20017380062aa0048_part1 on /mnt/thin_test_btrfs type btrfs (rw) /dev/mapper/20017380062aa0045_part1 on /mnt/test type xfs (rw) Just a wild guess, but maybe the device mapper targets don't allow pass-through of the corresponding IOCTL commands. You could try installing a file system on the bare disk (no LVM) and see if that works. Regards, Peter Oberparleiter -- 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: dasd_configure doesn't see partition 1 on RO disk
On 11.10.2011 10:26, Roger Evans wrote:
I am trying to mount a disk R/O from two linux machines on one VM. One
of them is SLES10 where the disk is defined in zipl.conf. The other
is a new SLES11 ('CLPRODB2)..
[...]
On the VM console for the SLES11 machine, I get the following msg:
--
DPRODDB2 login: dasd-eckd.90fb0d: 0.0.0119: New DASD 3390/0C (CU
3990/01) with 3
2759 cylinders, 15 heads, 224 sectors
dasd-eckd.412b53: 0.0.0119: DASD with 4 KB/block, 23586480 KB total
size, 48 KB/
track, compatible disk layout
dasdk:
Warning, expected Label VOL1 not found, treating as CDL formated Disk
Oct 11 08:08:21 DPRODDB2 kernel: Warning, expected Label VOL1 not found,
treating as CDL formated Disk
--
Judging by this output, it appears the the Linux kernel on your SLES11
system sees different VTOC data than the kernel on SLES10. Please try
the following:
- Set the device offline on both systems
- Detach the device from both systems
On the SLES10 system:
- Attach + set online
- Check if the partition is recognized
- Dump VTOC data:
dasdview -t all /dev/dasd... sles10.txt
- Set offline + detach
On the SLES11 system:
- Attach + set online
- Check if the partition is recognized
- Dump VTOC data:
dasdview -t all /dev/dasd... sles11.txt
- Compare the VTOC data:
diff -u sles10.txt sles11.txt
If there is a difference, please send the output of the diff command.
Regards,
Peter Oberparleiter
--
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: Annoyances with lsdasd and/or /proc/dasd/devices
On 10.08.2011 21:40, Patrick Spinler wrote: Okay, please accept an 'I'm stupid' retraction, as Bob N. across the wall got me. Running 'lsdasd' as root returns the full information about the device in a nicely parsable format. (Curious it doesn't as non-root, but there you go). newer versions of lsdasd (including the one from s390-tools 1.8) should generate parsable output when specifying the --long parameter, independently of whether it is run as root or another user. Note that certain values (such as the blocksize and number of blocks) will show as ??? for non-root users.. The reason for this is that lsdasd requires read access for the device nodes (e.g. /dev/dasda) to obtain this information and this type of access is usually restricted to certain users/groups. Regards, Peter Oberparleiter -- 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: z/VM RedHat Virtual Machine Memory abend
On 21.04.2011 00:19, Carlos Bodra - Pessoal wrote: If linux virtual machine is defined with 64G in directory we got an abend during startup (see below). Doing some tests I found that I can define it until 59G in directory (60794036k from TOP linux command) and it will startup correctly. My questions are: 1 - Is this a limitation of linux s390x or Red Hat distribution? 2 - Is this a linux s390x bug or Red Hat distribution? 3 - How can I circunvent this so we can continue with POC (Proof Of Concept)? There is a chance that the initial ramdisk of your system is being overwritten by the memory map that Linux creates at boot time. Try increasing the ramdisk load address in your zipl.conf file (see chapter 37 in * for instructions). Regards, Peter Oberparleiter [*] http://public.dhe.ibm.com/software/dw/linux390/docu/lk37dd09.pdf -- 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: Problems using channel-attached 3270 terminal
On 20.04.2011 20:21, Patrick Finnegan wrote: I have a couple of 3270-mode terminals locally attached via a 3174-21L on my z890 running Debian/Squeeze in an LPAR. According to the 3270 terminal driver documentation, I should be able to enter ctrl-C, ctrl-D, etc, using ^C or ^D. I can successfully do this from the SE/HMC console window. Looking at drivers/s390/char/defkeymap.map, I see the following definitions: control keycode 107 = Control_z # PA3 control keycode 108 = Control_c # PA1 control keycode 110 = Control_d # PA2 The comments suggest that pressing the PA1 key will generate Control-C, PA2 Control-D and PA3 Control-Z. Have you tried using these keys instead of the ^C sequence? Regards, Peter Oberparleiter -- 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: ECKD driver vs DIAG driver
On 04.01.2011 16:02, Richard Troth wrote: Mark is correct: one automagically created partition. Worse, there is no 'fdasd' or 'fdisk' management of that partition. Actually you *can* use fdisk to manage partitions on DASDs which are formatted with a fixed block size (ECKD LDL or FBA), regardless of whether DIAG access is used or not. Example: to get rid of the implicitly created DASD partitions on /dev/dasdx, use these commands: echo w | fdisk /dev/dasdx This will write an MS-DOS type master boot record with an empty partition table to dasdx. Note that some operations (mkfs.ext, pvcreate) seem to overwrite the MBR so the fdisk step should be performed last. More background: When a DASD is set online, the Linux kernel attempts to recognize the partition type by letting all supported partition type handlers have a look at the disk contents. This process happens sequentially and stops once a handler indicates that it has found a valid partition. The DASD partition handler comes very late in the list, so pretty much any partitioning scheme supported by the Linux kernel can be used to circumvent implicit DASD partitioning. WORSE STILL, you *must* put the filesystem into the partition (such as it is) if you are going to boot from this disk. A filesystem in /dev/dasdx will be clobbered by the first stage of the boot loader, while a filesystem in /dev/dasdx1 is protected by the extra 8K of padding. (12K total) I checked it again this morning. The bootstrap overwrites the root inode. This is a side effect of the zipl boot loader design, more precisely of the size of the first stage IPL code that is written to block 0. It's conceivable that this could be changed in the future. God bless whoever in Boeblingen fixed this problem for FBA disks. You can use the pseudo-partition, or not. You can boot from them either way. This problem never existed for FBA disks - the first stage FBA IPL code only spans a single FBA block. According to Martin Schwidefsky this approach was chosen because there were no format or layout restrictions for FBA disk so they decided to keep it similar to the Intel world. Regards, Peter Oberparleiter -- 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: Can't create ctcmpc groups
On 05.11.2010 13:44, Roger Evans wrote: When I execute the command: echo 0.0.0400,0.0.0401/sys/bus/ccwgroup/drivers/ctcmpc/group as per instructions from the device drivers, Features and Commands manual, i get an error message. Like this: LNXCCL:/etc/rc.d # echo 0.0.0400,0.0.0401 /sys/bus/ccwgroup/drivers/ctcmpc/group -bash: echo: write error: Invalid argument Possible reasons for this error: 1. devices 400 and 401 are not recognizes by Linux 2. devices are of different type 3. devices are already grouped For 1 and 2 see the output of the lscss command. If the device doesn't show up, make sure they are correctly attached to your z/VM guest/LPAR. For 3 see if a directory named 0.0.0400 exists in /sys/bus/ccwgroup/devices. If so, set it offline and ungroup it. Regards, Peter Oberparleiter -- 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: Red Hat network modules
On 22.06.2010 20:39, Thang Pham wrote: I dropped the first instance of the qeth module, and the qeth: Unknown symbol qdio_synchronize qeth: Unknown symbol do_QDIO ... errors disappeared. But the ERROR: Interface setup failed: pumpSetupInterface failed: get link - 19: No such device error is still there. I am using dhcp in my custom initrd. How exactly are you building your custom initrd? Does your custom built initrd create and activate a ccwgroup device according to Chapter 7 in http://public.dhe.ibm.com/software/dw/linux390/docu/lk33dd05.pdf? (post the output of lsqeth). Are all required ccw devices available to Linux? (post the output of lscss). Regards, Peter Oberparleiter -- 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: SHMALL and SHMMAX
Deric Abel wrote: -- Shared Memory Limits max number of segments = 4096 max seg size (kbytes) = 18014398509481983 max total shared memory (kbytes) = 4611686018427386880 min seg size (bytes) = 1 I don't know about you, but that total shared memory can't be good to have that large of a number. Is this a bug (or a feature ;) )? Feature, it seems. See https://bugzilla.novell.com/show_bug.cgi?id=146656 (requires a Novell user ID to access). Regards, Peter Oberparleiter -- 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
Re: chccwdev never returning on SLES 11
Michael MacIsaac wrote: Has anyone seen the chccwdev -d command never return? Not only does it not return, but I can't kill it from another SSH session: If you can't kill the chccwdev process, this is an indication that the process is currently waiting in a kernel function for a hardware response. There are two reasons why the kernel function wouldn't finish by itself: hardware error or kernel programming error. Are there any messages in the output of 'dmesg' that indicate that device 21b7 may have a problem? What is the output of 'lscss -d 0.0.21b7 --avail'? Regards, Peter Oberparleiter -- 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
Re: Problems using portno in PARMFILE on SLES11
Tobias Doerkes wrote: ccwgroup 0.0.a000 has network IF eth0 *** glibc detected *** /init: free(): invalid pointer: 0x0388f4a4 *** === Backtrace: = /lib64/libc.so.6¬0x22672dc| /lib64/libc.so.6(cfree+0x88)¬0x2268fa4| /init¬0x80036084| /init¬0x800215b4| /init¬0x80021e86| /init¬0x80007400| /init¬0x800086f8| /init¬0x8001b9a8| /init¬0x8001c3f8| /lib64/libc.so.6(__libc_start_main+0x108)¬0x22070a0| /init¬0x80005e32| This appears to be a known problem which is tracked in Novell Bugzilla 494301 (https://bugzilla.novell.com/show_bug.cgi?id=494301). Unfortunately the entry does not mention a fix. Regards, Peter Oberparleiter -- 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
Re: sles11 zipl multipath /boot problem
Mark Post wrote: I'm not sure how to react to Peter's email. If zipl hasn't been updated to deal with MPIO, then I don't understand how the IPL through IFCC feature is supposed to work. IPL through IFCC refers to a minor improvement in the way IFCCs are handled during the very early stage of booting: when some HW models detect an IFCC during IPL, they will retry the operation on another channel-path. The zipl change only makes sure that the same path is used for subsequent I/Os until the kernel is loaded. Before that, zipl would just fail when encountering an IFCC on the first path. Now it will only fail when it encounters an IFCC on the path that worked before :) Note that there is more work currently being done in zipl and Linux to improve I/O error recovery during the boot phase. Regards, Peter Oberparleiter -- 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
Re: sles11 zipl multipath /boot problem
Romanowski, John (OFT) wrote: But on sles 11 zipl will accept multipath LUN and reports Target device information Device..: fd:0a Device name.: dm-10 Device driver name..: device-mapper Type: disk device Disk layout.: SCSI disk layout Geometry - heads: 0 Geometry - sectors..: 0 Geometry - cylinders: 0 Geometry - start: 0 File system block size..: 4096 Physical block size.: 512 Device size in physical blocks..: 64260 ... and .. Preparing boot device: dm-10. Detected plain SCSI partition. Writing SCSI master boot record. Syncing disks... Done. I think the disk geometry of 0's looks suspicious. This appears to be a bug in zipl. The SLES11 version of zipl does not contain any code to support writing IPL records to multipath devices. Consequently zipl should abort with the same message as in SLES10. I'll have a look into this. As for the actual multipath/logical volume support for zipl: that code has not yet been released as it is currently in testing stage. Regards, Peter Oberparleiter -- 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
Re: 3270 input to zipl boot menu
Brian Nelson [EMAIL PROTECTED] wrote on 22.03.2006 16:29:16: I can log in, issue linux commands, etc. However, when I'm at the bootloader menu prompt, the script has no effect and I'm unable to load a non-default kernel or pass boot parameters. Did you make sure to prefix boot loader prompt input with '#cp vinput vmsg' (see man zipl.conf)? Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: 3270 input to zipl boot menu
Coffin Michael C [EMAIL PROTECTED] wrote on 22.03.2006 19:04:58: Actually, Brian and I are working on this together - CP is actually getting the VINPUT command but evidently doesn't know how to pass it to the Linux OS, we get: HCPPCX6531E The operating system will not accept commands from the service processor. This message indicates that the input to the boot loader prompt was not sent using the cp vi vmsg command. I'm not familiar with the cp send command, but did you implement David Kreuter's suggestion of using send cp linuxvm vi vmsg 0 instead of send linuxvm vi vmsg 0 ? Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SuSE 9 64-bit, SWAP, and DIAG driver
Tom Shilson [EMAIL PROTECTED] wrote on 08.03.2006 17:27:21: I have just installed SuSE SLES 9 on zVM 5.1. It is Service Pack 0 but fully patched. It is not finding the vdisks that I allocated for swap. Googling around seems to indicate that it won't work on 64-bit, although there is a private patch that does make it work. Does someone have the latest status on this? I don't know about that 'private patch', but: z/VM 5.2: Block I/O (Diagnose X'250'): Extended to allow a virtual machine to specify parameter addresses and I/O buffers with addresses above 2 GB. This will benefit operating systems that use DIAGNOSE code X'250' in a 64-bit environment. IBM is working with its Linux distribution partners to exploit this function in future Linux on System z9 and zSeries distributions or service updates. (http://www.vm.ibm.com/pubs/HCSF8B10.PDF) Linux 2.6.14: Add support for diag 250 access to dasd devices for 64 bit kernels. (http://www.ussg.iu.edu/hypermail/linux/kernel/0508.3/1218.html) SLES9 (including latest service packs) does not include this Linux support though. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Can SLES8's zipl dump tool be used with SLES9 too?
Romanowski, John (OFT) [EMAIL PROTECTED] wrote on 06.01.2006 19:43:34: But can the same dasd dump tool be used to dump either release of SLES? Do I have to use SLES8's tool to dump a SLES8 and SLES9's to dump a SLES9? You can use the zipl dump tool from either SLES8 or SLES9 to dump both types of systems. The dump tool itself does not have any dependency on the Linux version of the system to be dumped. It is advisable to use the newer dump tool though (i.e. SLES9) to benefit from the latest bug fixes and features. Note also that you can use the dump tool installed by a 64 bit (s390x) system to dump 31 bit (s390) systems. The other way around is not possible though, i.e. trying to dump a 64 bit system on a dasd on which the dump record from a 31 bit system is installed will produce unreadable dumps. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: SLES9 - yast - Patch CD Update
Bruce Hayden [EMAIL PROTECTED] wrote on 02.12.2005 14:23:16: If the loopback driver is built into the kernel, then pass the kernel parameter max_loop=nn to increase the number of loopback devices. If the driver is a module, then pass that parameter to the module. I have a PC with various SUSE and Red Hat iso images mounted using 52 loop devices. Wow, I totally missed this option. Thanks for pointing this out! Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: LPAR only Linux
[EMAIL PROTECTED] wrote on 09.07.2005 02:20:17: We are upgrading our system to a z890 (and getting a new HMC) which is now installed and running on the old hardware a z800. I see a new feature (Integrated Ascii Console) and I have been searching for a redpaper or existing e-mail archives from this list on how to cofigure so I can use this console to work with Linux instead of the horrible existing HMC single line mode interface. Can someone point me to documentation or some instructions about how to get this interface to work. Now when I click on the icon on the HMC I just gat a blank window with no text and I cannont type anything into it. Please see the Linux on zSeries Device Drivers, Features and Commands document at http://www-128.ibm.com/developerworks/linux/linux390/april2004_documentation.html chapter 18: Console device drivers, sub-chapter Setting up a full-screen mode terminal. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Need Help adding new DASD Devices
I wrote: mke2s /dev/dasdaa1 If not present, the respective device files (/dev/dasdaa1-4) need to be created for all partitions as well. Ah, two small corrections: the tool name is mke2fs mke2fs /dev/dasdaa1 Additionally, it's only 3 partitions, i.e. /dev/dasdaa1-3. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Using ssh to execute a command on another system
What I am looking to do is to ssh to a specific linux, execute a command, capture the output of that command, parse that output and set some variables and write out a 'status page' html file. I do not know how to handle being asked for a password in a shell script. I've seen some stuff about the identity file, but that really isn't making sense to me either and certainly seems like overkill for what I'm doing. Try using a private/public key pair without pass phrase: 1. Generate a key pair (press enter if the tool prompts for input) ssh-keygen -t dsa 2. Append public key to list of authorized keys for user on remote cat .ssh/id_dsa.pub | ssh [EMAIL PROTECTED] ( mkdir -p .ssh ; cat .ssh/authorized_keys )` 3. Log in/execute commands without password prompt ssh [EMAIL PROTECTED] ls Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Problems using SIGNAL SHUTDOWN
Tobias Doerkes [EMAIL PROTECTED] wrote: 01: HCPGIR450W CP entered; disabled wait PSW 00020001 8000 0FFF 02: HCPGSP2629I The virtual machine is placed in CP mode due to a SIGP stop from CPU 02. 01: HCPSIG2112I Signal timeout interval has expired Is somebody out there who can tell me why this stupid guest does not logoff ? The order in which the CPUs are stopped by Linux is invalid - the FFF PSW should be loaded last. VM therefore does not recognize the completion of the signal shutdown handling. There was a bug in Linux 2.4 code that was fixed in November 2003 which could cause such behavior (see http://www10.software.ibm.com/developerworks/opensource/linux390/linux-2.4.21-s390-07-june2003.shtml). Depending on the kernel level you are using this may be the source of your problem. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: S.O.S. - disk full
Istvan Nemeth [EMAIL PROTECTED] wrote: The root filesystem seems to be full, but it's NOT! We have 2.4.19-3suse-SMPkernel and a 2G disk for /, about 1G free (du tells me, and I'm sure), and the /var or /tmp is also less then 100M This sounds as if you deleted a file while a process was still accessing it. In that case its directory entry will be deleted while the allocated disk space will only be freed after the process closed the respective file handle. When you are deleting files from /var and /tmp, make sure that you stop the process accessing it first. You may also want to find out why a process is generating so much data (check error logs, etc.). Hope this helps. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: S.O.S. - disk full
Istvan Nemeth [EMAIL PROTECTED] wrote I'm not deleting files from /var and /tmp... and what is when I'm DELETING from an NFS file system and then _MY_ root fs gets full?? If you can, try to restart the NFS service and see if the situation improves. If that doesn't help, try restarting some of the other services running on your system. That's all the advice I can think of at the moment. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: Fwd: Bug#281394: env2debconf doesn't work on s390
Adam Thornton [EMAIL PROTECTED] wrote: This just in from d-i. Anyone here know anything about why the kernel doesn't set environment variables from the command line? Begin forwarded message: PPID='167' Command line environment variables are only passed to the init process (PPID=0). It should work if you retry the test using the following command line: ro foo=bar init=/bin/bash Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: zipl boot menu
Post, Mark K [EMAIL PROTECTED] wrote: [...] instead it just immediately boots the default kernel. My /etc/zipl.conf *cough*man zipl.conf*cough* If the 'prompt' setting of the menu section is set to 1, a menu text will be displayed during IPL and the boot program will wait for user input: [...] If the 'timeout' option has been used, the boot menu will automatically start the default configuration after the specified number of seconds has passed without user input. [...] The loadparm function is available even if the menu has been deacti- vated by setting 'prompt' to zero or by installing only a single con- figuration. The menu can then be temporarily activated by passing the string 'prompt' via the loadparm function: #cp ipl 0192 loadparm prompt Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: zipl boot menu
Post, Mark K [EMAIL PROTECTED] wrote: I did read the man page, several times. I should have mentioned that I'm using s390-tools 1.2.4. The text you quote does not appear in the man page at that level. If I try to specify either prompt or timeout in the menu section, zipl complains about an unknown keyword, and won't run. So, any advice as to how to get this to work with 1.2.4? Unfortunately not. Boot menu support was only added in s390-tools version 1.3.0. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: zipl boot menu
Post, Mark K [EMAIL PROTECTED] wrote: Then let me register a retroactive complaint, for future reference. Don't put things in the man page that aren't supported in the software. It only confuses people, and wastes a lot of time, both on their part, and the mailing list. I'll install 1.3.0 and see if I have better luck there. While I admit that the wording of the respective man-pages is somewhat vague, I don't agree with your statement that the man page describes a feature which is not supported by the software: The man page of zipl versions 1.2.0-1.2.4 contain references to a feature which allows specifying multiple boot configurations with the addition that: If supported by the hardware, an interactive choice of these configurations will be available at boot time, otherwise the menu's default entry is booted. Hardware support in this context refers to the extended HMC panel used during IPL from SCSI devices. This panel contains an extra input field that can be used to specify a non-default boot configuration. I guess it's this section together with the ambiguity of the term menu that caused the misunderstanding (I'll try to keep the text more clearer in the future). Anyway, I hope that with the new version, the feature works as expected for you. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: IPTables
Bob [EMAIL PROTECTED] wrote: I happen to be using an httpd server on system B and if I look in the logs when the packets come through system A, I see the IP address of system X so the packet ends up on the default route which for system B which is system A and that works fine. When I do that same thing putting the address of system C in the browser, I get nothing in the logs. But I do see the count on the iptables display go up by 1 on system C This means that you would need to enable the SNAT rule (see my previous post, needs modification to match the IP address of C instead of A) on C. As a downside, the HTTPD logs would show C as the source for requests which are forwarded by C. Maybe have a look at the book that Adam Thornton suggested if you want a more sophisticated solution. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: IPTables
Bob [EMAIL PROTECTED] wrote: There happen to be several of these exact lines for different ports and none of them seem to be working... LOGtcp -- 0.0.0.0/0159.166.1.69 tcp dpt:8994 LOG flags 0 level 4 DNAT tcp -- 0.0.0.0/0159.166.1.69 tcp dpt:8994 to:159.166.4.137:8994 I'll assume that you're trying to implement this scenario: X - A (159.166.1.69) - B (159.166.4.137) If you are testing this port redirection by starting a connection from A, you'll need to add the DNAT rule to the OUTPUT chain as well as local packets don't pass the PREROUTING chain. If the default gateway for packets sent from B to X is not A, B will try to reply to X directly which will then become confused as X talked to A before. To prevent this, you'll have to add a SNAT rule as well: $IPTABLES -t nat -A POSTROUTING -p tcp --destination 159.166.4.137 \ --dport 8994 -j SNAT --to 159.166.1.69 Also make sure that packets are not blocked by the FORWARD rule and, as Rob already pointed out, that you have switched ip_forwarding on. In case you're still experiencing problems, use the following commands to see the packet count for each rule that matched - this way you can try to understand what is happening within netfilter: iptables -L -v iptables -t nat -L -v Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: VM Shutdown
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 be: it depends:) First it should be noted that zipl does not perform any kind of check on the actual contents of the kernel command line (it couldn't - only the kernel itself knows about its parameters). All it does is pass the concatenated text string to the kernel. During IPL, the kernel startup routine parses the command line left to right, evaluating each keyword or keyword/value pair and looking for routines to handle each keyword. Parsing is handled by a generic mechanism so there's no checking for conflicting input done either. Only the routines which are used for keyword handling interpret the actual parameters. As each device driver/kernel component implements its own routines, there's no defined standard behavior on how to handle conflicting information. Example: 'dasd=' parameter: defines which DASD devices are automatically activated during IPL. Specifying this keyword multiple times will extend the list of devices. 'mem=' parameter: specifies how much main memory Linux should try to use. Specifying this keyword multiple times will override previous occurrences so that only the last one will be used. To sum it up, there's no universally applicable way of telling what will happen if keywords on the kernel command line provide conflicting information. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: VM Shutdown
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 the next round of updates, maybe? Seems reasonable (-t0, anyone..?:). I'll consider including a respective parameter in a future version of zipl. Still this would not cover situations where (extra) parameters were specified on the command line. Once an IPL record is written, there is no universal way to restore the exact original configuration - the boot loader code only gets told to load 'these blocks to that memory location'. There's no information contained as to what the meaning of the data is (parmfile, kernel, initrd). I also do not want to introduce external dependencies on the format of the internal bootmap file. 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. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: VM Shutdown
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' tool. I'm mostly concerned with the problem of assessing something that may already be in place where something weird has been done that didn't make it into zipl.conf for some reason. Sounds like there's no nice way to do that. Would it make sense to force updates into zipl.conf and gradually remove the cmdline arguments? 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 there is a need to test new or different parameters, simply define a new multiboot configuration, experiment with that and get back to the working configuration if anything bad happens. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: VM Shutdown
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 know that a bunch of files must be copied to implement a change, we find it helpful to run an additional check to verify that is has been done completely (and when possible have someone else do the check). I am sure many others also have a program to compare two CP load maps and eyeball the differences before an IPL (or after one that failed ;-) 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 multiboot feature to be able to switch back to a working one. 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 into the bootmap file wouldn't be too hard, but I don't like the implications: zipl would need to be able to read bootmap files, put a version tag on the current format, make sure to identify files written by previous versions with no or different information. Once external tools access this file, there's no way to change the file format without causing chaos with users of that tool. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: VM Shutdown
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 that was -t 0 (the default). -t 2 was the opposite, i.e. something like '--now-for-real'. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: VM Shutdown
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 contents. If you just want to have an idea of what parameters are currently written, use 'strings /boot/zipl/bootmap' and look for lines which resemble kernel parameters (there may be multiple lines if you're using a multiboot configuration). If you want to know the parameters for the currently running system, use 'cat /proc/cmdline' (though that would include the temporary parameter 'BOOT_IMAGE' generated by the boot loader code during IPL). If you want to know the resulting parameters for the current zipl configuration, use 'zipl -V' (the IPL record will be updated though). Hope this helps. Regards, Peter Oberparleiter -- Peter Oberparleiter Linux on zSeries Development IBM Development Lab, Boeblingen/Germany -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: 2.6 device node help
Richard Troth wrote: Adam Thornton wote: OK, so, am I on CRACK or does the Linux 2.6 device drivers book say to create 4,64 ? I don't think you're on crack, but the book might be. 4,64 is a UART class serial line. Not likely your zSeries will have that. But all HW have 5,1 console. On zSeries, the 3215 terminal device driver (VM) and the SCLP line-mode terminal driver (LPAR) are implemented as ttyS0 (4,64). Device number (5,1) is the console terminal device (commonly /dev/console) which is required by the init process for input/output. The following should fix the problem: mknod /dev/console c 5 1 Regards, Peter Oberparleiter -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: I updated zipl.conf incorrectly :(
Ken Vance wrote: Is there a way of overriding the command line and inserting the correct line? Even if we update the original file, we would still be stuck since the zipl command writes it to the boot area. Do we need to bring up the RAM image and rebuild the boot area? You need to run the zipl command on the respective disk to rebuild the boot area. Note that this can be done from another Linux system as well by doing the following: 1. mount the disk in question 2. chroot mountpoint 3. zipl or using the zipl command line parameters: 1. mount the disk in question 2. zipl -t mountpoint/boot -i /mountpoint/boot/image -p /mountpoint/boot/parmfile (filenames may vary depending on distribution) Note also that starting with the zipl version contained in the s390-tools 1.3.0 package, there is an interactive boot menu available which can be used to select an alternate configuration or to append additional parameters to the kernel command line at boot time (see respective zipl man pages). Regards, Peter Oberparleiter -- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
Re: 2004-03-01 Recommended Linux for zSeries documentation drop to developerWorks
Adam Thornton wrote: Which version of zipl is required in order to get the -s parameter? Support for segment load through zipl's -s parameter was first included in s390-tools version 1.2.0. Online documentation was added in version 1.2.4 (current). Regards, Peter Oberparleiter
Re: SLES8 trap signal shutdown
Hall, Ken (IDS ECCS) wrote: I had to add the ctrlaltdel line to /etc/inittab. I also made a modification to the /etc/init.d/halt script to issue hcp logoff at the end. For some reason, the options in zipl.conf caused me problems, but I forget exactly why. To clear this matter up a bit, here is a quick description of how the signal shutdown facility in Linux works: - any guest running a Linux kernel compiled with CONFIG_SCLP enabled is listening for a 'signal shutdown' - once a 'signal shutdown' is received by Linux, the ctrlaltdel action is triggered - Linux will call the command defined in /etc/inittab for ctrlaltdel. This should be a 'shutdown' command. - after the shutdown command has finished, Linux will signal completion of 'signal shutdown' processing. - the system that issued 'signal shutdown' will log off guests that signalled the completion of 'signal shutdown' processing - any system which is signalled but does not signal completion after a timeout interval (if specified) will be forced to log off I recommend the following approach: 1) add an entry for 'ctrlaltdel' to /etc/inittab. The associated command should be a 'shutdown' command. 2) do not modify the init scripts as this will prevent the kernel from signalling completion of 'signal shutdown' processing 3) do not specify 'vmpoff' or 'vmhalt' commands as these will be ignored Hope this helps. Regards, Peter Oberparleiter
Re: 2003-09-18 Linux for zSeries code drop to developerWorks
Hello, Mark Post wrote: Well, I didn't see anything in here that would address the compilation error in ctrlchar.c when CONFIG_MAGIC_SYSRQ is not set. Is anyone looking at that? sorry for the delayed response - that error has been taken care of by now and will be fixed in a future update. Thanks for pointing it out! Regards, Peter Oberparleiter
