Re: [Stretch] Status for architecture qualification
On Tue, Jun 14, 2016, at 18:37, Dimitri John Ledkov wrote: > > There is openmainframe project https://www.openmainframeproject.org/ , > which I believe offers access to z/VM instances hosted by Marist > colledge. > > At the openmainframeproject EU meetup, it was indicated that SUSE > joined with indication that Open Build Service might be able to use > resources hosted by Marist. > > I wonder if it makes sense to reach out, and see if there are > resources available to use as porter boxes & build boxes. That way > Debian might be able to get such donated resource available on ongoing > basis and hopefully with some hw support. > Of course, there's always Hercules. Real hardware is always better of course. But then again, strictly speaking, A z/VM instance is a virtual machine, running under z/VM. And z/VM is running in an LPAR, which is essentially a virtual machine running under PR/SM. And the physical machine behind those (at least) two levels of virtualization doesn't really have the same hardware architecture as a virtual machine, such as physical chpids vs. logical chpids and logical channel subsystems, etc., defined by HCD/HCM or IOCP. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Upgrading the minimum required s390x CPU to z10?
On Wed, Jun 1, 2016, at 11:39, R P Herrold wrote: > > IBM upstream has moved the 'enterprise' distributions to the > even later z196 level about three years ago, via the -march > option. They made no secret of their intention to 'end the > life' of earlier hardware main-line support, even if it was > not well communicated outside of 'enterprise' circles > > One could speculate why, but ... why bother. Chopping off the > legacy tail gets rid of easy conversions and substitution > replacement by Hercules rather than zPDT, and so drives more > of the remaining 'paying customer' pot either off of Z (to > Power, or distributed) Less than a year ago, I reported a problem to IBM regarding a kernel crash on pre-z10 processors, and they produced a fix for it. (See https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/patch/?id=0b991f5cdcd6201e5401f83ca3a672343c3bfc49.) So, for Linux they are still supporting the entire z/Architecture line. Of course, it's no secret that they want their customers to keep buying their newer models every few years. For their own proprietary 64-bit operating systems, such as z/VM, they start cutting off older hardware. We still run z/VM 5.4.0 because it is the last release of z/VM that still supports our z/890. Starting with z/VM 6.1.0, a z10 or newer is required. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Upgrading the minimum required s390x CPU to z10?
On Tue, May 31, 2016, at 18:25, Aurelien Jarno wrote: > > That's indeed the right way to do it (and to fix the issue), but the > point is that developers using GCC defaulting to z10 or higher don't > realize they can't use the corresponding instructions, so that has to > be fixed later. Latest example is openssl. > Hmm. I see two possibilities here. (1) The source code package uses a GCC option that specifies that the compiled object code is to run on a z10 processor. The fix here is rather simple and straightforward: change the GCC option to specify a z800/z900, then re-build the package. The compiler will now generate object code that is compatible with all z/Architecture processors. (2) The so-called "C" source code bails out to assembly language in places, and some instructions are used which aren't supported on a z800/z900. (I've mainly seen this in s390-specific kernel modules.) In this case, the fix is more involved. You have to find the offending code, insert a facility check to make sure the instruction is supported first, then decide how to handle the case where it isn't. This is much more labor intensive. Which case are you talking about? (I must confess that I haven't looked at the source code for openssl.) -- .''`. Stephen Powell : :' : `. `'` `-
Re: Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
On Mon, May 23, 2016, at 22:16, Ben Hutchings wrote: > On Mon, 2016-05-23 at 21:06 -0400, Stephen Powell wrote: >> >> The following message is received at boot time when booting the stock Debian >> kernel >> version 4.5.3-2 on the s390x architecture: >> >> dasd_mod: module verification failed: signature and/or required key missing >> - tainting kernel > > This is expected until we sort out support for loading signed modules > in unstable. > I've done a little research on this. I haven't checked other architectures, but the stock s390x kernel for 4.5.3-2 (and today I also tried 4.5.4-1) has CONFIG_MODULE_SIG=y # CONFIG_MODULE_SIG_ALL is not set This seems to be the problem. From what I've read, If CONFIG_MODULE_SIG=y, but CONFIG_MODULE_SIG_ALL is not set, then the modules need to be manually signed via scripts/sign-file between the "make modules" and "make modules_install" phases of the build process. But automated tools for building debian kernel packages, such as make-kpkg from kernel-package, "make deb-pkg", and I presume the tools you use for building stock kernels as well, do not allow this manual signing step to take place. I have been able to build a successful kernel using make-kpkg with both of the above options not set, as well as with both of them set to y. But the combination of options currently used in the stock kernel is problematic for these tools. -- .''`. Stephen Powell : :' : `. `'` `-
Bug#825141: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel
Package: linux Version: 4.5.3-2 Severity: minor X-Debbugs-CC: debian-s390@lists.debian.org The following message is received at boot time when booting the stock Debian kernel version 4.5.3-2 on the s390x architecture: dasd_mod: module verification failed: signature and/or required key missing - tainting kernel The kernel does boot; but the kernel gets tainted, which disables lock debugging. -- .''`. Stephen Powell : :' : `. `'` `-
Bug#801913: init-premount boot script is now superfluous
Package: sysconfig-hardware Version: 0.0.10+nmu3 Severity: wishlist X-Debbugs-CC: debian-s390@lists.debian.org Now that sysconfig-hardware brings DASD devices online before the permanent root file system is mounted, the script usr/share/initramfs-tools/scripts/init-premount/sysconfig_hardware is superfluous. It is no longer needed. It should be dropped from the package. That's one less piece of code to maintain, and one less item that needs to be included in the initial RAM file system image file. -- .''`. Stephen Powell : :' : `. `'` `-
Bug#801912: DASD options are ignored because device is already online
Package: sysconfig-hardware Version: 0.0.10+nmu3 Severity: normal X-Debbugs-CC: debian-s390@lists.debian.org Tags: patch The DASD options are being ignored. The problem is in etc/sysconfig/scripts/hardware/hwup-ccw-dasd. The DASD options can only be set *before* the device is brought online. The script is attempting to set the DASD options *after* bringing the device online. Thus, the DASD options are ignored. A patch which fixes the problem is attached. -- .''`. Stephen Powell : :' : `. `'` `-diff -ura a/etc/sysconfig/scripts/hardware/hwup-ccw-dasd b/etc/sysconfig/scripts/hardware/hwup-ccw-dasd --- a/etc/sysconfig/scripts/hardware/hwup-ccw-dasd 2015-09-06 03:38:33.0 -0400 +++ b/etc/sysconfig/scripts/hardware/hwup-ccw-dasd 2015-10-15 14:26:51.819975570 -0400 @@ -15,18 +15,17 @@ message_n "Configuring device $ID: " read _online < $SYSFS$DEVPATH/online if [ "$_online" -ne "1" ]; then + if [ -n "$DASD_USE_DIAG" ]; then +echo "$DASD_USE_DIAG" > $SYSFS$DEVPATH/use_diag + fi + if [ -n "$DASD_READONLY" ]; then +echo "$DASD_READONLY" > $SYSFS$DEVPATH/readonly + fi echo 1 > $SYSFS$DEVPATH/online message_n "online. " else message_n "already online. " fi -if [ -n "$DASD_USE_DIAG" ]; then - echo "$DASD_USE_DIAG" > $SYSFS$DEVPATH/use_diag -fi -if [ -n "$DASD_READONLY" ]; then - echo "$DASD_READONLY" > $SYSFS$DEVPATH/readonly -fi - message "ok. "
python3-minimal (3.4.3-4) fails configuration under Hercules
Here's a "heads up" for those of you who are running Debian under Hercules. I recently did an "apt-get upgrade" for my stretch (testing) system under Hercules, and it failed configuration with this error: - Setting up python3-minimal (3.4.3-4) ... Traceback (most recent call last): File "/usr/bin/py3compile", line 34, in from debpython.version import SUPPORTED, debsorted, vrepr, \ File "/usr/share/python3/debpython/__init__.py", line 2, in from datetime import datetime File "/usr/lib/python3.4/datetime.py", line 633, in microseconds=99) File "/usr/lib/python3.4/datetime.py", line 408, in __new__ assert abs(microseconds) < 3.1e6 AssertionError dpkg: error processing package python3-minimal (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: python3-minimal E: Sub-process /usr/bin/dpkg returned an error code (1) - I spent the weekend trying to resolve this. The bottom line: there is a bug in Hercules itself. The version of Hercules currently packaged for Debian, 3.07, has a bug in the emulation of the s390x hardware which causes configuration of the above package to fail. I downloaded Hercules 3.11 directly from upstream, compiled it from source, and installed it. The above error disappears under Hercules 3.11. The bottom line: We really need a new hercules package for Debian! -- .''`. Stephen Powell : :' : `. `'` `-
Re: Adding DASD to a Debian guest
On Sat, 19 Sep 2015 18:15:16 -0400 (EDT), Philipp Kern wrote: > > On Sat, Sep 05, 2015 at 05:12:30PM -0400, Stephen Powell wrote: >> No. The hook script was written by me years ago, and I put it in the >> bug report, but it was never incorporated into the official package. > > You were of course right all along. I'll add the hook script to the > package ASAP (I just tested it). WAIT_FOR_SYSFS probably has to go, > because it's long deprecated, so I'll retry testing without it. But > apart from that it works. > > Root on LVM should work afterwards as long as you have /boot outside > of it (zipl requirement). It requires another patch to zipl-installer to > make it work, but I have and tested that part already. (Essentially > taken from lilo-installer.) > Another thing I would check on, both in zipl-installer and lilo-installer, is to make sure that the /boot partition, whether it is a separate partition or whether it is included in /, is not formatted with the btrfs file system. I'm pretty sure that neither boot loader supports btrfs. Only boot loaders which have file system drivers, such as grub and extlinux, support btrfs, IIRC. Neither lilo nor zIPL understand the format of the file system and require files to be in the "extent" format. Furthermore, I don't believe that btrfs supports "mapping" a file to physical blocks. Note that if /boot is a separate partition, then / can be btrfs; but if /boot is included in /, then / cannot be btrfs. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Adding DASD to a Debian guest
On Sat, 05 Sep 2015 13:56:07 -0400 (EDT), Philipp Kern wrote: > > As much as I dislike sysconfig-hardware, it's probably the thing we > should do: Include a hook script that includes enough of > sysconfig-hardware to bring up hardware early in the initrd. (Best to > not fail if any of it is missing at this point. Debugging from within > the initrd is awkward.) I don't dislike sysconfig-hardware, per se, but I do dislike the lack of documentation. It was apparently written by SUSE. They used it themselves for a while, then abandoned it. (I don't know what they put in its place.) Furthermore, the version we use differs from the version SUSE last used in several ways, including naming conventions. So for all practical purposes, Debian is now its own "upstream" for sysconfig-hardware. So we can do whatever we want to with it. > > I was under the impression -- mostly because of the presence of the > mentioned hook script -- that this already happened. No. The hook script was written by me years ago, and I put it in the bug report, but it was never incorporated into the official package. > > The route SUSE > went with running grub2 from a kernel image booted by zipl and then > kexec()ing into the right kernel and initrd is a bit too much, though. I agree. -- .''`. Stephen Powell : :' : `. `'` `-
Re: [OT] Re: Hercules - how to get a zVM OS (legally bought!) and put it on a VM under Hercules?
On Sat, 05 Sep 2015 13:40:27 -0400 (EDT), Philipp Kern wrote: > > What is the canonical place to get new Hercules releases from? > It's neither http://www.hercules-390.org nor > https://github.com/hercules-390/hyperion http://www.hercules-390.eu -- .''`. Stephen Powell : :' : `. `'` `-
Re: Possible bug in GCC 5, need help
On Mon, 31 Aug 2015 07:12:10 -0400 (EDT), Andreas Krebbel wrote: > > I've bisected the problem. It occurred first with: > > commit 90f3e775d6b7bec70e883579beb49b456c135a09 > Author: wmi > Date: Thu Jan 22 17:59:23 2015 + > > 2015-01-22 Wei Mi > > PR rtl-optimization/64557 > * dse.c (record_store): Call get_addr for mem_addr. > (check_mem_read_rtx): Likewise. > > With this patch an stc (store character) is dropped by the DSE pass > (dead store elimination). I'm currently auto-reducing the testcase > to start debugging. I'll open a GCC BZ with the reduced testcase. You beat me to it. Thanks, Andreas -- .''`. Stephen Powell : :' : `. `'` `-
Re: [OT] Re: Hercules - how to get a zVM OS (legally bought!) and put it on a VM under Hercules?
On Tue, 25 Aug 2015 19:17:27 -0400 (EDT), Philipp Kern wrote: > ... > Technically using Hercules is probably your best bet[*]. It should be able > to do MIPS similar to your existing z800 on contemporary x86-64 hardware. > (You'll certainly know for how many MIPS your existing machine was > sized and Hercules does display them.) You might need to be careful with > relation to I/O, of course. > ... Aye, there's the rub. CPU emulation is slow, but I/O emulation is really slow. But I'm looking forward to Hercules 4.0, which promises an I/O subsystem restructure, which should help in that regard. Incidentally, the version of Hercules currently packaged for Debian, 3.07, was released by upstream more than five years ago. There have been many enhancements, performance improvements, and bug fixes since then. I'd love to see the Debian hercules package updated. The current production upstream release is 3.11, released on September 15, 2014. 3.07 was released on March 10, 2010. -- .''`. Stephen Powell : :' : `. `'` `-
Bug#797023: Linux kernel FTBFS error for ARCH=s390, CONFIG_SMP=n, and CONFIG_DYNAMIC_DEBUG=y
Package: linux Version: 3.16.7-ckt11-1+deb8u3 Severity: minor X-Debbugs-CC: debian-s390@lists.debian.org Tags: patch The Linux kernel in jessie fails to build from source for the combination ARCH=s390, CONFIG_SMP=n, and CONFIG_DYNAMIC_DEBUG=y. Compilation of drivers/s390/char/sclp_early.c fails with a number of undefined symbols. The problem also exists in the stretch and sid kernels at the time of this writing. The following patch fixes the problem for all three kernel versions: https://git.kernel.org/cgit/linux/kernel/git/s390/linux.git/patch/?id=a313bdc5310dd807655d3ca3eb2219cd65dfe45a -- .''`. Stephen Powell : :' : `. `'` `-
Re: Hercules - how to get a zVM OS (legally bought!) and put it on a VM under Hercules?
On Sat, 22 Aug 2015 11:52:19 -0400 (EDT), Dave Jones wrote: > > You will need to go talk with IBM about obtaining a proper license to > run their software (z/VM, z/OS) on your Hercules ssytem. > ... Dave, (1) I basically already said this (2) Please trim your posts! (3) Please don't top-post Respectfully, -- .''`. Stephen Powell : :' : `. `'` `-
[OT] Re: Hercules - how to get a zVM OS (legally bought!) and put it on a VM under Hercules?
On Sat, 22 Aug 2015 05:25:02 -0400 (EDT), Christian Boitet wrote: > > sorry if this goes to the wrong group... > if so, please give us a better pointer. This is a forum for those running the s390x port of Debian. How to run Debian under Hercules would definitely be on-topic here, since Hercules is a software emulation of the hardware on which Debian for s390x was designed to run. If your question regards how to run Debian in a virtual machine under z/VM, that would also be on topic. But questions about how to run z/VM under Hercules are not on topic. I would suggest the Hercules forums on Yahoo, specifically, https://groups.yahoo.com/neo/groups/H390-VM/info > > We have a z800 with zVM 5.3.0, and under it several Linux/390 (Debian) > virtual machines, and a special VM that runs zVM 4.2.0 and under it a > legacy system made of 100 or more VMs, all under CMS, plus of course > all service VMs. > > We have bought the 4.2.0 system "one shot" back in 2001 and have been > entitled to all following releases, including the 5.3.0. > > Now, this z800 is a burden, the processor went dead last year and we > had to find a second-hand one... > > In short, we would like to put all our configuration under Hercules, > preferably on a Macintosh under Yosemite. > > Our problem is: how to get our OSs (zVM 530 and zVM 420) from our > machine and install them under Hercules? > > Thnks in advance for any help! Although this question is, strictly-speaking, off topic, I suspect that it is of interest to many of the subscribers to this list, so I'll answer it anyway. I need to start by saying that I am not a lawyer, an IBM employee, or an official spokesman for any person, company, or government. As I see it, there are three sides to this question: the practical side, the legal side, and the technical side. I will address them in that order. First, the practical side. Hercules is a software emulation of a mainframe, not a real mainframe. It adds a tremendous amount of overhead. Debian under Hercules under amd64 is *way* slower than Debian running directly under amd64 using the same hardware. I suspect you will find that the performance of your z/VM systems is not adequate for production use, even when Hercules is running on the fastest amd64 processors available. But the only way to find out is to try it, I suppose. Next is the legal side. As I said, I am not a lawyer. But if you check the fine print in your contract, you may find that you did not, strictly speaking, *buy* z/VM. What you probably did was *license* z/VM. Typically, this license is good for a single mainframe box. The license is typically not transferable to another box without a contract modification. IBM typically does not license their proprietary 64-bit mainframe operating systems, such as z/VM, to run on anything other than IBM hardware. I'd have your legal department go over this very carefully, if I were you. I'd hate to see you get in legal trouble for running z/VM on a processor for which you are not licensed. Finally, there's the technical side. There are a number of ways to migrate the data. One way that I can think of is to use DDR to create a volume dump, convert the real tape file to an AWS emulated tape file, create a DDR stand-alone IPL tape, convert that to an AWS emulated tape file, Then IPL the DDR stand-alone IPL tape under Hercules using the AWS emulated tape file, and use the stand-alone version of DDR to restore the dumped volume from its AWS emulated tape file to a Hercules volume. That's one way to do it. Perhaps the folks on the above Yahoo group know a better way. Regards, -- .''`. Stephen Powell : :' : `. `'` `-
Re: Hercules - Error: undefined configuration on first boot after installation
On Thu, 20 Aug 2015 12:03:00 -0400 (EDT), C. Thomas Stover wrote: > > Anyone have any ideas on this? Install seemed to work ok. > ... > Error: Undefined configuration > ... This looks like an error from zIPL. It doesn't like your LOADPARM. It is interpreting the LOADPARM as the menu item number for a kernel to boot. I suggest leaving LOADPARM blank. But since you are running Debian under Hercules, you might find the following web page useful: http://users.wowway.com/~zlinuxman/hercules.htm -- .''`. Stephen Powell : :' : `. `'` `-
Re: Possible bug in GCC 5, need help
On Sat, 15 Aug 2015 05:44:42 -0400 (EDT), Mike Hommey wrote:
> ...
> The current version of Iceweasel in unstable fails to build because of
> an internal error in the javascript engine which looks like it could be
> caused by some miscompilation.
> ...
> I was able to narrow it down as follows:
> ...
> - Building js/src/Parser.o with a #pragma GCC optimize("O0") at the
> beginning fixes it.
> - Then I was able to go down at the function level, whereby moving the
> following function at the end of the file and preceding it with the
> pragma above fixes it:
> template <>
> /* static */ bool
> Parser::bindLexical(BindData* data,
> HandlePropertyName name,
> Parser* parser)
>
> (somehow, adding a #pragma GCC optimize("O3") after a O0 one doesn't
>raise optimization level for the rest of the file, what's why I
>double checked by moving the function)
>
> Could someone with s390x assembly knowledge look at the assembly for
> that function and narrow it down further, possibly filing a GCC bug?
If you will produce a compiler listing that shows the generated machine
language and pseudo-assembly language for the problem piece of code,
both for the good case and the failing case, and send me a link to it,
I'll take a look at it. I can't promise you success, but I'll look at it.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
Bug#795954: sysconfig-hardware contains various syntax errors in "case" commands
Package: sysconfig-hardware
Version: 0.0.10+nmu1
Severity: minor
Tags: patch
X-Debbugs-CC: debian-s390@lists.debian.org
The sysconfig-hardware package contains a number of syntax errors in "case"
commands. The "case" command requires that after each pattern specification
there must be a command list, and this command list must be terminated by
a double semicolon. This is violated in several places. In some places,
the only thing between the end of the pattern specification and the double
semicolon is a comment. A comment is not a list. A null command (a colon)
will do, but there must be at least one command present to constitute a list.
In other places, there is no double semicolon to terminate the list. This
also is a violation of the rules of valid syntax.
For some reason, the code has apparently been executing more or less correctly;
but a future release of bash (yes, bash, not dash) may tighten up standards
and the code will fail. I have attached a patch file which corrects the
problems.
Note: the portion of the patch which changes chandev-convert affects only
the source package. It is not included in the binary package.
--
.''`. Stephen Powell
: :' :
`. `'`
`-diff -uar a/etc/sysconfig/scripts/hardware/functions b/etc/sysconfig/scripts/hardware/functions
--- a/etc/sysconfig/scripts/hardware/functions 2010-10-30 10:50:49.0 -0400
+++ b/etc/sysconfig/scripts/hardware/functions 2015-08-18 05:36:06.411307488 -0400
@@ -27,6 +27,7 @@
echo "$SCRIPTNAME: illegal option -- $OPTARG" >&2
echo "Try: \`$SCRIPTNAME -h' for mor information." >&2
exit $R_USAGE
+ ;;
esac
done
diff -uar a/etc/sysconfig/scripts/hardware/hwup b/etc/sysconfig/scripts/hardware/hwup
--- a/etc/sysconfig/scripts/hardware/hwup 2010-10-30 10:28:43.0 -0400
+++ b/etc/sysconfig/scripts/hardware/hwup 2015-08-18 05:38:22.536360188 -0400
@@ -17,6 +17,7 @@
case "${STARTMODE:-auto}:$MODE" in
auto:auto|*:auto-override)
# Start auto devices in auto and override mode.
+ :
;;
*:auto)
# Don't display any message if device is not auto in auto mode.
@@ -24,6 +25,7 @@
;;
auto:manual|manual:manual)
# Start manual devices in manual mode.
+ :
;;
off:manual)
message "$SCRIPTNAME: used configuration has STARTMODE=$STARTMODE."
@@ -32,6 +34,7 @@
*)
message "$SCRIPTNAME: unknown STARTMODE=$STARTMODE."
exit $R_ERROR
+ ;;
esac
source $SYSCONFIG/scripts/hardware/$COMMAND-$BUS $ID $DEVPATH
diff -uar a/usr/share/sysconfig/chandev-convert b/usr/share/sysconfig/chandev-convert
--- a/usr/share/sysconfig/chandev-convert 2009-03-24 06:10:51.0 -0400
+++ b/usr/share/sysconfig/chandev-convert 2015-08-18 05:40:58.760978505 -0400
@@ -26,6 +26,7 @@
echo "$SCRIPTNAME: illegal option -- $OPTARG" >&2
echo "Try: \`$SCRIPTNAME -h' for mor information." >&2
exit $R_USAGE
+;;
esac
done
Re: Adding DASD to a Debian guest
On Sun, 16 Aug 2015 08:28:42 -0400 (EDT), Philipp Kern wrote: > ... > However it then turned out that I needed to hack the zipl config to > make the kernel see the DASD from within the initrd. > > [0.066844] Kernel command line: root=/dev/sysvg/root > dasd_mod.dasd=0.0.0100 BOOT_IMAGE=0 That's because sysconfig-hardware isn't in the initial RAM file system, and therefore doesn't bring DASD volumes online until the permanent root file system has been mounted. If the permanent root file system is a partition on a physical volume, there is exception code in /usr/share/initramfs-tools/scripts/init-premount/sysconfig_hardware to bring that specific volume online early, but only if the root device is specified in zipl via the form root=/dev/disk/by-path/ccw-0.0.-partz where is the device number and z is the partition number. It must be in this form so that /usr/share/initramfs-tools/scripts/init-premount/sysconfig_hardware knows the device number and can bring it online via echo 1 >/sys/bus/ccw/devices/0.0./online This is one reason, but not the only reason, why I advised the OP not to make the root file system a logical volume. On my systems, I add sysconfig-hardware to the initial RAM file system, using the method described in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=621080 but of course this cannot be done until *after* installation. The main reason that I do it is so that I can specifiy the root file system in zipl as root=UUID=... which will only work if all the DASD volumes have been brought online already, and therefore udev has found the volumes and their partitions and has created symbolic links for them in /dev/disk. This makes the boot process much closer to how it works on all other hardware platforms that Debian supports. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Adding DASD to a Debian guest
On Thu, 13 Aug 2015 07:02:21 -0400 (EDT), Howard V. Hardiman wrote: > > Hello, > > I am configuring a golden image that will live on one piece of dasd > with LVM. OK. > When I clone it I will need to add more dasd to certain of > the cloned guests. So, now I am attempting to do a fresh install that > has LVM for the golden image, because my current golden image does not > use LVM. As you mentioned, in this process I am letting the > 'installer' do the job. But, during one of the last steps of the > install I get the error about zipl bootloader not being able to > download and I have to skip that step. The install finishes but I > cannot boot with the ipl command. > > Here is a run down of what I have done relating to the LVM. > > (1.) Placed a 100M partition on the dasd and made it the /boot partition > (2.) Placed the remainder of dasd in a virtual group vg1 > (3.) Created logical volume lv1 = '/' and lv2=swap, using vg1 > (4.) Wrote partitions and moved on with install process > > If I proceed in the installation it says that I can manually boot > with the /vmlinuz kernel on partition /dev/dasda1 and root > /dev/mapper/vg1-lv1 passed as kernel argument. How do I do that? > If that works, can I then load zipl or some bootloader that will allow > me to be able to ipl the OS like normal? First of all, the /boot partition cannot be in an LVM2 logical volume. The "/boot" partition must be a partition on a "physical" DASD volume, that is, a volume which appears as a physical volume to an operating system running in the z/VM virtual machine. In reality, this can be a z/VM minidisk, but not an LVM2 logical volume. I'm not sure if the "/" partition can be in a logical volume either. But even if it can, I don't recommend it. There are a number of maintenance situations where one wants to (or needs to) unmount the file system in order to perform maintenance on it. Since "/" is always mounted, that presents a problem. I highly recommend that the "/" file system be a partition on a physical volume as well. Here is a scenario that has worked well for me. I create four minidisks in z/VM, with virtual device numbers 200, 201, 202, and 203. During Debian installation I create a single partition on each device which occupies the entire device (except for the required metadata at the beginning: track 0 reserved for the IPL records and the volume label, and track 1 reserved for the VTOC). I use the partition on 200 as the "/" filesystem. I use the partition on 201 as the "/boot" filesystem. I use the partition on 202 as the "/home" filesystem, and I use the partition on 203 as a swap partition. After installation, I boot the machine with "IPL 201". I would probably make /boot about 100 cylinders. Now if you want to use LVM2, you can. For example, if you're going to be building packages from source, you might want to create a logical volume and mount it on /usr/src. Or maybe you are going to be needing a lot of space for SQL data, such as with mariadb or postgresql. You might want to create a logical volume for that and mount it on /dbase, or whatever mount point the database wants to use. You can put /home on a logical volume too, if you want. But I wouldn't put /boot or / or a swap partition on a logical volume. You can have multiple swap partitions anyway, so expanding swap space is not an issue. I would make / big enough so that after installation is complete it is no more than 50% full, to allow for future growth. Let me know how it goes. If you add new DASD devices to your system after installation, whether you mount them directly or add them to a logical volume, be sure to create files in /etc/sysconfig/hardware so that sysconfig-hardware will bring them online at the next boot. -- .''`. Stephen Powell : :' : `. `'` `-
Re: Please add
On Mon, 10 Aug 2015 21:47:56 -0400 (EDT), Verbus Counts wrote: > > Please add me to this list. > > ver...@gmail.com You can't subscribe to the list by posting to the list. Please see the instructions for subscribing to a Debian mailing list, including this one, on the following web page: https://www.debian.org/MailingLists/ Please also read the whole page, especially the "Code of Conduct" section. I don't normally CC the poster, in accordance with policy; but I'm going to assume in this case that you want a CC since requesting a subscription is an implicit acknowledgement that you are not subscribed but want to be, which is normally an implicit request for a CC. Also, although not specifically required by the code of conduct, we prefer the usenet style of interleaved quoting here, as I have done above, rather than "top posting". When replying to a message from the list, please change the "Reply To" field to the list's e-mail address, if your e-mail client does not do this automatically, and do not CC the sender unless specifically requested to do so. Regards, -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1392008330.11364566.1439290042536.javamail.zim...@wowway.com
Re: Please add
Mon, 10 Aug 2015 21:47:56 -0400 (EDT), Verbus Counts wrote: > > Please add me to this list. > > ver...@gmail.com One other thing I forgot to mention: I notice that your e-mail address is at the gmail.com domain. Although I can't vouch for this from personal experience, I understand from other users on Debian mailing lists who have complained about it that gmail will not return a copy of your own posts to the list, as most other e-mail providers do. But please, don't assume that because you didn't receive a copy of your own post that the post didn't get there and re-send it. Instead, check the mailing list archives at https://lists.debian.org/debian-s390/ or by some other means, to verify that your post was received and posted to the list. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/921638858.11368260.1439290634623.javamail.zim...@wowway.com
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
I realize that you've moved on to version 1.25.0-1 (and beyond), but for what it's worth, I thought you might like to know that I added -fno-delete-null-pointer-checks to CFLAGS in zipl/boot/Makefile and recompiled the package (1.24.1-1) with gcc 4.9 and it now works fine. The only problem with adding this option to the Makefile is that the compiler will choke on it if the compiler version is too old to recognize the option. And I agree with Bastian. -fno-delete-null-pointer-checks should be assumed by default in gcc if -ffreestanding is in effect, unless -fdelete-null-pointer-checks is explicitly specified. Null pointer dereferences are perfectly valid when referring to data in real page 0. I don't know about other machine architectures, but on s390/s390x, such references are sometimes necessary. The case in point was a valid null pointer dereference to examine the external interruption code. I do worry, though, about this being a more general problem. What about the interrupt handler in the Linux kernel? Or any other portion of the kernel that needs to examine (or change) data in real page 0 for whatever reason? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1089387572.419704.1409107138524.javamail.r...@md01.wow.synacor.com
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Fri, 22 Aug 2014 08:02:42 -0400 (EDT), Michael Holzheu wrote:
>
> You can get a disassembly for the eckd boot loader code when you go
> to s390-tools/zipl/boot and:
>
> 1) make
> 2) objdump -S eckd2.exec > eckd2.list
> ...
>
> static inline int wait(void)
> {
> do {
> load_wait_psw(0x010200018000ULL,
> &S390_lowcore.external_new_psw);
> 33d0: e3 20 d0 00 00 04 lg %r2,0(%r13)
> 33d6: a7 39 01 b0 lghi%r3,432
> 33da: c0 e5 ff ff fc f7 brasl %r14,2dc8
> if (S390_lowcore.ext_int_code == 0x1004)
> 33e0: e3 10 00 86 00 91 llgh%r1,134
> 33e6: a7 1e 10 04 chi %r1,4100
> 33ea: a7 74 00 06 jne 33f6
> 33ee: a7 28 00 02 lhi %r2,2
> 33f2: a7 f4 00 08 j 3402
> return ETIMEOUT;
> } while (S390_lowcore.ext_int_code != 0x2401);
> 33f6: a7 1e 24 01 chi %r1,9217
> 33fa: a7 74 ff eb jne 33d0
> 33fe: a7 28 00 00 lhi %r2,0
>
> Would be interesting how the disassembly looks on your system.
Indeed. Here is what I got:
-
static inline int wait(void)
{
do {
load_wait_psw(0x010200018000ULL,
&S390_lowcore.external_new_psw);
32d6: a7 39 01 b0 lghi%r3,432
32da: e3 20 d0 00 00 04 lg %r2,0(%r13)
32e0: c0 e5 ff ff fb b8 brasl %r14,2a50
if (S390_lowcore.ext_int_code == 0x1004)
32e6: 48 10 00 86 lh %r1,134
32ea: a7 f4 00 01 j 32ec
32ee: 07 07 nopr%r7
-
Obviously bad code. Something is terribly wrong here. The complete eckd2.list
file is available for download at
http://users.wowway.com/~zlinuxman/zipl/eckd2.list
It was compiled with gcc version 4.9.1 (Debian 4.9.1-4) on a Debian jessie
system.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/1065104246.397237.1408749691477.javamail.r...@md01.wow.synacor.com
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
Here are the last few instructions prior to the failure on the failing version, thanks to the CP TRACE facility under z/VM on a real IBM z/890: 2A78 STG E310F0A80024 >> FEB0 CC 2 2A7E LG E320300401B0 CC 2 2A84 LG E3103008000401B8 CC 2 2A8A STG E3403024 >> 01B0 CC 2 2A90 LA 4140F0A0 = FEA8 CC 2 2A94 LARLC05BCC 2 2A9A STG E35040080024 >> FEB0 CC 2 2AA0 STG E35030080024 >> 01B8 CC 2 2AA6 LPSWE B2B2F0A0FEA8 CC 0 2AAA LMG EBDFF0B4 CC 0 2AB0 STG E3203024 >> 01B0 CC 0 2AB6 STG E31030080024 >> 01B8 CC 0 2ABC BR 07FE -> 32E6 CC 0 -> 32E6 LH 481000860086 CC 0 32EA BRU A7F40001 -> 32EC CC 0 -> 32EC 0001 *** 32EC PROG0001 -> 39A8 And here is what appears to be the equivalent code on the working version, compiled under wheezy: 2A38 STG E310F0A80024 >> FEA0 CC 2 2A3E LG E320300401B0 CC 2 2A44 LG E3103008000401B8 CC 2 2A4A STG E3403024 >> 01B0 CC 2 2A50 LA 4140F0A0 = FE98 CC 2 2A54 LARLC05BCC 2 2A5A STG E35040080024 >> FEA0 CC 2 2A60 STG E35030080024 >> 01B8 CC 2 2A66 LPSWE B2B2F0A0FE98 CC 0 2A6A LMG EBDFF0B4 CC 0 2A70 STG E3203024 >> 01B0 CC 0 2A76 STG E31030080024 >> 01B8 CC 0 2A7C BR 07FE -> 32C0 CC 0 -> 32C0 LLGHE310008600910086 CC 0 32C6 CHI A71E1004CC 2 32CA BRZ A784000A32DE CC 2 ... And on we go from there. The BRU instruction in the first sequence is clearly bad. In assembler language format, the equivalent instruction would be "BRU *+2". This is a bad branch. The instruction branches into the middle of itself, picking up "0001" as the next machine instruction, which causes an operation exception. Since the failing "instruction" starts at storage address 32EC, and is two bytes long, that means that the updated instruction address in the PSW at the time of the program interruption will be 32EE, which is the value used in the disabled wait PSW. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/2091317040.389462.1408663604512.javamail.r...@md01.wow.synacor.com
Re: custom kernels and s390x
On Tue, 19 Aug 2014 21:20:23 -0400 (EDT), Stephen Powell wrote: > > I maintain a Debian-specific custom-kernel-building web page at > >http://users.wowway.com/~zlinuxman/Kernel.htm > ... One thing I forgot to mention earlier is that there are links to a couple of s390-specific bug fixes for the Linux kernel also. One is for a 3215 hang problem. The other is for a tab problem on a 3215. Also, just today, I revised the web page yet again to provide a patch for the 3215 hang problem for wheezy kernels. The patch listed in the bug report only works for jessie kernels. The patch for the 3215 tab problem works for both wheezy and jessie. This is in the "Alternatives" section. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1701034847.380427.1408574402448.javamail.r...@md01.wow.synacor.com
custom kernels and s390x
I maintain a Debian-specific custom-kernel-building web page at http://users.wowway.com/~zlinuxman/Kernel.htm Although it is Debian-specific, it is not s390x-specific. However, I recently (today) revised that web page to contain a couple of s390x-specific things that may be of interest to subscribers of this list. kernel-package does not contain any s390x support in the wheezy version. The jessie version of kernel-package attempted to add s390x support, but it didn't quite work. I have added links to my web page listed above to two patches. The first patch adds s390x support to the wheezy version of kernel-package. The second patch fixes the s390x support in the jessie version of kernel-package. These links can be found in the last paragraph of "Step 6: Install kernel-package". The second update is a tip for how to get "make deb-pkg" to work on s390x, when it normally does not. See the "Alternatives" section for this tip. Perhaps this information will be useful to at least some of those who subscribe to this list. Cheers. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1068462462.372461.1408497623103.javamail.r...@md01.wow.synacor.com
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Fri, 15 Aug 2014 19:12:24 -0400 (EDT), Stephen Powell wrote: > > The full PSW is as follows: > >0002 8000 32EE By the way, Hercules has an instruction tracing facility, similar to the CP TRACE command on z/VM. The "T" command, along with the "T+" and "T-" commands, are documented in the Hercules User Reference Guide, available as a pdf file from http://hercdoc.glanzmann.org Scroll down to the section for the manuals for version 3.07, which is the version which is currently packaged for Debian. And, by the way, the current main Hercules web site is http://www.hercules-390.eu The 3.07 documentation which ships with the current hercules package in Debian points to the old web site, which is no longer valid. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1638357473.343069.1408203104179.javamail.r...@md01.wow.synacor.com
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Fri, 15 Aug 2014 17:24:30 -0400 (EDT), Philipp Kern wrote: > > ... > Do you happen to have the PSW handy? The full PSW is as follows: 0002 8000 32EE It looks like the "wait" bit is set, "31-bit addressing mode" is set, I/O, External, and Machine check interruptions are all disabled, and the instruction address (i.e. disabled wait state code) is set to X'32EE'. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1701537604.339404.1408144344993.javamail.r...@md01.wow.synacor.com
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Thu, 14 Aug 2014 10:32:42 -0400 (EDT), Philipp Kern wrote: > > Hrm. Odd. It shouldn't be because the brokeness relates to the C > library, not to the C compiler itself and zipl does not use the C > library. Again, we must distinguish between zipl, the Linux command which runs at a Linux shell prompt, and zIPL, the boot loader proper, a customized version of which is written out by zipl when zipl gets run. zipl, the command which runs at a Linux shell prompt, most certainly does use the C library. It is written in C, it is compiled by the C compiler, and, at execution time, it uses the C run-time library, just like any other C program. zIPL, which is written out by zipl, does not use the C library. Or does it? Well, not the regular C library, no. But it does use a minimalist run-time library. In the source package, look at zipl/boot/libc.c. Yes, even zIPL, the boot loader proper, does use a C library of sorts. > > That being said, I had to recompile s390-tools on sid, Therein lies the problem. > > and I do not run sid due to the C breakage. You should. You may not be able to directly install jessie or sid, but you can install wheezy and then do an upgrade to jessie or sid. Of course, you will likely experience problems during the upgrade, as I did, most likely with the upgrade of package perl-base. But there are posts to debian-s390 by me that explain how I worked around it. If you had a sid system to test with, you would have realized that this package is unusable and you never would have uploaded it. > > It worked before the recompilation, hence there might be > a change in sid vs. wheezy that caused this. Oh, absolutely. I downloaded the new source package, built it on a wheezy system, transferred the binary package to my jessie system, installed the binary package on my jessie system, ran zipl, shutdown my system, and IPLed. It IPLed just fine. I then took the exact same source package, compiled it on a jessie system, installed the binary package, ran zipl, shutdown, and IPLed. Kaboom! disabled wait state code X'32EE'. The C compiler and run-time library used is the only difference. I think I've proven pretty conclusively that this is C breakage causing this problem. > > You are talking about Hercules, right? It doesn't matter. I get the exact same results on Hercules as I do on a real mainframe, and vice versa. I have found Hercules to be a deadly accurate emulation of real mainframe hardware, when properly configured. In my opinion, everyone who maintains a package which is mainframe-specific, such as s390-tools, and anyone responsible, in whole or in part, for the s390x port needs their own mainframe system that they can play around with in a totally unrestricted manner, without fear of messing someone else up. And if you don't have access to a real mainframe, a Hercules emulation of one is the next best thing. It's slower than a real mainframe; but architecturally, it is virtually indistinguishable from a real mainframe to the software. And that's what an emulator is all about, right? You need a jessie/sid system to play around with. I must say that the C breakage on s390x is the biggest mess that I have ever seen, and in the case of this package, has produced the worst error yet: a totally unbootable system. By the way, when version 1.17.1 of the package is compiled on a jessie system, it runs fine. To me, the most significant difference between the two packages is that the zIPL portion of the 1.17.1 package, the boot loader proper, is all written in assembly language (zipl/boot/sclp.S, zipl/boot/menu.S, etc.), whereas the zIPL portion of the 1.24.1 package has been rewritten in C (zipl/boot/sclp.c, zipl/boot/menu.c, etc.). Since it's written in C, it needs that minimalist C run-time library (zipl/boot/libc.c), which the 1.17.1 version doesn't need. Yes, this bug has C breakage written all over it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1925263645.331324.1408067153733.javamail.r...@md01.wow.synacor.com
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
Package: s390-tools Version: 1.24.1-1 Severity: critical Justification: The entire system is unbootable After installing s390-tools version 1.24.1-1 and re-running zipl, a reboot of the system causes a disabled wait PSW to be loaded during boot, with a wait state code of X'32EE', prior to the zipl menu being written out. The system is unbootable. This may be related to the "general brokenness" of C on s390x in jessie/sid. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/174934116.323623.1408013360592.javamail.r...@md01.wow.synacor.com
interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d0000]
Bug number 753592 was merged into bug number 753444. Bug number 753444 was then marked as fixed in perl-base version 5.18.2-6. At the time of this writing, this version is now in testing (jessie). So one would think it would be safe now to upgrade one's system, right? Well, yes and no. It can be done, but not in the standard way. If you use apt-get update apt-get upgrade The upgrade will fail. The problem is a trigger in perl-base for man-db. Configuring man-db requires hidden dependencies on other packages which are not yet installed. Here's how I managed to break the deadlock. First of all, I had previously put perl, perl-base, and perl-modules on hold at the 5.18.2-4 level with echo perl hold | dpkg --set-selections echo perl-base hold | dpkg --set-selections echo perl-modules hold | dpkg --set-selections So the first step was to remove the holds with echo perl install | dpkg --set-selections echo perl-base install | dpkg --set-selections echo perl-modules install | dpkg --set-selections Of course, it should go without saying that you have to be root to do all of this. But I'll say it anyway for good measure. Now change your current directory to a directory without any *.deb files in it and proceed as follows: apt-get update apt-get download perl perl-base perl-modules libgdbm3 \ liblocale-gettext-perl libtext-charwidth-perl libtext-iconv-perl dpkg -i perl-base_*.deb Unpacking and configuring of perl-base will succeed, but the trigger for configuring man-db will fail. This leaves perl-base with a dpkg status of "ii" and man-db with a dpkg status of "iF". You can check this with dpkg-query -l perl-base dpkg-query -l man-db if you want. Keep going as follows: dpkg -i perl-modules_*.deb dpkg -i libgdbm3_*.deb dpkg -i perl_*.deb dpkg -i liblocale-gettext-perl_*.deb dpkg -i libtext-charwidth-perl_*.deb dpkg -i libtext-iconv-perl_*.deb Now you have the prerequisites installed to configure man-db dpkg --configure man-db Now check the status of man-db again. dpkg-query -l man-db Now it shows up with a status of "ii", which is what you want. Now do some cleanup ... rm *.deb apt-get check If "apt-get check" gives errors, then use "apt-get -f install" to fix it. Once this is done, proceed to upgrade the rest of your database. apt-get upgrade apt-get clean apt-get --purge dist-upgrade apt-get clean apt-get --purge autoremove aptitude forget-new aptitude keep-all I hope this helps someone. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/401375167.101804.1406081045913.javamail.r...@md01.wow.synacor.com
Bug#753592: interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d0000]
Package: perl-base Version: 5.18.2-4+b1 Severity: grave X-Debbugs-CC: debian-s390@lists.debian.org Justification: essential package broken, affects other packages, prevents system upgrade. For now, this bug appears to affect only the s390x architecture of Debian testing (jessie), since all other architectures still use version 5.18.2-4. While performing an "apt-get --purge dist-upgrade" on my s390x jessie system, I encountered errors such as this immediately after perl-base was unpacked: - Use of uninitialized value $ARGV[0] in string eq at /usr/share/debconf/frontend line 17. Use of uninitialized value $ARGV[0] in pattern match (m//) at /usr/share/debconf/frontend line 24. Use of uninitialized value $ARGV[0] in concatenation (.) or string at /usr/share/debconf/frontend line 60. Use of uninitialized value $ARGV[0] in pattern match (m//) at /usr/share/debconf/frontend line 61. Use of uninitialized value $ARGV[0] in pattern match (m//) at /usr/share/debconf/frontend line 62. Use of uninitialized value $ARGV[0] in pattern match (m//) at /usr/share/debconf/frontend line 72. Use of uninitialized value $r in at /usr/share/perl5/Debconf/ConfModule.pm line 72. readline() on unopened filehandle at /usr/share/perl5/Debconf/ConfModule.pm line 72. - These error messages occurred on the user terminal session. On the system console, errors such as these were encountered: - User process fault: interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d] failing address: 0 - This prevented a successful upgrade, as all packages which are configured through debconf failed their configuration. According to the changelog, there are no source changes between 5.18.2-4 and 5.18.2-4+b1, only a recompile against a newer C library. Either something went wrong with the package build, or the new C library has exposed a previously-hidden bug. Version 5.20.0-1 from experimental solves the problem, but breaks other packages, such as libhtml-parser-perl, liblocale-gettext-perl, etc., which now have unmet dependencies. No newer versions of these packages are available. Therefore, I have had to downgrade perl-base from version 5.18.2-4+b1 to 5.18.2-4 and put the package on hold. I also downgraded perl to version 5.18.2-4 and put it on hold. perl-modules is still at 5.18.2-4, but I put it on hold too, for good measure. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1270242434.431488.1404389237787.javamail.r...@md01.wow.synacor.com
Re: [SOLVED] debconf bricked -- undefined variable $ARGV[0] and similar issues
On Tue, 01 Jul 2014 06:12:07 -0400 (EDT), Stephen Powell wrote: > > I found version 5.20.0-1 in experimental, and installed it. > Problem solved. Well, version 5.20.0-1 did solve the problem, as far as eliminating the program exception is concerned. But it also broke packages such as libhtml-parser-perl, liblocale-gettext-perl, etc., which now have unmet dependencies. No newer versions of these packages are available. Therefore, I downgraded perl, perl-base, and perl-modules to version 5.18.2-4, and put them on hold for now. (Thank God for http://snapshots.debian.org !) "apt-get check" now finds no errors, and I can once again upgrade my system, except for the three packages that I put on hold and packages which depend on them. I intend to submit a bug report for this problem. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/719685794.414692.1404265159296.javamail.r...@md01.wow.synacor.com
[SOLVED] debconf bricked -- undefined variable $ARGV[0] and similar issues
On Sun, 15 Jun 2014 12:40:38 -0400 (EDT), Stephen Powell wrote: > > I tried an "apt-get dist-upgrade" of my jessie system yesterday, with bad > results. It seems that debconf is bricked. Currently, there are three > packages > that are unpacked but not configured: tzdata, locales, and debconf. (There > were > originally two: tzdata and locales. I tried reinstalling debconf in an > attempt > to fix the problem, but that only bricked debconf too. So now there are > three. > Here's what I get when I attempt to configure debconf. I get similar errors > if > I attempt to configure either of the other two packages. > > - > > root@smp6:~# dpkg --configure debconf > Setting up debconf (1.5.53) ... > Use of uninitialized value $ARGV[0] in string eq at > /usr/share/debconf/frontend line 17. > Use of uninitialized value $ARGV[0] in pattern match (m//) at > /usr/share/debconf/frontend line 24. > Use of uninitialized value $ARGV[0] in concatenation (.) or string at > /usr/share/debconf/frontend line 60. > Use of uninitialized value $ARGV[0] in pattern match (m//) at > /usr/share/debconf/frontend line 61. > Use of uninitialized value $ARGV[0] in pattern match (m//) at > /usr/share/debconf/frontend line 62. > Use of uninitialized value $ARGV[0] in pattern match (m//) at > /usr/share/debconf/frontend line 72. > Use of uninitialized value $r in at > /usr/share/perl5/Debconf/ConfModule.pm line 72. > readline() on unopened filehandle at /usr/share/perl5/Debconf/ConfModule.pm > line 72. > dpkg: error processing package debconf (--configure): > subprocess installed post-installation script was killed by signal > (Segmentation fault) > Errors were encountered while processing: > debconf > root@smp6:~# > > - > > How did this happen, what can I do to fix it, and how do I make sure that it > doesn't > happen again? These errors are preventing the rest of the upgrade from going > through. > I can't go forward, and I can't back out. Fortunately, the system still runs > (and > boots). The error messages above show up on the user's console (a remote ssh session). An additional symptom is this message on the system console (the SCLP line-mode console for Linux running in an LPAR, the 3215 virtual console for Linux running in a virtual machine under z/VM): - User process fault: interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d] failing address: 0 - I checked, and libperl.so.5.18.2 belongs to package perl-base on the s390x architecture. The package version currently installed was 5.18.2-4+b1. According to Debian's web site, s390x is the *only* architecture running this version in testing. All others are at 5.18.2-4. I found version 5.20.0-1 in experimental, and installed it. Problem solved. If you have this problem, you can't fix it the usual way (apt-get install), because apt-get will first run "dpkg --configure -a" if there are any unconfigured packages on the system, which there are, and it will fail. This causes apt-get install to fail. You have to download the packages somehow (apt-get download, wget, ftp, etc.) then install them manually with dpkg. You will need three packages, probably: perl, perl-base, and perl-modules. Install perl-base first, then perl-modules (you will probably need to use the --force-depends option on perl-modules), then finally perl. Don't install version 5.18.2-4+b1 of perl* on your system! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1576907570.401581.1404209527054.javamail.r...@md01.wow.synacor.com
Re: Debian-390 / Hercules Problems
On Sun, 23 Feb 2014 21:24:43 -0500 (EST), Philipp Kern wrote: > > Is znetconf solely doing runtime configuration or does it also try to persist > it? >From what I can tell, it appears to be doing runtime configuration only. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/641079549.101995.1393694742304.javamail.r...@md01.wow.synacor.com
av_register_all() segfaults on s390x in some cases (regression, causes FTBFS)
I am not a Debian s390x porter, per se, and I don't know much about Debian package maintaining. But if you want to create your own virtual s390x machine for testing purposes, perhaps the following web page will be helpful to you: http://users.wowway.com/~zlinuxman/hercules.htm -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1015660444.101479.1393691702191.javamail.r...@md01.wow.synacor.com
Re: Hercules Bus Error
On Sun, 23 Feb 2014 21:22:10 -0500 (EST), Philipp Kern wrote: > > I think that your post should end up somewhere accessible and google'able in > documentation, as it is probably something a bunch of people will struggle > with when getting started with Debian on the mainframe. Except that I don't > know where. Some of it might belong into the installation manual, but most > of it is just how Debian network configuration works on the mainframe > and I'm not sure if we have good enduser docs where this would fit… > > (Thanks for writing it up!) Well, it obviously wasn't what the OP wanted to hear, but maybe it will benefit someone. But I know what you mean. There's no well-defined place for it. Network configuration in Debian for s390x is part sysconfig-hardware (which is poorly documented), part udev (such as /etc/udev/rules.d/70-persistent-net.rules), and part ifupdown. There doesn't seem to be a single, well-defined place to document it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2075252195.1067.1393244580014.javamail.r...@md01.wow.synacor.com
Re: Hercules Bus Error
On Wed, 19 Feb 2014 22:19:23 -0500 (EST), David Clements wrote: > > My initial response to your response was short, sharp and yes, crude, > but > > I sent this problem report to the wrong group. OK, so you sent the problem report to the wrong group. We all make mistakes, myself included. But how was I to know that you had sent the problem report to the wrong group? I can't read minds. There's no need to get mad about it. I responded based on the assumption that you posted to debian-s390 on purpose. What else could I do? > > There is no correct way to use debian. As I said in a post on my original > issues with hercules and debian-390 testing, I use debian because it gives > me what I need from a distro. Whatever floats your boat, man. But when you use Debian in ways that its architects did not design it to work, you severely limit the number of people that will be able to help you should you have problems. I was just trying to explain how its architects designed it to work. > > I do not use the debian supplied version of hercules, it does not provide > the functionality I need, so I use later versions from the github repo. Again, whatever floats your boat, man. > > I use bash as my default shell, for all non-root work, I do not use dash nor > am I interested in why debian uses dash. bash is the default shell for the login shell on Debian. But a shell script which specifically points to "#!/bin/sh" will run under dash by default on a Debian system, unless you have made alterations to it. Debian switched to dash for improved speed, especially during the boot-up process. If you want to make bash your default shell for shell scripts, again, whatever floats your boat. I just wanted to make you aware of this issue. > > I use later kernels to fix stall > problems on my AMD cpus, I could go on and on. Fine. Again, whatever floats your boat. > > I use debian the way I want > to, if I wanted to be dictated to about how I use my systems I would use > OSX or Windows. I did not dictate to you. > > My goal is to test new functionality in hercules, if this means I misuse or > abuse debian and or it's tools then so be it. OK. > > I worked with real mainframe boxes both as an engineer and a systems > programmer for more than 40 years, during that time I always had the > belief, philosophy if you like, that there was always some who knew more > than I on any given subject. I am a systems programmer for IBM mainframes myself, still actively employed. And I share that belief. > > To summarize, please don't presume to lecture me, particularly as you said > in your first sentence "I admit that I don't understand all that you have > written", without first trying to ascertain the questioners level of > expertise. If you feel you can help in the spirit the question was posed > in, then great, otherwise... I did not lecture to you. That is your interpretation. I was just trying to be helpful. Let me know how your strategy of insulting those from whom you are trying to obtain free help works out for you. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1242534943.1044943.1392906015480.javamail.r...@md01.wow.synacor.com
Re: Hercules Bus Error
ETH device looks like: # The primary network interface auto eth0 iface eth0 inet static address 10.14.80.48 netmask 255.255.255.0 network 10.14.80.0 broadcast 10.14.80.255 gateway 10.14.80.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 10.14.80.5 10.14.80.9 10.14.6.24 dns-search my.employers.network.us (Well, OK, I lied about the dns-search option. That's not the real domain name. The name was changed to protect my employer's identity.) Here is what my CTCA device in protocol 0 mode looks like on one of my home Debian system under Hercules: # The primary network interface auto ctc0 iface ctc0 inet static address 192.168.1.9 netmask 255.255.255.252 network 192.168.1.8 broadcast 192.168.1.11 gateway 192.168.1.10 pointopoint 192.168.1.10 mtu 1500 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 192.168.0.1 dns-search my.home.network.us (Again, I lied about the domain name for anonymity's sake.) As you can see, the options are about the same. I had to add "pointopoint" as an option for this device, since it is a point-to-point connection. And I added "mtu" for technical reasons. "mtu" could have been specified for the eth0 interface too, but I chose to leave it off. Some of the above options are not used or are ignored for this device, such as broadcast, but it doesn't hurt to specify them for documentation purposes. If you have two QETH devices defined at the same time, one layer 3 and one layer 2, for example, then one of them will be called eth0 and the other will be called eth1. The trick is to figure out which is which. This is controlled by a file called /etc/udev/rules.d/70-persistent-net.rules. On the i386 or amd64 platform, devices are generally identified by MAC address. But on the s390x platform, they are generally identified by device number. If this file is missing, you can determine the correspondence from sysfs. For example, cat /sys/bus/ccwgroup/devices/0.0.0300/ifname might produce eth0 Once you know the correspondence between device numbers and interface names, you will know how to configure the interface names in /etc/network/interfaces. If you want the interface to come up automatically during boot, you can add an "auto" statement to the file, such as auto eth0 If not, you can manually bring the interface up by means of ifup eth0 You can manually take an interface down with ifdown eth0 In short, I recommend that you configure these network devices the way Debian was designed to work. If Hercules is working properly, and you have configured your interfaces properly in both Hercules and Debian, it should "just work". If not, asking for help on this list with your devices configured the "Debian way" will likely cause better recognition of the problem by Debian users. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/903639687.1034419.1392840906968.javamail.r...@md01.wow.synacor.com
Re: Debian-390 / Hercules Problems
On Tue, 18 Feb 2014 14:09:43 -0500 (EST), David Clements wrote: > > My jessie installed finished and znetconf is missing. This is very weird > because lsqeth, lsdasd, lscss, etc. are all part of the zconf sub-package > and they are installed. > I have wasted enough time on this, and as I now understand what is going on > with the s390-tools package, not why, I will continue to pull the package > from DeveloperWorks, and get on with my qeth testing. I downloaded the Debian source package for s390-tools 1.17.1. The source code (it's a shell script) for znetconf is present in the source package, but for some reason it does not get built into the binary version of the package. I was able to get it to run from the source package (using "./znetconf -c") when my current directory was debian/build/build/zconf (starting from the top directory of the source package). But in order to get it to run, I had to make some changes. Both znetconf and lsznet.raw have hard-coded references to a directory called /lib/s390-tools, which does not exist on a stock Debian system. This may be causing a build failure. But if so, it is a silent build failure. dpkg-buildpackage produces no errors. I got it to run by changing the directory to ".", for testing purposes. This is no good for the general case, of course, but I did it just to see if I could get it to run, and I was able to get it to run that way. "./znetconf -c" finds and lists my CTCA. I think this is a question for the package maintainer. Philipp, are you listening? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/370643734.1024081.1392783799335.javamail.r...@md01.wow.synacor.com
Re: Debian-390 / Hercules Problems
On Mon, 17 Feb 2014 15:19:13 -0500 (EST), David Clements wrote: > Stephen Powell wrote: >> ... >> The standard Debian package for >> Hercules, 3.07, does not support an Open Systems Adapter Express in QDIO >> mode, so that's the end of that. >> >> I've never tried to use znetconf. For that matter, I've never tried to use >> lsqeth either. But it does seem to be included in the standard s390-tools >> package under Debian. Here is some output from my system: >> >> # whereis lsqeth >> lsqeth: /sbin/lsqeth /usr/share/man/man8/lsqeth.8.gz >> >> By the way, I'd be interested to hear your opinion of my "Debian Under >> Hercules" >> web page at http://users.wowway.com/~zlinuxman/hercules.htm . > > I'm using hercules 4.0, this version supports qeth layer2, I have debian > wheezy running with qeth and I'm currently testing layer3 qeth. > > What version of debian-390 are you using, the current stable that I have > installed, only contains a minimal s390-tools package and I have yet to > find a full debian s390-tools package. The system quoted above is a jessie system (testing). Debian, especially Debian stable, tends to be a "trailing edge" distribution. Many Debian packages are substantially behind the latest upstream release, hercules itself being a good example (3.07 vs 4.0). GNU parted is another example. It is way behind. s390-tools is no exception. The release used in jessie, 1.17.1, is way behind the latest upstream release, which at the time of this writing is apparently 1.24.1. Perhaps the tools you are looking for don't exist in 1.17.1. Debian wheezy (stable) uses 1.16.0, even older. Make sure that the documentation you're looking at (Device Drivers, Features, and Commands?) was written for release 1.16.0 or 1.17.1, depending on which Debian "release" you are running. If you're looking for a bleeding edge distribution, look elsewhere. I speak here as an experienced Debian user, not as any kind of official spokesman for Debian. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1427305353.1006281.1392694068473.javamail.r...@md01.wow.synacor.com
Re: Debian390 / Hercules Problems
On Fri, 14 Feb 2014 13:56:29 -0500 (EST), David Clements wrote: > > ... > After a successful install I tried to work with the qeth device, and found > lsqeth and znetconf are missing, I tried to update s390-tools with apt-get > and it says s390-tools is at the latest release. I pulled s390-tools-1.17.0 > from the IBM Developerwork website installed the zconf part of the package > and continued with my testing. > > I have just noticed in the /var/log/installer/status file a comment that > the s390-tools-udeb package included in the install only contains binaries > for dasdfmt and fdasd. I have searched for znetconf in all releases and can > find no trace in any debian package. > > Any ideas? I have used ctc under Hercules and qeth in a virtual machine under z/VM, but I have never used qeth under Hercules. The standard Debian package for Hercules, 3.07, does not support an Open Systems Adapter Express in QDIO mode, so that's the end of that. I've never tried to use znetconf. For that matter, I've never tried to use lsqeth either. But it does seem to be included in the standard s390-tools package under Debian. Here is some output from my system: # whereis lsqeth lsqeth: /sbin/lsqeth /usr/share/man/man8/lsqeth.8.gz By the way, I'd be interested to hear your opinion of my "Debian Under Hercules" web page at http://users.wowway.com/~zlinuxman/hercules.htm . -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1994842031.969212.1392436680138.javamail.r...@md01.wow.synacor.com
Re: Hercules and a strange CTCI error
On Tue, 13 Aug 2013 22:38:15 -0400 (EDT), Pedro Pinheiro wrote: > ... > So I'm trying to set up an emulated mainframe in Hercules, > having as a host an Windows Server 2003 32-bit, with WinPcap > and CTC-W32 installed and properly configured, as Hercules > itself atests, judging by devlist command and no boot up errors. > ... > Well, I tried a lot of different network setups, > including only CTCI or only LCS. Neverthless, none of them > ever worked. But, at that point, you should be asking: "So, > what's the problem?" Well, in fact everything is okay during > the whole boot process, however it starts to mess it up here: > > Configure the network device > > > Please choose the type of your primary network interface that you will need > for > installing the Debian system (via NFS or HTTP). Only the listed devices are > supported. > Network device type: > 1: ctc: Channel to Channel (CTC) or ESCON connection, > 2: qeth: OSA-Express in QDIO mode / HiperSockets, > 3: iucv: Inter-User Communication Vehicle - available for VM guests only, > 4: virtio: KVM VirtIO, > Prompt: '?' for help> > > As a trained monkey, I naturally select the 1, by typing .1 > at Hercules console, thus transmiting the command to Hercules. > But the installer seems to dislike me, or the computer, or the world, > or whatever, judging by it's bad reply: > > 1 > >ERROR: No CTC or ESCON connections > > Please make sure that you have set them up correctly. > Press enter to continue! I'm afraid that I have no experience with the Windows version of Hercules. But I have had good success installing Debian under Hercules under Debian. See the following web site for more information: http://users.wowway.com/~zlinuxman/hercules.htm Maybe the above will help in some way. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/850197581.2709701.1376871595168.javamail.r...@md01.wow.synacor.com
Instructions for installing Debian GNU/Linux for IBM System z in the Hercules emulator
Hello Debian mainframe enthusiasts! I have just put together a web page for how to install Debian under Hercules. Here's the link: http://users.wowway.com/~zlinuxman/hercules.htm I'd really like to know what you think. I hope to eventually submit this material to Debian for inclusion in the Debian Installation manual for the s390x architecture. But I thought it best to submit this for a peer review first. Did I leave out something important? Did I include something irrelevant? Are there any factual errors? Is the material organized well? Any and all feedback, positive or negative, is welcome. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/394932986.2159874.1373830809192.javamail.r...@md01.wow.synacor.com
Re: Using netboot Debian installation images in the Hercules emulator
On Sat, 06 Jul 2013 14:56:29 -0400 (EDT), Stephen Powell wrote: > > On Sat, 06 Jul 2013 12:31:25 -0400 (EDT), Philipp Kern wrote: >> >> Maybe you could check out the debian-installer manual from SVN and create a >> patch? I'd be happy to commit it. > > I'll be happy to do that if you will grant me the kind indulgence of giving > me the exact, step-by-step procedure for checking out a copy of the > debian-installer manual from SVN. I'm not familiar with SVN in general or > debian-installer manual maintenance procedures in particular. Never mind, I found the instructions I need (I think) in Appendix E of the debian installation manual. I'll have a go at it and, if I get stuck, I'll let you know. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1095733256.2066081.1373310508601.javamail.r...@md01.wow.synacor.com
Re: Using netboot Debian installation images in the Hercules emulator
On Sat, 06 Jul 2013 12:31:25 -0400 (EDT), Philipp Kern wrote: > > On Thu, Jul 04, 2013 at 11:55:00AM -0400, Stephen Powell wrote: >> >> There is no need to do a list-directed IPL from a CD image, there is no >> need to create an emulated tape file, etc. Just use the netboot images >> directly. There is not even a need to pad the files to a multiple of >> 80 bytes, thanks to the autopad option. You can use them "as is". You >> boot the installer by entering the "ipl 000C" command on the Hercules >> console, of course. (Or you may use "iplc 000C" if you want to do a >> "load clear" instead of a "load normal".) I hope this helps someone. > > Maybe you could check out the debian-installer manual from SVN and create a > patch? I'd be happy to commit it. I'll be happy to do that if you will grant me the kind indulgence of giving me the exact, step-by-step procedure for checking out a copy of the debian-installer manual from SVN. I'm not familiar with SVN in general or debian-installer manual maintenance procedures in particular. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1626830535.2042564.1373136989852.javamail.r...@md01.wow.synacor.com
Using netboot Debian installation images in the Hercules emulator
Most posts to the various Debian mailing lists are a question looking for an answer. This one is different. This one is an answer looking for a question. Maybe I'm the only dolt who didn't already know this; but I just figured something out; and just on the off chance that someone else might not know this; I thought I'd share what I've learned. For those of you who already know this, please excuse the noise. The netboot Debian installation images which are designed for use in a virtual card reader in a virtual machine under z/VM work just fine when installing "natively" in the Hercules emulator in a "real" card reader. Consider, for example, the following device definition in hercules.cnf: 000C 3505 /home/hercules/reader/kernel.debian /home/hercules/reader/parmfile.debian /home/hercules/reader/initrd.debian ebcdic autopad eof (Regardless of how the above may look in your mail reader, the above is actually one logical line.) 000C is the device number; 3505 is the device type; then there are the three netboot image files in the proper order; then Hercules options are after that. The ebcdic option tells Hercules not to do any ascii-to-ebcdic translation on the input files, nor to look for line-feed characters as an indicator of logical records, but to simply split up the input file into 80-byte pieces and pass each piece as a separate card image to the program which is reading from the card reader. The autopad option tells Hercules to pad the last record of each file to a length of 80 bytes with null characters (0x00) to make the last record 80 bytes long, if the input file size is not a multiple of 80 bytes. The eof option tells Hercules to signal end-of-file (unit exception in the device status) on the first read following the end of each file. An attention interruption will then be signaled by Hercules when it is ready for the program to read the next file. (No attention interruption is signaled after the last file.) Note that the multifile option must *not* be used. If the multifile option is used, end-of-file is signaled only once (at the end of the last file). The three files are treated as one continuous file in that case. This is the equivalent of spooling a virtual reader continuous (CONT) in z/VM, and that will not produce the expected results. There is no need to do a list-directed IPL from a CD image, there is no need to create an emulated tape file, etc. Just use the netboot images directly. There is not even a need to pad the files to a multiple of 80 bytes, thanks to the autopad option. You can use them "as is". You boot the installer by entering the "ipl 000C" command on the Hercules console, of course. (Or you may use "iplc 000C" if you want to do a "load clear" instead of a "load normal".) I hope this helps someone. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2131923110.2018695.1372953300939.javamail.r...@md01.wow.synacor.com
Bug#714581: Debian Installer "partition disks" step fails on s390/s390x when a "small" disk is used
Package: debian-installer Version: 20130613 Severity: important X-Debbugs-CC: debian-s390@lists.debian.org I recently discovered a bug in the Debian installer on the s390/s390x architecture. The bug occurs when a "small" disk is used. As an illustration, I had four DASDs in my installation environment, all of them device type 3390, each with a single partition occupying the entire disk, as follows: Device size in file mount Number cylinders system point 63FC 3338ext3 / 63FD 75ext2 /boot 63FE 500ext3 /home 63FF 1457swap swap mke2fs for the 63FD device (/dev/dasdb1 in this case) fails because the block size assumed by default was 1024. This is normally fine for i386 and amd64 architectures, since the physical disk block size is normally 512. The file system block size must be an integral multiple of the physical disk block size. And 1024 is a multiple of 512. But on the s390/s390x platform, dasdfmt defaults to a block size of 4096, regardless of the size of the disk. Thus, in the s390/s390x environment, the only acceptable block size (-b option) for mke2fs is 4096. Thus, mke2fs fails, which causes the subsequent mount command to fail, which causes the "partition disks" step of the installer to fail, which causes the entire installation to fail. The definition of a "small" disk is one which results in a default block size chosen by mke2fs which is lower than 4096. I'm not sure where that boundary is. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1167780681.1958873.1372640119359.javamail.r...@md01.wow.synacor.com
How do I get the box-drawing characters to look right for Debian Installer? (SOLVED)
On Sat, 29 Jun 2013 15:37:42 -0400 (EDT), Stephen Powell wrote: > > As you know, the installation procedure for Debian on the s390 and s390x > architectures involves using the Integrated System Console (or the virtual > 3215 console in a virtual machine under z/VM) to get the network device > configured, then logging in as "installer" using a remote SSH client to > finish the rest of the installation. I have learned from experience that > when my remote SSH client is PuTTY running under Windows, I can get the > box-drawing characters in the Debian installer to look right by selecting > "UTF-8" as the character set in the PuTTY configuration. If I use Lat-1, > or some other character set, the box-drawing characters don't look right. > > Recently, however, I tried a Debian install for s390x (wheezy) using the > Linux SSH client running under Linux on an Intel box instead of PuTTY > running under Windows. (Debian package openssh-client, command ssh.) > I used a virtual terminal, vt2 in this case, rather than an xterm window > or something similar (i.e. gnome-terminal). I can connect just fine, > but the box-drawing characters don't look right. I can't find any way > to configure the Linux ssh client to make the box-drawing characters > display properly. > > How do I get the Linux ssh client to work with the Debian installer to get > the box-drawing characters to look right? Or must I use Windows to > install Debian? Well, I'm answering my own post. Sorry about that. But maybe it will help others. I guess I didn't do enough digging before posting my question. But anyway, here's the answer. The Linux ssh client apparently does not have a mechanism for independently specifying the character mapping, as PuTTY does. If it does, I haven't discovered it. The Linux ssh client relies on the character mapping of the host Linux system under which it runs. You have to change that to UTF-8 if you want to have the box characters of the Debian installer running on a remote s390 or s390x host look right. You specify that in two different places: one for xterm sessions under the X Window system (or a substitute application for xterm, such as Gnome Terminal) and the other for virtual terminals (vt1-vt6). Login as root. Enter the command dpkg-reconfigure locales Select appropriate locales. On my system, I selected en_US, en_US.ISO-8859-15, and en_US.UTF-8. Select OK. On the next screen, you select a default locale for the system. I selected en_US.UTF-8. Complete the configuration. This changes the character mapping for stuff under the X Window System. Now enter dpkg-reconfigure console-setup On the first screen, you select the encoding to use on the console. Select UTF-8, then select OK. Finish the configuration. This changes the character mapping for virtual consoles. Now shutdown and reboot. Upon reboot, the ssh client will use UTF-8 character mappings, whether you run it in a terminal window under the X Window system or whether you run it in a virtual terminal. And the box characters of the Debian installer will look right for the remote s390/s390x host. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1478260138.1947802.1372543174813.javamail.r...@md01.wow.synacor.com
How do I get the box-drawing characters to look right for Debian Installer?
As you know, the installation procedure for Debian on the s390 and s390x architectures involves using the Integrated System Console (or the virtual 3215 console in a virtual machine under z/VM) to get the network device configured, then logging in as "installer" using a remote SSH client to finish the rest of the installation. I have learned from experience that when my remote SSH client is PuTTY running under Windows, I can get the box-drawing characters in the Debian installer to look right by selecting "UTF-8" as the character set in the PuTTY configuration. If I use Lat-1, or some other character set, the box-drawing characters don't look right. Recently, however, I tried a Debian install for s390x (wheezy) using the Linux SSH client running under Linux on an Intel box instead of PuTTY running under Windows. (Debian package openssh-client, command ssh.) I used a virtual terminal, vt2 in this case, rather than an xterm window or something similar (i.e. gnome-terminal). I can connect just fine, but the box-drawing characters don't look right. I can't find any way to configure the Linux ssh client to make the box-drawing characters display properly. How do I get the Linux ssh client to work with the Debian installer to get the box-drawing characters to look right? Or must I use Windows to install Debian? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/353485001.1946594.1372534662942.javamail.r...@md01.wow.synacor.com
Bug#696943: /etc/initramfs/post-update.d/zz-zipl script invokes zipl unnecessarily at times
Package: s390-tools
Version: 1.16.0-2
Severity: wishlist
The /etc/initramfs/post-update.d/zz-zipl script sometimes invokes zipl
when it doesn't need to do so, resulting in zipl being run twice.
For example, during an "aptitude full-upgrade" or "aptitude safe-upgrade"
command, a kernel image package may be updated. The hook scripts in
directory /etc/kernel/postinst.d are invoked twice: once during the
pre-configuration phase and once during the configuration phase.
The /etc/kernel/postinst.d/initramfs-tools hook script checks to see
what phase it's in, and returns to its caller with no action taken
during the pre-configuration phase; but during the configuration phase
it invokes update-initramfs. update-initramfs in turn invokes run-parts
to execute the hooks in /etc/initramfs/post-update.d, which includes
/etc/initramfs/post-update.d/zz-zipl, if s390-tools is installed.
Under these conditions, /etc/initramfs/post-update.d/zz-zipl should not
invoke the zipl command, since /etc/kernel/postinst.d/zz-zipl will be
run shortly thereafter, which will invoke the zipl command.
In short, /etc/initramfs/post-update.d/zz-zipl is not testing for this
condition. On the other hand, it is testing for pre-configuration vs.
configuration. This is not necessary, since it will never be called
during pre-configuration (unlike /etc/kernel/postinst.d/zz-zipl).
I suggest something like this for /etc/initramfs/post-update.d/zz-zipl:
-
#!/bin/sh
#
# runzipl - postupdate.d script for modern initrd management
#
set -e
# check for maintainer param
PAR=${DPKG_MAINTSCRIPT_PACKAGE:-ever}
case "$PAR" in
linux-image-*)
# zipl will be run later by the kernel postinst hook.
# no need to run it now.
:
;;
*)
# Run the boot loader installer
if [ -f /sbin/zipl ];then
if [ -f /etc/zipl.conf ];then
zipl &2
else
echo 'Warning: Not updating ZIPL; /etc/zipl.conf not found!' >&2
fi
fi
;;
esac
-
This is based on /etc/initramfs/post-update.d/runlilo from the lilo package.
(Note that the "zz-" prefix is not required for hook scripts in the
/etc/initramfs/post-update.d directory, as it is for the /etc/kernel/postinst.d
and /etc/kernel/postrm.d directories.)
I have tried the above script on my system, and it works fine. zipl only gets
invoked once on a kernel update now. But zipl still gets invoked when the
initial
RAM file system is re-built for other reasons. A machine-readable copy of this
script can be found on my web site at
http://users.wowway.com/~zlinuxman/zipl/runzipl
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/42129112.492581.1356806265744.javamail.r...@md01.wow.synacor.com
Re: s390x upgrade squeeze to wheezy.
On Tue, 13 Nov 2012 15:04:56 -0500 (EST), nduc...@bellsouth.net wrote: > > I just did a upgrade to wheezy on intel and it didn't go all that well. > I need to upgrade from squeeze to wheezy on an IBM z9 and was hoping > someone had a detailed step by step process to do this. > The more searches I do the more confusing it gets. > > Any detailed help is appreciated. > Regards, > Nelson First of all, you didn't give any information as to exactly how you attempted to perform this upgrade. I trust you didn't just edit /etc/apt/sources.list and then simply do an "aptitude update" / "aptitude full-upgrade". The procedure is more involved than that. The Debian release notes give a proper, detailed procedure for performing an upgrade. However, having said that, the release notes are usually out-of-date, being essentially a copy of the release notes for the previous upgrade, until the new release becomes stable. In other words, once Wheezy becomes the stable release, the release notes for how to migrate from Squeeze to Wheezy will be updated with current information. Using the Squeeze to Wheezy upgrade release notes while Wheezy is in testing status is a precarious thing because the release notes often haven't been updated yet. In general, such migrations are not really recommended. Wheezy has been in freeze status for some time; so it should become the stable release "soon". I'd wait until Wheezy becomes the stable release first if I were you, then carefully follow the release notes. Also, keep in mind that Squeeze will be the hybrid environment (a 64-bit kernel and a 31-bit user space). If you want a full s390x distribution of Wheezy (64-bit kernel space and 64-bit user space), you will probably want to do a fresh install of s390x anyway. It is theoretically possible to migrate from the hybrid environment to a full s390x environment, but you really have to know what you're doing, and it's unsupported. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/796399517.1087215.1352866863587.javamail.r...@md01.wow.synacor.com
Re: dasd-id vol-id
On Tue, 13 Nov 2012 13:15:26 -0500 (EST), Tom Huegel wrote: > > I have DEBIAN s390x installed, but I get a lot of these messages at start > up. > > *udevd[344]: failed to execute '/lib/udev/dasd_id' 'dasd_id --export > /dev/dasdb': No such file or directory > ... > > Can anyone tell me what to do next? > > I am a real LINUX beginner but 40 yrs. with VM > This is probably something that needs to be cleaned up, but it does not appear to be causing any operational problems. I get the same errors on my system during boot. At some point in the boot process, the errors go away. I trust it will be addressed eventually. Philip may wish to elaborate. I do not speak for the port team. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1021528828.1087042.1352865826890.javamail.r...@md01.wow.synacor.com
Re: installer problem
On Fri, 02 Nov 2012 11:11:02 -0400 (EDT), Tom Huegel wrote: > > I am trying to install DEBIAN s/390 for the first time and get the > following messages in the log. > I seem to get the same (or at least similar) messages regardless of which > mirror I try. > Can anyone point to my error? > Thanks > Tom > ... If you're using the s390x version of the installer, then the only release that can currently be installed is wheezy (testing). To install an earlier release, such as squeeze (stable), you must use the s390 version of the installer, not the s390x version of the installer. Allow me to explain. Debian, until recently, took a hybrid approach to the s390/s390x environment. The kernel space was 64 bit, while the user space was 31 bit. Thus, even when running on z-series processors, the architecture designation was still s390. Wheezy is the first release to offer a complete s390x architecture, where both kernel space and user space are 64 bit. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/185993493.850156.1351870315455.javamail.r...@md01.wow.synacor.com
Re: Adding DASD to Debian wheezy..
On Fri, 26 Oct 2012 15:52:05 -0400 (EDT), Dave Jones wrote: > ... > I have found (accidentally :-) ) that if I simply do the touch command > and not the update-initramfs command, the kernel picks up the new device > at the next boot as well. > ... Yes, in a "plain vanilla" implementation, that is probably true. But if you implement the suggestions in Debian Bug report 621080, the config files are in the initial RAM file system. Thus, making changes in this area really should be followed by a re-build of the initial RAM file system. (Which will also result in zipl being run afterwords, if your system is configured properly.) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1211379467.720245.1351285938171.javamail.r...@md01.wow.synacor.com
Re: Adding DASD to Debian wheezy..
On Fri, 26 Oct 2012 09:46:37 -0400 (EDT), Dave Jones wrote: > > Hello everyone. > > I have installed the latest version of Wheezy here and it is running > very well; good job developers. I now want to add a new DASD drive and > have it come on-line automatically at boot timewhat is the approved > "Debian way" of doing this? Will I have to do a mkinitrd and zipl as I > do for RedHat or SuSE? > > Thanks and have a good weekend. Hi Dave. Wheezy uses sysconfig-hardware for this. To have the DASD come online automatically, follow a procedure similar to the one below. Do this as root. cd /etc/sysconfig/hardware touch config-ccw-0.0.0204 update-initramfs -uk $(uname -r) The above example assumes that the device number to be added is 0204. Change this as appropriate for your system. There are some bug reports against sysconfig-hardware that you might want to take a look at. They haven't been fixed, but the bug reports show how to fix them. http://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;package=sysconfig-hardware You might also find some of my web pages available on my web site useful: http://users.wowway.com/~zlinuxman/index.htm -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1966085070.713662.1351267528749.javamail.r...@md01.wow.synacor.com
Re: No security updates available for s390x
On Mon, 15 Oct 2012 15:23:02 -0400 (EDT), Philipp Kern wrote: > > wheezy is not released yet. A bug is filed against the infrastructure > to enable armhf/s390x on security.d.o. If you check the other > architectures you won't find any package in there for wheezy. (Except > that there actually is exactly one, I wonder why that is because we > still update wheezy proper directly. I'll followup on that.) Hello, Philipp. Thank you for the reply. Yes, I realize that Wheezy has not yet been made the stable release, but the Debian installer states that security support is available for the testing release and enables security support by default when installing the testing release. I have always enabled it, and it works fine for i386 and s390, but not for s390x. Thanks for filing the bug report. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/759135338.522786.1350478889848.javamail.r...@md01.wow.synacor.com
No security updates available for s390x
After doing a fresh install of Debian Wheezy for s390x I discovered that there is no security support available for this architecture. "aptitude update" produced the following error messages: W: Failed to fetch http://security.debian.org/dists/wheezy/updates/InRelease: Unable to find expected entry 'main/binary-s390x/Packages' in Release file (Wrong sources.list entry or malformed file) E: Some index files failed to download. They have been ignored, or old ones used instead. E: Couldn't rebuild package cache I checked /etc/apt/sources.list. The entries are formed correctly: deb http://security.debian.org/ wheezy/updates main contrib non-free deb-src http://security.debian.org/ wheezy/updates main contrib non-free A search of the internet using the above error messages produced no useful hits. Why is there no security support? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/121573374.473370.1350307321741.javamail.r...@md01.wow.synacor.com
Re: RFH: segfault on s390x (hyperestraier)
On Sat, 18 Aug 2012 05:39:07 -0400 (EDT), Philipp Kern wrote: > On Fri, Aug 17, 2012 at 07:11:26PM +0900, Satoru KURASHIKI wrote: >> This segfault occurs only on s390x, so I guess it is some of platform >> specific one. Are there any pattern or best practice about such problems? > > Casts of pointers usually are a problem. Like casting size_t* to int* > and vice versa. > > Kind regards > Philipp Kern > > PS: The liberal use of casts from (unsigned) char* to int* does not make me > that happy. Like «return (int *)"";»… On a related subject, Satoru, s390 and s390x are "big-endian" machine architectures, whereas most computers, including i386 and amd64, are "little-endian" architectures. That is to say that s390 and s390x store integers in storage with the high-order byte at the low address and the low-order byte at the high address. For example, the decimal number 19,088,743, when converted to a 32-bit binary integer and expressed in hexadecimal notation, is 01234567. When that number is in a register, both on amd64 and s390x, it is stored with the high-order byte on the left, the next high-order byte adjacent to that, and so on, with the low-order byte on the right. But when the number is stored into RAM, the two architectures do it differently. On s390x, the number is stored in big-endian format, with the high-order byte at the lowest storage address and the low-order byte at the highest storage address: 01 23 45 67. amd64 stores the bytes in RAM in reverse order: 67 45 23 01. This is "little-endian" format. Sometimes hidden assumptions of little- endian format creep into programs that cause them to not work properly on s390x. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1309768158.513538.1345292571615.javamail.r...@md01.wow.synacor.com
Re: Architecture conversion instructions (s390 -> s390x)
On Sat, 11 Aug 2012 09:43:12 -0400 (EDT), Bastian Blank wrote: > On Sat, Aug 11, 2012 at 07:54:04AM -0400, Stephen Powell wrote: >> Are there any architecture conversion instructions available anywhere? >> (I.e. how to convert an existing s390 server to an s390x server?) >> Or is it a requirement that any s390x server must be installed from >> scratch? > > Upgrading between architectures is not supported in Wheezy. However this > is nothing special. Go ask on debian-devel. Thanks, Bastian and Jeremy, for your replies. In summary, it's not supported, but it is possible to do it if you do things just right. Thanks for the tips. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/145653790.508146.1345246471345.javamail.r...@md01.wow.synacor.com
Architecture conversion instructions (s390 -> s390x)
Are there any architecture conversion instructions available anywhere? (I.e. how to convert an existing s390 server to an s390x server?) Or is it a requirement that any s390x server must be installed from scratch? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/159624047.377743.1344686044198.javamail.r...@md01.wow.synacor.com
Re: Installing a custom kernel on Debian S/390(wheezy/sid)
On Sun, 05 Aug 2012 15:08:23 -0400 (EDT), Sampsa Laine wrote: > > I copied the two scripts into the /etc/kernel dirs. Good. Make sure the attributes are set properly. In particular, it's very important that the scripts be marked executable. Otherwise, they won't get run. > > Am in the progress of re-reading it for the third time now, > I think I've got most of it. > > I also looked in the /etc/kernel/post* dirs, I take it the dpkg > command will invoke zipl to add the relevant entries to the boot > loader? Yes. When dpkg installs the .deb package, the scripts in /etc/kernel/postinst.d will get run in alphabetical order. The three most important scripts in this directory are (1) initramfs-tools, which will build an initial RAM file system for the new kernel (2) zy-symlinks, which will maintain the symbolic links. (In particular, the most recently installed kernel will get the vmlinuz symbolic link, and the initial RAM file system which goes with it will get the initrd.img symbolic link.) (3) zz-zipl, which will run zipl to re-create the map file. The newly installed kernel will now be the default kernel. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/584641464.263119.1344196422624.javamail.r...@md01.wow.synacor.com
Re: Installing a custom kernel on Debian S/390(wheezy/sid)
On Sun, 05 Aug 2012 10:01:31 -0400 (EDT), Sampsa Laine wrote: > > Does anyone have any practical examples of this? I don't want > to bugger up my system (am of course backuping the DASD's > before any install step :) I know it's long, but I recommend that you read the entire web page before starting. There's a lot of material there, and many "gotchas" are documented. If you read the web page first, you will avoid most of the common "gotchas". If you are talking specifically about the hook scripts, what I use is the lynx browser (text mode only) to do the download. Bring up the web page in lynx under Debian for s390. Position to the first download link, then press "d" to download. Exit the browser, become root, move (mv) the file to /etc/kernel/postinst.d, change the group to root (chgrp), the owner to root (chown), and the attributes to 755 (chmod). Revert back to your non-root userid again, run lynx, position to the second download link, type "d" to download, exit lynx again, become root, move the second file to /etc/kernel/postrm.d, and change the group, owner, and attributes as before. Then edit /etc/kernel-img.conf and change do_symlinks to no. There are examples in the web page itself, but they are for the i386 architecture. Slight changes will need to be made in the kernel naming convention for s390 kernels, but other than that the examples in the web page itself should suffice. After reading the entire web page, if you still have specific questions, ask away. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1180210863.262657.1344192985512.javamail.r...@md01.wow.synacor.com
Re: Installing a custom kernel on Debian S/390(wheezy/sid)
Please reply to the list, not to me personally. Placing my reply on the list. On Sun, 05 Aug 2012 09:20:47 -0400 (EDT), Sampsa Laine wrote: > On 5 Aug 2012, at 16:09, Stephen Powell wrote: >> >> First of all, are you running Debian or Ubuntu? This is a Debian list. >> Advice you get here is going to be Debian-specific and may not work >> for Ubuntu. Debian has its own s390 port. > > Debian on the S/390 - I just thought I'd mention I installed Hercules > on the host machine which is running Xubuntu. Oh. >> >> Second, let me qualify my remarks by saying that I am not a member of >> the Debian s390/s390x port team and I do not speak for them: I am just >> an ordinary Debian user (including a Debian for s390 user). >> >> For building and installing custom kernels under Debian GNU/Linux, >> I recommend the web page >> >> http://users.wowway.com/~zlinuxman/Kernel.htm >> >> This is not an official Debian web page, but this is what I use. >> Take it with however many grains of salt you think it's worth. >> > > Yeah, found that page too. Does step 11 (Install the kernel image > package) work pretty much like they say on that page (thinking S/390 > bootloaders are pretty different from i386 ones)? The boot loader for s390 is ZIPL (part of the s390-tools package), which is similar to LILO in that it uses a list of blocks determined at map installer time to load the map file, kernel image, and initial RAM file system image into memory. It also is typically configured to use symbolic links, as LILO typically is too. The configuration file is /etc/zipl.conf. Step 11 is not where you will have your problem: Step 10 is. With ZIPL configured to use symbolic links and using a custom kernel created by make-kpkg under Squeeze and later releases, it will be necessary to install the two hook scripts called zy-symlinks. Read that section carefully. You must install these hook scripts BEFORE you install the kernel. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/16815096.259117.1344174939219.javamail.r...@md01.wow.synacor.com
Re: Installing a custom kernel on Debian S/390(wheezy/sid)
On Sun, 05 Aug 2012 07:04:02 -0400 (EDT), Sampsa Laine wrote: > > Guy, I've just finished installing the S/390 version of wheezy/sid > into a Hercules emulator (the one from the Xubuntu repositories, > seems to work fine). First of all, are you running Debian or Ubuntu? This is a Debian list. Advice you get here is going to be Debian-specific and may not work for Ubuntu. Debian has its own s390 port. > > Everything is working including networking, but to my dismay I noticed > there's no DECNET support compiled into the kernel (yes, I am that nuts, > I want DECNET on an S/390). > > Anyway, so I downloaded kernel sources for linux-2.6.32.59 (2.6.32.59 > seemed the closest to 2.6.32-45, which was shipped with the distro) > from kernel.org and did a make menuconfig. All went swimmingly. > > I am now running the proper "make" to build the kernel, and it seems > to be working fine, too. > > Now to my question: How do I _install_ this kernel, ideally as a new > boot option when I IPL the box. > > I assume I have to: > > 1. Generate a new initramdisk > 2. Put the kernel somewhere > 3. Put the new modules somewhere > 4. Modify the bootloader > > Now it's been a LONG time since I've done this (think slackware with > lilo and kernel 1.x) so I have no idea how to proceed, especially > on an S/390. > > Anyone got any pointers? > > As for my current setup, here's some data: > > #cat /etc/debian_version: > wheezy/sid > > #cat uname -a: > Linux version 2.6.32-5-s390x (Debian 2.6.32-45) (da...@debian.org) > (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sun May 6 03:12:45 UTC 2012 > > # cat /proc/version > Linux version 3.2.0-23-generic (buildd@crested) > (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu4) ) > #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 > > PS: In the future, could you guys maybe include DECNET support > in the mainstream kernel releases? Or is this a problem? Second, let me qualify my remarks by saying that I am not a member of the Debian s390/s390x port team and I do not speak for them: I am just an ordinary Debian user (including a Debian for s390 user). For building and installing custom kernels under Debian GNU/Linux, I recommend the web page http://users.wowway.com/~zlinuxman/Kernel.htm This is not an official Debian web page, but this is what I use. Take it with however many grains of salt you think it's worth. Finally, a request to include DECNET support in the kernel by default should probably be posted to the debian-kernel list. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2066589575.258688.1344172160670.javamail.r...@md01.wow.synacor.com
Re: S390 Release 6.0.5
On Thu, 14 Jun 2012 09:34:47 -0400 (EDT), Larry D Martin wrote: > > I am trying to boot from CD at the HMC into an LPAR but I cannot find > a valid mirror site. I have tried 6 or 7 in the US but it always > comes back and says not a valid mirror. > > Is there a list of valid mirrors for this S390 release? > > Thanks, .Larry A list of all published Debian mirrors can be found at http://www.debian.org/mirrors/list The architectures supported by each mirror are listed. Not all mirrors mirror all architectures. However, you may have a network connectivity problem. Are you using the correct network device in the correct mode? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2110422779.106696.1339849282670.javamail.r...@md01.wow.synacor.com
Re: [Linux/390] Problem to find packages (under z/VM 5.3.0 on a Z800 2066)
On Wed, 16 May 2012 12:58:12 -0400 (EDT), Christian Boitet wrote: > > Hi Philipp, Stephen, 16/5/12 > > maybe you remember us trying to install Debian > Linux for s390 (31 bits) on a H30 (MP3000) last > year? Yes, I remember. You were trying to install Lenny: the last release that supported 31-bit kernels. The proper place for this discussion is the debian-s390 mailing list, not private e-mails; so I have copied that list. I am subscribed to the list; so you needn't CC me. > > The bug in the installer was never found nor > corrected, so that we settled for a CentOS > version, that installed immediately. > > We have now moved to a Z800 (2066) under z/VM 5.30. > We are trying to install Debian Linux for x390 > (or s390x?, in any case 64 bits). Debian's implementation of Linux for s390/s390x works differently than most other distribution's implementation. In most (all?) other distributions, s390 and s390x are separate architectures. Debian, up to now, has taken a hybrid approach. The architecture designation is s390. The kernel has s390x in it's name somewhere, but is considered as belonging to the s390 architecture. The kernel executes in 64-bit mode, but the user space is still 31-bit. I seem to remember that a 64-bit user space was one of Debian's release goals for Wheezy, but I do not know what the current status of that goal is. Philipp knows much more about this than I do. But in any case, if you're installing the stable release (Squeeze), the architecture should be s390, not s390x, even though you are running on a z-architecture box. > > This time, the installer worked immediately (I > mean, sending the 3 files to the reader and > IPLing from there). > However, when we reach the point where packages > shouold be installed from a mirror, it blocks, > telling us that "this architecture is not > supported". > It was some time after the installer told us to > leave the 3270 emulated terminal and continue > using ssh (we did, from a PC and the from a Mac, > but got always the same error message). > > We got always the same error message, although we > tried 5 or 6 mirrors, in particular: > > ftp.fr.debian.org > (debian.proxad.net) /debian//debian/ > amd64 armel armhf hurd-i386 i386 ia64 > kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc > s390 s390x sparc > > ftp2.fr.debian.org > (ftp.oleane.net) /debian//debian/ > amd64 armel armhf hurd-i386 i386 ia64 > kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc > s390 s390x sparc > > ftp2.de.debian.org/debian/amd64 armel armhf > hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 > mips mipsel powerpc s390 s390x sparc > > The mirrors seem to have the necessary archives, > but the subdirectories and archives have names > like "Contents-s390.gz" and not > "Contents-s390x.gz". See my comments above. For now, use s390 as your architecture designation, not s390x, especially if you're installing the stable release (Squeeze). s390x definitely will not work for Squeeze. Wheezy, maybe. I don't know what the status of that project is. But Squeeze, definitely not. At some point later on in the install, you will be asked to select a kernel. At that point, you will be offered only 64-bit kernels. But the user space is still 31-bit. > > Achille (in copy) is a fan of Debian (on PC) and > has tried to help, to no avail. > > > Is there a simple solution to get the s90x packages in our configuration? Yes. See my comments above. > > Thanks & regards, > > Christian & Jean-Claude -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1965585554.1213112.1337211783121.javamail.r...@md01.wow.synacor.com
Re: Access to s390 porter machine
On Thu, 05 Apr 2012 03:58:11 -0400 (EDT), shahanawaz wrote: > > Hello Stephen > > I want to install Debian on Mainframe z10 EC, I was successfully booted it > through DVD but the problem is that it is not detecting any of the OSAs. And > while installing SUSE I didn't face any problem. > > Please guide me how to install it on LPAR. > > Regards > Shahanawaz I have never installed Debian in an LPAR. I have always used a virtual machine under z/VM. But it looks like Philipp Kern has already answered you. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2146879037.359708.1333672999628.javamail.r...@md01.wow.synacor.com
Bug#645836: Missing build dependency on libfuse-dev
Package: s390-tools Version: 1.13.0-1 Severity: minor When doing $ cd /usr/src $ apt-get --only-source source s390-tools $ su # apt-get --only-source build-dep s390-tools # exit $ cd s390-tools-1.13.0 $ dpkg-buildpackage -uc -b -rfakeroot I get build errors. The file "fuse.h" is not found during compilation. Installing package libfuse-dev seems to fix the problem. There seems to be a missing build dependency on libfuse-dev in source package s390-tools version 1.13.0-1. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1894056471.180352.1318982322393.javamail.r...@md01.wow.synacor.com
Re: Improvements to Debian for s/390 (was Java on Debian s/390)
On Wed, 21 Sep 2011 09:18:16 -0400 (EDT), Philipp Kern wrote: > On Sat, 10 Sep 2011 at 21:02:56 -0400 (EDT), Stephen Powell wrote: >> That's good news, Philipp. A 64-bit user space will be a >> welcome addition. > > Actually its focus is to be a replacement for the existing 31bit > userland. Right. I didn't mean to imply that the two user spaces would exist side by side. > On Sat, 10 Sep 2011 at 21:02:56 -0400 (EDT), Stephen Powell wrote: >> On a related topic, upstream "parted" at release 2.4 and later >> contains very useful enhancements for the s390 environment. >> ... > > Now that's an entirely different topic. That depends on how you look at it. If you look at it from the point of view of "previews of coming attractions in Debian for s390", then it's a related topic. > I trust in Colin's expertise > in that matter. I'm not questioning Colin's competency. I'm just eager for the benefits of the new release. > Maybe we can get the new upstream version in > time for the next release, though. That would be nice. And thanks for your reply. Regards, -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/124723420.2042932.1316657681053.javamail.r...@md01.wow.synacor.com
Re: Patch to enable build on s390x
On Thu, 15 Sep 2011 22:53:53 -0400 (EDT), Steve M. Robbins wrote: > > Hello GMP authors, > > I appreciate your interest in porting GMP to s390x. > > On Thu, Sep 15, 2011 at 05:20:38PM +0200, Torbjorn Granlund wrote: >> "Steve M. Robbins" writes: >>> >>> Hello GMP authors, >>> >>> I'd like to draw your attention to Andreas' patch >>> for building GMP on the 64-bit S390 (s390x): >>> http://article.gmane.org/gmane.comp.lib.gmp.general/2611 >>> >>> I just built 5.0.2 for Debian -- including this patch -- and, as >>> reported, all tests pass on both s390 and s390x. >>> >>> Would you consider adding this to the next release? >> >> As Marc has already pointed out, we have tried to work on this >> repeatedly, and the issue has not been dropped by us. >> >> None of the GMP developers have s390x access, and qemu-system-s390x >> cannot be persuaded to work with any (public) documentation. If the >> people that care about s390x GMP support do not reply to our simple >> questions, then it is almost guaranteed that no progress will be made. > > I do not have an s390x system, either. > > Andreas, Philip, and debian-s390 folks: can one of you please help > with porting GMP to s390x? Please see the thread starting here > > http://gmplib.org/list-archives/gmp-bugs/2011-September/002361.html > > for the inital questions. > > Thanks, > -Steve Have any of you tried using hercules? hercules is an s390/s390x emulation program that runs under Linux. You can use it, for example, to emulate an s390x machine on an amd64 Linux system, then run Linux for s390x under hercules. It's slow, due to the emulation, but it works. That's what Frans Pop used to do. hercules is free software, and it is pre-packaged for Debian and many other Linux distributions. If you have a Debian system, Issue "aptitude show hercules" for more information. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/764830344.1946869.1316262890044.javamail.r...@md01.wow.synacor.com
Improvements to Debian for s/390 (was Java on Debian s/390)
On Sat, 10 Sep 2011 11:43:59 -0400 (EDT), Philipp Kern wrote: > ... > And yes, s390x will hopefully come soon. That's good news, Philipp. A 64-bit user space will be a welcome addition. On a related topic, upstream "parted" at release 2.4 and later contains very useful enhancements for the s390 environment. Although these enhancements will be useful in the standard parted packages, the most important benefits will be in the udeb packages, those used by the Debian installer. They will, for example, allow installation to CMS minidisks, FBA DASD, and use of the DIAG driver for the first time. Yet the Debian package continues to use release 2.3. The package maintainer is aware of this, or should be, but I've seen no progress as of yet. Perhaps your influence might help. Respectfully yours, -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/631031160.1814313.1315702976411.javamail.r...@md01.wow.synacor.com
Re: Debian Version for System Z
On Fri, 13 May 2011 16:09:09 -0400 (EDT), Philipp Kern wrote: > > usually repacking IBM's RPMs as debs isn't a problem. I do that for TSM on > i386, amd64 and s390 and it works just fine. (That said, not with alien, > RPM would work too.) Most ISV software conforms to LSB and thus they ship > everything that's not guranteed to be present in the base system. So as > long as all this stuff is available in 64bit form we ought to be safe > if ISVs are compliant. Well then things have changed since I last messed with this. I remember trying to get an SSLSERV server for TCP/IP for z/VM 5.3.0 running. Back then the SSLSERV virtual machine needed to run Linux. IBM supported only Red Hat and Suse, of course, and they had only rpm packages. I had a devil of a time getting it to work. Also, if you do get it to work (almost) and have problems with it, and call IBM for support, IBM will tell you that Debian is not a supported environment and hang up. And then what good is the support that you're paying for? I love Debian for s390, but if I were going to use it I would want to use it in an all-open-source environment. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/362229342.557329.1305334610801.javamail.r...@md01.wow.synacor.com
Re: [Linux/390 under z/VM 4.2.0] more details on problem with lenny, but we could install centos 4.6, maybe a bug in debian somewhere?
On Thu, 12 May 2011 19:22:53 -0400 (EDT), Christian Boitet wrote: > Stephen Powell wrote: >> ... >> No, that's not right. Did you try an unmodified file, >> as I suggested? Here is the unmodified PARMFILE DEBIAN >> file, in hexadecimal ASCII. For readability, I have added a blank >> between each group of two hex digits: >> ... > > Yes we did. But we HAD to modify the file as it was in V format. All you would have to do would be PIPE < PARMFILE DEBIAN A|FBLOCK 80 00|> PARMFILE DEBIAN2 A F ERASE PARMFILE DEBIAN A RENAME PARMFILE DEBIAN2 A = DEBIAN = That does not require editing. But if you use the CMS FTP client and say "binary f 80", it should download as format F. The only file that needs to be downloaded in ascii mode is DEBIAN EXEC. Then, to fix up DEBIAN EXEC you do something like: PIPE < DEBIAN EXEC A|JOIN *|SPLIT AT X25|> DEBIAN EXEC2 A ERASE DEBIAN EXEC A RENAME DEBIAN EXEC2 A = EXEC = Note that the SPLIT stage of CMS Pipelines looks for X25 as the terminator (the EBCDIC linefeed character) instead of X0A as the terminator (the ASCII linefeed character), since downloading the file in ascii mode using the CMS FTP client will result in an ASCII- to-EBCDIC translation. > > Was it wrong to put the terminator at position 80, after padding with > spaces (X'20')? Possibly. There are two "terminators" here. The linefeed and the null. It may need both. The linefeed ends a logical line, and a null terminates a string of characters in C. > > We'll check it again (no access from here), > because, if "par malheur" we produced something > like > > 72 6f 20 6c 6f 63 61 6c 65 3d 43 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0A No, there should not be embedded nulls in a line. >> >> Apparently you don't have TCP/IP for z/VM installed on this >> system? > > TCP/IP works on our z/VM, under CMS, but ftp does > not work well on all virtual machines, for some > unidentified reasoon. For example, on our LINUX7 > machine, ftp will not go down the hierarchy of > the mirror, while it does on LINUX3. Something is fishy here. Why would the CMS TCP/IP client work on one virtual machine and not on another? Perhaps you don't have a disk accessed that you need, such as the TCP/IP client code disk (TCPMAINT 592)? My advice is to figure out why the CMS FTP client doesn't work, fix it, and use the CMS FTP client to download the files, with "binary f 80" in effect (except for debian.exec, which requires "ascii"). Then try an install without touching PARMFILE DEBIAN. Your file transfer steps are too cumbersome, and your editing is flawed. Keep it simple. Get the CMS FTP client working. >> >> At this point, I suspect the problem has something to do with how >> the files get from the Debian mirror to the CMS disk. But you also >> might want to check to see if there are any APARS against the z/VM >> 4.2.0 CP component that are Linux-related. I'm not familiar with >> the maintenance for 4.2.0 as I have not used it in nearly six years. > > I don't think so as we succeeded in installing a > CentOS 4.6 on our LINUX7 today. > As one of us is a fan of Debian, plus Centos 4.6 > dates back to 2008 and seems to be the latest > available for s390 *and* s390x, we would like to > contribute to Debian in solving this small > mystery, and go back to it for several or all our > Linux/390 virtual machines. Well, it's possible there is a bug in Lenny. But if there is, it's not going to be fixed. It's two releases out of date. And many others have installed it successfully. I just thought of something else to check. Make sure that the CP directory says MACHINE XA not MACHINE ESA On some older releases of z/VM, "MACHINE ESA" meant a virtual machine that was capable of being switched to z/Architecture mode, while "MACHINE XA" meant a virtual machine that could not be switched. I may be grasping at straws here, but it's something to check. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/693614844.557166.1305333635029.javamail.r...@md01.wow.synacor.com
Re: Debian Version for System Z
On Thu, 12 May 2011 10:39:17 -0400 (EDT), Saulo Silva wrote: > > You answered me what I want to understand . Just to clarify . The other > distro treat s390 as 31-bits and s390x as 64-bits and Debian doesn't . My > question is : I will be able to run the s390x applications from ISVs based > on other s390x linux distro at the Debian 6 running with 390x kernel ? > could I say that we have the same Linux from any other s390x distro that we > have with s390x Debian ? Well, as Bill Bitner often says, "It depends." It depends on what you mean by an ISV. Obviously that means "Independent Software Vendor". But let's take a specific example. Let's suppose that you want to run IBM's DB2 Universal Database for Linux. That's a closed-source, proprietary, object- code-only product. The last time I checked, they did not offer a version packaged for Debian. You see, Red Hat and Suse are "IBM Business Partners". And they both use the Red Hat Package Management format (.rpm format). So IBM's binary packages are in .rpm format. Debian uses the Debian Package Management format (.deb format). Although it is theoretically possible, in some cases, to install a .rpm package to a Debian system (using "alien" for example), it's probably not something you want to do. And in this specific case, it may not even be possible. If you try to install an s390x-architecture rpm package on Debian, you're likely to see the install fail with an architecture conflict (s390 vs s390x). Plus, the .rpm package was compiled with the C compiler that was current in the intended target distribution, which may or may not work with the C run- time libraries in Debian, etc. In short, only install a binary package that has specifically been packaged for Debian. If you have the source code, you can compile it yourself, if need be. But lots of luck getting the source code for DB2 from IBM. ;-) On the other hand, if you are using postgresql or mysql, which are open source, there's no problem. The source code is available, and you can compile it yourself. But in most cases, that's not necessary. Both of those products, as well as about 25,000 others, are already packaged for Debian. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/849409142.538013.1305251619627.javamail.r...@md01.wow.synacor.com
Re: Debian Version for System Z
On Wed, 11 May 2011 14:21:29 -0400 (EDT), Saulo Silva wrote: > > I would like to know about the current release of the Debian Linux for Z . > And if that is a 64bit linux compile . I'm not sure I understand your question. Debian GNU/Linux has had an s390 port since 3.0 (Woody). Some other Linux distributions treat s390 and s390x as separate architectures. Debian does not. Debian treats both ESA/390 processors and z/Architecture processors as belonging to the s390 architecture, or "port". Debian does provide two different flavors of kernel, however. The s390 flavor runs on either an ESA/390 processor or a z/Architecture processor. The s390x flavor runs only on a z/Architecture processor. Older releases of Debian provided only the s390 flavor. For a while, a single release of Debian provided both flavors, at the user's choice. I'm not sure which was the first release that provided the s390x flavor, but I do know that Lenny (Debian 5.0) was the last release to provide the s390 flavor. Starting with Squeeze (Debian 6.0), only s390x kernel flavors are provided. The s390x flavor of kernel puts the processor into z/Architecture mode shortly after IPL, and the processor stays in z/Architecture mode thereafter. Debian does not have a 64-bit user space, however. The kernel (and it's modules) run in 64-bit mode. But user-space applications currently run in 31-bit mode. Thus, a single user-space process is limited to 2G of (virtual) memory. But the system can make use of more than 2G of real memory, since the kernel can allocate (in theory) up to a 2G address space to EACH user-space process. HTH -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1158730820.516480.1305170419317.javamail.r...@md01.wow.synacor.com
Re: [Linux/390 under z/VM 4.2.0] CP works forever (Lenny): new attempt
Wed, 11 May 2011 10:20:12 -0400 (EDT), Christian Boitet wrote: > At 7:42 -0400 11/05/11, Stephen Powell wrote: >> First, please do not "top post" on this list. (See >> http://en.wikipedia.org/wiki/Top-posting#Top-posting for >> more details.) Please use the usenet, or "bottom posting" style. > > I don't see how Jean-Claude could "top-post" as he wrote a new message. > I take it as an advice for later messages such as this one. I don't think you understand. Look at Jean-Claude's post: http://lists.debian.org/debian-s390/2011/05/msg5.html The new material is at the top. The quoted material is at the bottom. That's top-posting. This post is an illustration of the posting technique that we prefer on this list (and all the Debian lists). Questions and answers are interleaved, and the question appears before the answer. Not all material from the earlier post need be quoted if it is not needed to establish a context to the replies in the new post. That's called, "trimming your posts". > > To answer you: yes we know well about binary and F 80 etc. > I myself edited under Xedit the ASCII version of > PARMFILE (already put in F 80). > I replaced the last character (X'20', a space), in position > 80, by X'0A'. We both know CMS and XEDIT quite well. > Jean-Claude wrote a tree editor all in REXX for > use under XEDIT for his PhD, and I wrote many > XEDIT macros... I can't see which mistake we > could have done. But we sure did one! I'm not questioning anyone's competence in general z/VM matters: I'm only giving you a check list of common causes of problems. > > To be sure, we retransferred the PARMFILE (in > binary, by ftp) on a Mac under MacOSX and > verified that the file was indeed in ASCII and > had the terminator in position 80 (only ONE > character, not 2 like under Windows). No, that's not right. Did you try an unmodified file, as I suggested? Here is the unmodified PARMFILE DEBIAN file, in hexadecimal ASCII. For readability, I have added a blank between each group of two hex digits: 72 6f 20 6c 6f 63 61 6c 65 3d 43 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 That's "ro locale=C" (without the quotes), followed by a linefeed character, followed by 68 nulls. Before you try monkeying with the file at all, just try the raw binary download, with no modifications. I know you want to add extra stuff when you do your actual install, but this is a diagnostic step. > > Considering the source: yes we took the files > from "generic" ... Good. > ... and made sure to get a lenny version (5.0.8). Good. > SOMETHING is a bit strange and might help: > immediately after the "IPL 00C" command is > issued, what is read from the reader seems to > cause another "CHANGE RDR ALL KEEP NOHOLD" > as we get the message: > 003 FILES CHANGED That is a normal message. You didn't change the DEBIAN EXEC file, did you, to eliminate the "PURGE RDR ALL" command? Otherwise, you will keep accumulating reader files but you will always IPL the oldest ones, which of course never change. > > Another question is, if the PARMFILE were wrong, > could it put the IPL process in a loop? If it doesn't see the terminator it expects, it may read part of the initial RAM disk as parmfile information. Thus, the initial RAM disk will be corrupted and unusable. Who knows what will happen then? > In order to get the KERNEL and INITRD files > (already transferred in binary) in F80, we used > the CMS PIPE command as shown in the IBM > documentation: > > PIPE < fn1 ft1 fm1 | FBLOCKS 80 | > fn2 ft2 fm2 F 80 Almost. Try PIPE < fn1 ft1 fm1 | FBLOCK 80 00 | > fn2 ft2 fm2 F 80 Apparently you don't have TCP/IP for z/VM installed on this system? I'm used to using the CMS FTP client to transfer the files. It makes things much easier. In newer versions of z/VM, TCP/IP for z/VM comes bundled with z/VM at no extra charge. But at the z/VM 4.2.0 level, perhaps TCP/IP is still a separate product? I don't remember. Please explain the EXACT steps you go through to transfer the file to a CMS minidisk, in detail, plus all post-processing you do on the file once it arrives on the CMS disk but before you run the DEBIAN EXEC file. > > If there is a problem there, maybe you could help > us detect it by comparing the lengths? PARMFILE DEBIAN is 1 record (fixed length, 80 bytes). INITRD DEBIAN is 34861 records (fixed length, 80 bytes) KERNEL DEBIAN is 42020 records (fixed length, 80 bytes) > > Should we pos
Re: [Linux/390 under z/VM 4.2.0] CP works forever (Lenny): new attempt
On Wed, 11 May 2011 05:21:52 -0400 (EDT), Jean-Claude Durand wrote: > > I return to our problem with the installation of a Debian/Lenny > version on our mainframe (a Multiprise Series 3000 Model H30, > 32 bits running z/VM V4.2.0). You can see below the > different steps of a new attempt which remains unsuccessful. > > Could you help ? > > Thanks and best regards. > Jean-Claude Durand > > LIG, équipe GETALP > 385, rue de la Bibliothèque, BP 53 > 38041 Grenoble cedex 9 > > 1. I got the for files from: > http://ftp.debian.org/debian/dists/lenny/main/installer-s390/current/images/ > > (the files with their size: > 2788877 24 nov 22:06 initrd.debian > 3361536 24 nov 22:06 kernel.debian) > > 2. The the files after they have been reblocked: > > Filename FiletypeFm Format LreclRecords Blocks > DEBIANEXECA1 V40 10 1 > KERNELDEBIAN A1 F80 42020798 > INITRDDEBIAN A1 F80 34861681 > PARMFILE DEBIAN A1 F80 1 1 > > 3. We added some parameters to the parmfile.debian in order to have > some debug information: > > ro locale=C debconf/priority=low DEBIAN_FRONTEND=text BOOT_DEBUG=2 > > 4. And we got CP running forever: > > q time > TIME IS 08:33:44 EST WEDNESDAY 05/11/11 > CONNECT= 00:01:54 VIRTCPU= 000:00.10 TOTCPU= 000:00.14 > Ready; T=0.01/0.01 08:33:44 > exec debian > 3 *-* PURGE RDR ALL > >>> "PURGE RDR ALL" > 003 FILES PURGED > 4 *-* 'SPOOL PUNCH * RDR' > >>> "SPOOL PUNCH * RDR" > 5 *-* 'PUNCH KERNELDEBIAN A (NOHEADER' > >>> "PUNCH KERNELDEBIAN A (NOHEADER" > RDR FILE 0066 SENT FROM LINUX7 PUN WAS 0066 RECS 042K CPY 001 A NOHOLD > NOKEEP > 6 *-* 'PUNCH PARMFILE DEBIAN A (NOHEADER' > >>> "PUNCH PARMFILE DEBIAN A (NOHEADER" > RDR FILE 0067 SENT FROM LINUX7 PUN WAS 0067 RECS 0001 CPY 001 A NOHOLD > NOKEEP > 7 *-* 'PUNCH INITRDDEBIAN * (NOHEADER' > >>> "PUNCH INITRDDEBIAN * (NOHEADER" > RDR FILE 0068 SENT FROM LINUX7 PUN WAS 0068 RECS 035K CPY 001 A NOHOLD > NOKEEP > 8 *-* CHANGE RDR ALL KEEP NOHOLD > >>> "CHANGE RDR ALL KEEP NOHOLD" > 003 FILES CHANGED > 9 *-* Q RDR > >>> "Q RDR" > ORIGINID FILE CLASS RECORDS CPY HOLD FORM DEST KEEP MSG > LINUX7 0066 A PUN 00042020 001 NONE STANDARD OFF ON OFF > LINUX7 0067 A PUN 0001 001 NONE STANDARD OFF ON OFF > LINUX7 0068 A PUN 00034861 001 NONE STANDARD OFF ON OFF > 10 *-* CP IPL 000C CLEAR > >>> "CP IPL 000C CLEAR" > 003 FILES CHANGED > > CP Q T > TIME IS 08:35:13 EST WEDNESDAY 05/11/11 > CONNECT= 00:03:23 VIRTCPU= 000:47.93 TOTCPU= 000:50.38 > > CP IND LOAD > AVGPROC-100% 01 > MDC READS-01/SEC WRITES-01/SEC HIT RATIO-100% > STORAGE-064% PAGING-/SEC STEAL-000% > Q0-6 Q1-0 Q2-0 EXPAN-001 Q3-0 EXPAN-001 > > CP Q T > TIME IS 09:16:53 EST WEDNESDAY 05/11/11 > CONNECT= 00:45:03 VIRTCPU= 040:07.99 TOTCPU= 040:15.97 > Jean-Claude, First, please do not "top post" on this list. (See http://en.wikipedia.org/wiki/Top-posting#Top-posting for more details.) Please use the usenet, or "bottom posting" style. Second, be sure you have downloaded the files in "binary" (except for DEBIAN EXEC) as opposed to "ascii", "ebcdic", or "text" mode (depending on the method of download). This is important to avoid unwanted (and fatal) ASCII to EBCDIC translations and also to avoid linefeed or carriage-return/linefeed sequences being added. Make sure the files are downloaded from the "generic" subdirectory, not the "tape" subdirectory. Third, just for grins, try using the unmodified PARMFILE DEBIAN file. If that works, you can abort the installation and try again with a modified one. I think that is the most likely cause of trouble. It is VERY important that the last used charater be followed by a linefeed (X'0A' in ASCII, X'25' in EBCDIC). XEDIT tends to remove this terminator. The line must be filled with nulls (X'00' in either code) after the terminator out to 80 bytes. (Use "SET NULLS ON" in XEDIT.) I would issue SET VERIFY OFF H 1 80 in XEDIT just prior to the "FILE" command to verify the trailing linefeed and trailing nulls. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/612580459.495053.1305114127451.javamail.r...@md01.wow.synacor.com
Re: [Linux/390 under z/VM 4.2.0] CP works forever (Lenny)
On Sat, 09 Apr 2011 09:16:13 -0400 (EDT), Stephen Powell wrote: > I will explain the installation steps in detail. > Maybe there's something you're missing. > ... One more thing I forgot to mention. I'm not sure if the kernel boot messages are written to the virtual 3215 console or if they're written to the Service Console Logical Processor (SCLP) internal console and re-routed to the 3215 virtual console by CP. I suspect the latter is the case, since that method would work in both a virtual machine and in an LPAR. (In an LPAR, the corresponding output device is the "Operating System Messages" icon on the Hardware Management Console (HMC) or the Support Element (SE). If that is the case, then your release of z/VM must have support for virtualizing the SCLP interface. See if CP supports a VINPUT command (HELP CP VINPUT). If it does, then you should be OK. If it doesn't, they you might be in trouble. I know for sure that zipl requires a virtualized SCLP interface by CP. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1638847192.132768.1302355944061.javamail.r...@md01.wow.synacor.com
Re: [Linux/390 under z/VM 4.2.0] CP works forever (Lenny)
On Thu, 07 Apr 2011 11:49:00 -0400 (EDT), Christian Boitet wrote: > At 22:23 -0400 5/04/11, Stephen Powell wrote: >> On Tue, 05 Apr 2011 20:50:23 -0400 (EDT), Christian Boitet wrote: >>> Bonsoir Stephen, >>> >>> we are trying to upgrade some virtual machines >>> under a 2004 RedHat Linux/390 to an up-to-date Debian >>> ... >>> Could you help? >>> ... >> >> A multiprise 3000 model H30? Isn't that an ESA/390 processor? >> In other words, it's not capable of z/Architecture mode, correct? > > Yes, you are 100% right, our fault. I should have > known, because I read somewhere we should not use > Squeeze on a H30. We actually experienced > recently similar problems on Mac OSX with > programs in 32 and 64 bits, in ANTLR, and kernel > in 32 bits or 64 bits. > > We are planning to upgrade in June to a z box > (z800) as you suggest, but in the meantime we > would like to use 6 or 7 VM under Linux/390 under > z/VM 4.2.0 on our multiprise 3000 model H30. > > Still a problem with Lenny ... > > This time, CP does not go into "interrupt loop", > but seems to compute forever after "IPL 000C CLEAR". > It says "03 FILES CHANGED" and then no messages appear. > > I don't think it would be useful to write to the > whole list as this moment, because I saw nobody > but you answering questions precisely. Maybe we > should if the next trial also fails, after all! > > Many things for the detailed info. I keep it in this > e-mail for the moment. I don't mind if you CC debian-s390@lists.debian.org, because that is where this discussion belongs. But please don't send a copy to the bug log for bug 621080. That is a totally unrelated bug report. Your long, unrelated post to that bug log has no doubt annoyed the maintainer and reduced my chances of getting the enhancement request. I'm not sure how that happened. Perhaps you tried to "reply to all" to a post on the list. What you should have done is start a new thread. Please submit a *short* apology to 621...@bugs.debian.org for the unrelated and unintended post. There are others who answer questions on the s390 list besides me. But the real point is that someone else may have a similar problem to yours a few months from now. If I help you in a private e-mail, I solve your problem. But if I help you on the list, someone else searching the internet may find it. We have to think of others too and not just ourselves. I cannot reproduce your problem because I don't have the hardware (Multiprise 3000) or the software (z/VM 4.2.0) to reproduce your problem. My hardware is a z/890 and I run z/VM 5.4.0. So at the risk of insulting your intelligence, I will explain the installation steps in detail. Maybe there's something you're missing. (1) Choose a Debian mirror. I will use ftp.uwsg.indiana.edu in this example. You'll probably want to use a mirror closer to home. For a full list of Debian mirrors, see http://www.debian.org/mirrors/list. (2) Logon to the virtual machine that you will install to and IPL CMS. Make sure that the TCP/IP client code disk is accessed (TCPMAINT 592). Make sure that the "A" disk is large enough to handle the downloads. >From a CMS "Ready;" prompt, issue - FTP ftp.uwsg.indiana.edu anonymous you...@yourdomain.com passive binary f 80 cd /linux/debian cd dists/lenny/main/installer-s390/current/images/generic get kernel.debian KERNEL.DEBIAN get initrd.debian INITRD.DEBIAN get parmfile.debian PARMFILE.DEBIAN ascii get debian.exec DEBIAN.EXEC close quit PIPE < DEBIAN EXEC A|SPLIT AT X25|> DEBIANX EXEC A ERASE DEBIAN EXEC A RENAME DEBIANX EXEC A DEBIAN = = CP SPOOL 000C CLASS * DEBIAN - I assume that z/VM 4.2.0 includes CMS Pipelines. I can't remember. If not, then the PIPE command will not work. In that case you will have to manually edit DEBIAN EXEC A to remove the X'25' characters (EBCDIC line feed characters) and split the lines. I tried it yesterday, and it works on my hardware. I verified that the Lenny installer does indeed use a 31-bit kernel (2.6.26-2-s390) and not a 64-bit kernel (2.6.26-2-s390x); so, in theory, it should work. You will perform the first few steps, such as configuring the network device and configuring the network, from the virtual 3215 console. After that, you must continue the installation by logging in remotely using an SSH client. If your desktop operating system is Windows, I recommend PuTTY as the SSH client. It is free software from Simon G. Tatham, available here: http://www.chiark.greenend.org.uk/~sgtatham/putty/ I use a virtual OSA in QDIO mode (a NICDEF entry in the CP directory which is attached to a virtual switch) as the network device for my virtual machines, but I don't
Bug#621080: Improving the s390 boot process
es. However, until this bug (i.e. enhancement request) and all the other bugs against sysconfig-hardware mentioned in this bug report are fixed, the kernel method is the only method that is fully functional. Notes: (1) The "manual_add_modules dasd_diag_mod" line in /etc/initramfs-tools/hooks/sysconfig-hardware is what causes the dasd_diag_mod kernel module to be included in the initial RAM file system, since I use MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy. This is preferable to listing it in /etc/initramfs-tools/modules because listing it in /etc/initramfs-tools/modules also causes initramfs-tools to attempt to load it when it comes to the point of "loading essential drivers". It may be too late by then. The only way to make sure that dasd_diag_mod gets loaded at the proper time is to use the two "softdep" lines in /etc/modprobe.d/dasd.conf, as shown above. (2) Note that /lib/udev/rules.d/85-sysconfig-hardware.rules was included in the initial RAM file system, but /lib/udev/rules.d/65-sysconfig-hardware-net.rules was not. I did not deem it necessary to fully configure network devices prior to the initial read-only mount of the permanent root file system. Network devices, such as an OSA, will have their configuration finished after the permanent root file system is initially mounted read-only. (3) In an attempt to reduce the size of the initial RAM file system, I attempted to remove all the "bashisms" from the scripts belonging to sysconfig-hardware; so it would be able to run under ash. This would allow me to avoid including /bin/bash in the initial RAM file system. Most of the bashisms could be easily eliminated, but arrays were a problem. For example, my OSA configuration file, /etc/sysconfig/hardware/config-ccw-0.0.0300, contains the following: CCWGROUP_CHANS=(0.0.0300 0.0.0301 0.0.0302) This is an array assignment statement, which gets "sourced" into /etc/sysconfig/scripts/hardware/hwup-ccw-group during execution. bash supports arrays, but ash does not. In the end I decided that it was more trouble than it was worth and left them all as bash scripts. Thus, /bin/bash had to be included in the initial RAM file system. Initial RAM file system size is not really a problem in s390. For one thing, s390 has a lot fewer device driver modules to deal with than, say, the i386 architecture. Also, s390 is not subject to a 16M memory restriction, as LILO is on the i386 architecture for some machines with a very old BIOS. zipl can access up to 2G of RAM. (4) Note that in my example the vmhalt=LOGOFF and vmpoff=LOGOFF kernel boot parameters are used. For a Linux system running in a virtual machine under z/VM, this causes the CP LOGOFF command to be issued during shutdown when a "halt" or "power-off" signal is received. But this only works if the vmcp kernel module is loaded. I list vmcp in /etc/modules to accomplish this. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1555455293.56289.1302089676441.javamail.r...@md01.wow.synacor.com
Re: Debian 6 - qdio Device
On Thu, 17 Feb 2011 10:49:54 +0100, Philipp Kern wrote: > On Thu, Feb 17, 2011 at 10:35:46AM +0100, Riedel, Alexander wrote: >> I the meantime i have found the cause for the problem. >> >> In /etc/udev/rules.d are old rules from Debian 5. >> I have deleted now this rules and everything is working fine. > > Well, when I looked at it some days ago it left me wondering why they're in > /etc in the first place. After all they override files in /lib/udev/rules.d > with the same content. Shouldn't people rather copy them to /etc to modify > them and then live with the consequences instead of having trouble on > upgrades? Since my initial response to this message I have done some more research on udev, and I now agree with you 100%. In my initial response I said something about how the copies in /etc/udev/rules.d were intended to be "user editable". There is an element of truth to that. I'm thinking, for example, of /etc/udev/rules.d/70-persistent-net.rules, on the i386 architecture, which is generated by /lib/udev/write_net_rules. This file assigns network interface names (eth0, eth1, etc.) based on the MAC address and is user-editable so that the user can decide which MAC address to assign to which interface. However, in the case of 65-sysconfig-hardware-net.rules and 85-sysconfig-hardware.rules, these are not generated files and contain nothing that would ordinarily be considered user-customizable. I can see no reason for them to be in both /lib/udev/rules.d and /etc/udev/rules.d. There seems to be conflicting evidence here. According to the web page http://packages.debian.org/squeeze/s390/sysconfig-hardware/filelist the two rules files exist only in /lib/udev/rules.d. But according to /var/lib/dpkg/info/sysconfig-hardware.list on my actual installed system, they exist in both places. I have erased the copies in /etc/udev/rules.d on my system. Perhaps this will save me some trouble on the next upgrade. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/749784506.1864988.1301623758345.javamail.r...@md01.wow.synacor.com
Re: gdm3 on s390
On Tue, 22 Mar 2011 11:22:53 -0400 (EDT), Alexander Riedel wrote: > > does anybody have succesfully running gdm3 on a s390? > On my old system i used it to get over vnc a login-mask for gnome. > > But in debian 6 i am not able to start gdm3. It is restarting the whole > time, because > it is not finding a /dev/tty0 . I have only /dev/console (z/VM) and > /dev/ttysclp0 (HMC-Ascii-console) You can't run an X server on s390 because s390 has no graphical console to display things on, as you noted above. It is possible to run graphics applications on s390 (i.e. an X client) but they must be connected over the network to a remote server (i.e. a PC running the X server). I know this is possible. But I don't recommend it. As much as I like the mainframe, it really wasn't designed for this type of application. The mainframe is much better suited for back-end servers, such as SQL databases, web servers, ftp servers, etc. Just think about it. All the user interface devices (keyboard, mouse, graphical display) are on a remote PC and all those screen updates and mouse mickeys (yes, that is what they are called) have to go across a high-bandwidth network connection to keep decent response time. It chews up a lot of network bandwidth and (very expensive) mainframe CPU cycles. It's possible to do, but in my humble opinion it just isn't the right platform for this type of application. You're better off doing something like a browser-based application, with the browser running on somebody's PC and the web server and its server-side programming running in a virtual machine under z/VM. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1313605023.1646656.1300835878597.javamail.r...@md01.wow.synacor.com
Re: Debian 6 - qdio Device
On Thu, 17 Feb 2011 04:49:54 -0500 (EST), Philipp Kern wrote: > On Thu, Feb 17, 2011 at 10:35:46AM +0100, Riedel, Alexander wrote: >> I the meantime i have found the cause for the problem. >> >> In /etc/udev/rules.d are old rules from Debian 5. >> I have deleted now this rules and everything is working fine. > > Well, when I looked at it some days ago it left me wondering why they're in > /etc in the first place. After all they override files in /lib/udev/rules.d > with the same content. Shouldn't people rather copy them to /etc to modify > them and then live with the consequences instead of having trouble on > upgrades? I'm no udev expert; but in the general case, I believe that the files in /lib/udev/rules.d are intended to be templates used to generate the files in /etc/udev/rules.d. The files in /etc/udev/rules.d tend to be tailored to the user's environment in some way. For example, the MAC addresses of the network adapters being used are typically present in the versions in /etc/udev/rules.d. s390 is a special case in that, when the OSA is in layer 3 mode, as mine is, there are no MAC addresses in the files. In many cases, erasing one of the files in /etc/udev/rules.d will cause a new one to be generated at the next boot up, but it may or may not be what the user wants. This is particularly the case when the system has more than one network adapter. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1978325157.896429.1297996626019.javamail.r...@md01.wow.synacor.com
Re: Debian 6 - qdio Device
On Wed, 16 Feb 2011 10:45:04 -0500 (EST), Alexander Riedel wrote: > > I have upgraded my Debian 5 to Debian 6 but after that my network-devices > Are not started automatically. I have to load manually the driver qeth_l2 and > qeth > And also to group the devices and set it online before i can take the > interface up. > > What do i have to change to get this automatically as before ? Hello, Alexander. I had the same problem. See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=612707 for a description of how I solved it. Reviewing outstanding bugs against the "upgrade-reports" pseudo-package is a good idea when you are having upgrade problems. Sometimes, someone else has had the same problem already. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1493423426.872374.1297912786528.javamail.r...@md01.wow.synacor.com
Re: IBM z/VM + z/Series + Debian
On Tue, 16 Nov 2010 09:19:37 -0500 (EST), anandhakrishn...@tcs.com wrote: > Stephen Powell wrote: >> >> The installation instructions don't contain much detail on this step. >> Here is what it says: >> >> - >> >> 3.6.4. Setting up an installation server >> >> If you don't have a connection to the Internet (either directly or via >> a web proxy) you need to create a local installation server that can >> be accessed from your S/390. This server keeps all the packages you >> want to install and must make them available using NFS, HTTP or FTP. >> >> The installation server needs to copy the exact directory structure >> from any Debian GNU/Linux mirror, but only the s390 and >> architecture-independent files are required. You can also copy the >> contents of all installation CDs into such a directory tree. >> >> - >> >> As I said in my previous post, I have no experience installing Debian from >> a private mirror. I have never used a private mirror because I have never >> needed to use a private mirror. At my installation, the virtual Linux >> servers >> on z/VM have access to the external internet. Therefore, I can use a >> public >> mirror for installation. Therefore, I do. >> >> If due to your installation policy the virtual Linux servers are not >> allowed >> to access a public mirror then you must create a private mirror and >> install >> from that. Instructions for creating a private mirror can be found here: >> >>http://www.debian.org/mirrors/ftpmirror >> >> If you need help creating a private mirror, ask for help on the >> debian-mirrors >> mailing list (debian-mirr...@lists.debian.org). >> > > Am still not able to sort out the problem. It will be great that if you > clear my doubts that are prevailing, > > * What is the size of the debain mirror for s390? I don't know. As I said, I have always used a public mirror; therefore, I have never attempted to set up a private mirror. Therefore, I really don't know how much space is required for a private mirror. I'm sure it depends on which releases and which architectures you mirror. Again, ask this kind of question on debian-mirr...@lists.debian.org. > * What size is required in z/vm to install the debian linux? That, of course, depends on which packages you install. You can find my standard configuration described on http://www.wowway.com/~zlinuxman/diag250.htm This seems to be adequate for a "standard system", as long as you don't have to compile a custom kernel. I'd add another 1000 cylinders to / if you need to do that. > * In referring to debain mirrors, there are some points reg resync? Again, I know nothing about setting up a private mirror. Ask these kinds of questions on debian-mirr...@lists.debian.org Your private mirror must be placed in your network in such a location that it can sync up with a public mirror, if you're going to keep it up-to-date, yet the private mirror must be accessable to the TCP/IP stack of the virtual Linux server. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1188459640.453548.1289962926777.javamail.r...@md01.wow.synacor.com
Bug#600100: zipl's postinst hook fails upon initial kernel installation by d-i
On Wed, 13 Oct 2010 13:31:26 -0400 (EDT), Philipp Kern wrote: > > The initial kernel installation through d-i fails with the current squeeze d-i > due to zipl's postinst failing. It obviously doesn't have a configuration > file > yet, because it will be configured in the step after kernel installation: I am not a package maintainer for s390-tools; I am a user who is an interested party to this bug report. This bug is related to bug number 599931, and the hook script templates provided in the body of bug report 599931 will fix both that problem and this one. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1677940689.14215.1287061660203.javamail.r...@md01.wow.synacor.com
Bug#599931: zipl hook scripts invoke zipl multiple times
Package: s390-tools Version: 1.8.3-2 Severity: wishlist The zipl hook scripts, /etc/kernel/postinst.d/zz-zipl and /etc/kernel/postrm.d/zz-zipl, invoke zipl multiple times. It would be good to incorporate logic similar to that included in the initramfs-tools hook script so that zipl only gets invoked once. For example, at the time of this writing, /etc/kernel/postinst.d/zz-zipl looks something like this: - #!/bin/sh exec zipl &2 - This script is called both for pre-configuration and for configuration, causing zipl to be invoked twice. Consider instead the following logic: - #!/bin/sh set -e # Avoid executing multiple times. if [ -n "$DEB_MAINT_PARAMS" ];then eval set -- "$DEB_MAINT_PARAMS" if [ -z "$1" ] || [ "$1" != "configure" ];then exit 0 fi fi if [ -f /etc/zipl.conf ];then zipl >&2 else echo "WARNING, not invoking zipl: /etc/zipl.conf not found" >&2 fi - This script exits without invoking zipl when invoked during pre-configuration, but does invoke zipl during configuration. (It also does not invoke zipl if zipl's configuration file is not found.) Similarly, /etc/kernel/postrm.d/zz-zipl currently looks something like this: - #!/bin/sh exec zipl &2 - This script is invoked for a remove and also for a purge. When a purge is done, the script is called twice: first for the remove process, then a second time for the purge process. Thus, zipl gets executed twice. Consider instead the following logic: - #!/bin/sh # Avoid executing multiple times. if [ -n "$DEB_MAINT_PARAMS" ];then eval set -- "$DEB_MAINT_PARAMS" if [ -z "$1" ] || [ "$1" != "remove" ];then exit 0 fi fi if [ -f /etc/zipl.conf ];then zipl >&2 else echo "WARNING, not invoking zipl: /etc/zipl.conf not found" >&2 fi exit 0 - This logic causes the script to exit without invoking zipl when called for purge processing, but allows zipl to be invoked during remove processing. (It also forces a clean exit in case of an error from zipl, which is desirable during a remove.) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1100484582.59372.1286894101419.javamail.r...@md01.wow.synacor.com
Re: IBM z/VM + z/Series + Debian
On Thu, 30 Sep 2010 02:09:40 -0400 (EDT), anandhcoe wrote: > > Thanks for your valuable suggestion. I had set up an anonymous ftp for > the installation and yet the problem prevails.The error msg below is shown. > >"The specified Debian archive mirror is either not available, or does > not have a valid Release file on it. Please try a different mirror. " > > Are there any release files or repository file needed for this and in the > image which i have download i cant find any release file or something like > that. > > Could you please help on the issue and let me know if there is any other > link where i can download the Debain Linux full version with the release > files.. The installation instructions don't contain much detail on this step. Here is what it says: - 3.6.4. Setting up an installation server If you don't have a connection to the Internet (either directly or via a web proxy) you need to create a local installation server that can be accessed from your S/390. This server keeps all the packages you want to install and must make them available using NFS, HTTP or FTP. The installation server needs to copy the exact directory structure from any Debian GNU/Linux mirror, but only the s390 and architecture-independent files are required. You can also copy the contents of all installation CDs into such a directory tree. - As I said in my previous post, I have no experience installing Debian from a private mirror. I have never used a private mirror because I have never needed to use a private mirror. At my installation, the virtual Linux servers on z/VM have access to the external internet. Therefore, I can use a public mirror for installation. Therefore, I do. If due to your installation policy the virtual Linux servers are not allowed to access a public mirror then you must create a private mirror and install from that. Instructions for creating a private mirror can be found here: http://www.debian.org/mirrors/ftpmirror If you need help creating a private mirror, ask for help on the debian-mirrors mailing list (debian-mirr...@lists.debian.org). -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/273996600.388799.1285853849788.javamail.r...@md01.wow.synacor.com
Re: IBM z/VM + z/Series + Debian
r. (5) If you still have trouble, then you probably don't have your FTP server set up properly. It must look like a Debian mirror to the Debian installer. I'm afraid I can't be of much help here, since I've never set up my own internal Debian mirror. I have always used an external public Debian mirror to do my installs. Perhaps you could set up a Debian mirror from a PC that has access to the external internet, then once you have it working, move it to another LAN segment to which the mainframe has access. (Of course, if it can't access the external internet from its new location, it can't sync up with the official mirrors once you move it.) Perhaps this link will get you started with creating your internal Debian mirror: http://www.debian.org/mirrors/ftpmirror If you need help setting up your internal mirror or getting it to work, ask for help on the debian-mirrors mailing list. You can limit your mirror to the "s390" and "all" HTH -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1388766870.216171.1285252690933.javamail.r...@md01.wow.synacor.com
Re: IBM z/VM 6.1 + z/Series + Debian
On Wed, 22 Sep 2010 01:01:23 -0400 (EDT), anandhcoe wrote: > > Hi Stephen, > http://old.nabble.com/file/p29776158/Nabble_Forum.doc Nabble_Forum.doc > As discussed i have attached the problem in accessing the > debian mirror. Pls do have a look on that and give ur valuable thoughts. > Thanks in advance Apparently you are not subscribed to debian-s390, nor do you read the list, because I addressed that in the following post: http://lists.debian.org/debian-s390/2010/09/msg00016.html Please read this post, all the way to the end. Policy with Debian mailing lists is to reply to the list only and not to CC the OP unless explicitly requested. But in this case I will CC you since you apparently did not get my previous reply. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2041521141.180675.1285160614936.javamail.r...@md01.wow.synacor.com
Re: Re: Installation of Debian under z/VM 530
On Thu, 16 Sep 2010 14:47:33 -0400 (EDT), Alain Benvéniste wrote: > > Thanks to give me some light ! > > OK. I want to install a free Linux to learn by myself the basics to follow > the market... > I will never have a Linux from my employee. I assume you meant to say "employer" instead of "employee". > So I have to follow my idea > without any help from him. > So YES, I can¹t access the WEB in extranet point of view. I can¹t even use > HTTP in intranet for security reasons. That does put you at a disadvantage. > It explains my approach to ask if it is possible to use my VM first level as > a FTP server to install Debian. In theory, it seems like it should be possible. Your VM system's FTP server should be able to serve up the files. The two main requirements are (1) Getting the files onto the FTP server in the first place, which could be tricky since you can't access the internet. (2) Making sure that your FTP server supports anonymous FTP. By default, a VM FTP server does not support anonymous FTP, but the Debian installer uses anonymous FTP. I've never done anything like this; so you're on your own. What worries me the most is the preservation of the Rock Ridge extensions. You will probably need to use a BFS server to store the data. Files on CMS minidisks or in SFS servers aren't going to cut it. The installation manual does not provide much information on this topic. Here's what it says. - 3.6.4. Setting up an installation server If you don't have a connection to the Internet (either directly or via a web proxy) you need to create a local installation server that can be accessed from your S/390. This server keeps all the packages you want to install and must make them available using NFS, HTTP or FTP. The installation server needs to copy the exact directory structure from any Debian GNU/Linux mirror, but only the s390 and architecture-independent files are required. You can also copy the contents of all installation CDs into such a directory tree. - Basically, you would be setting up an internal Debian mirror, except that there is no provision to sync up when the external mirrors change. And of course there will be no security or volatile updates, nor any updates of testing or sid, nor stable point release updates. I am fortunate enough to be at an installation where connectivity to the external internet is available to my VM system; so I never had to deal with your situation. I'm afraid I have no experience in that particular aspect of your installation problem. Good luck. Please report back if you are successful, with details of what you did and how you did it, and a list of pitfalls to avoid. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/429461488.37321.1284665962356.javamail.r...@md01.wow.synacor.com
Re: IBM z/VM 6.1 + z/Series + Debian
On Thu, 16 Sep 2010 02:35:50 -0400 (EDT), anandhcoe wrote: > > Thanks for your valuable thoughts... I have nearly followed all your > steps in installing Debian Linux on Z/VM.. > > In my case, I am using FTP as the method to access the installation media. > The problem is I am unable to specify the Username/Password to access our > FTP server. It sounds to me like what you have done is create some kind of "in-house" FTP server. Again, how are you going to get security and volatile updates if you don't have access to the internet? But ignoring that problem for the moment, what the Debian installer wants to connect to is a *Debian mirror*. A list of public Debian mirrors is available here: http://www.debian.org/mirrors/list You can choose any of those which support the FTP protocol and the s390 architecture, provided you enter the correct domain name and directory path, and provided that you entered the IP address of a DNS server during network configuration that can resolve the name. (If that's the issue, take a look at the TCPIP DATA file on your VM system and look at the NSINTERADDR statement(s) for the IP address(es) of DNS server(s).) It is possible to create an in-house Debian mirror and point the installer to that, but it doesn't sound like that's what you've done. > I have attached screenshots of what I have done so far. > Kindly help proceed > further. I don't have any software installed that can process .odt files. How about plain text? (In PuTTY, you can copy the current screen to the clipboard as follows: (1) click on the "icon button" in the upper left-hand corner of the title bar. From the drop-down menu, click on "Clear Scrollback", then repeat the process, clicking on "Copy All to Clipboard" this time. The resulting text can then be pasted in an e-mail.) Here's an example from my PuTTY session: - login as: steve st...@10.14.80.48's password: Linux debian3 2.6.32-5-s390x #1 SMP Wed Aug 25 13:56:36 UTC 2010 s390x The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. You have new mail. Last login: Wed Sep 15 10:42:06 2010 from 10.14.91.79 st...@debian3:~$ - The above was extracted from PuTTY via the method described. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/104733069.25464.1284645808599.javamail.r...@md01.wow.synacor.com
Re: Installation of Debian under z/VM 530
I took the liberty of correcting your typos, including those in the subject line. On Wed, 15 Sep 2010 12:42:47 -0400 (EDT), Alain Benveniste wrote: > > I'm not allowed to install Debian from the Net. I'm not sure what that means. Does that mean that you are not allowed to use the http protocol, or does that mean that your VM system has no access to the Internet at all? > So I chose the > hidden FTP method, only viewable when we choose the low option > through Installer. I assume that you are referring to debconf/priority=low as an option in PARMFILE DEBIAN. That implies that your VM system *does* have access to the internet, or you couldn't use FTP. > Now that I have my ISO file, I have no idea > if this file has to be on a CMS mdisk, an SFS or a BFS? When installing in a virtual machine under z/VM, you shouldn't need an ISO file. But let's back up a minute. Most Debian mirrors do support the FTP protocol, as well as the HTTP protocol. But to the best of my knowledge, the security server and the volatile server only support the HTTP protocol. If you aren't allowed to use HTTP, you won't be able to pick up security or volatile updates. That would not be a good thing for security. If HTTP is truly forbidden, ask your management to reconsider. Preventing security updates harms everyone. Perhaps the real rule is that all HTTP access must go through an HTTP proxy. That is not a problem. The Debian installer provides a way to specify a proxy. And if you don't specify it during installation, you can manually configure apt after installation to start using a proxy. On the s390 platform, an ISO file is normally used to burn a CD, which can be used to install Linux directly into an LPAR. But you don't want to run Linux in an LPAR, you want to run it in a virtual machine under z/VM. CDs, or the .iso images from which they are created, are not normally needed or used for installing in a virtual machine under z/VM. > If the > installer is waiting for a CMS iso file, how [does] it resolve the > concatenated subdirectries it adds? And there is no way to > overlay what the wget does, because extra directories are added > to what is entered in the screen installer. I think you're confused. I know I am! I don't know what you're talking about. You might want to read a post that I made to another thread which gives some more detail about the typical installation procedure in a virtual machine under z/VM: http://lists.debian.org/debian-s390/2010/09/msg00013.html > Looking too into the > /var/log/syslog we can see that the default for the defaultnet > is 255.255.252.0 not 255.255.255.0. The installation of the s390 port of Debian GNU/Linux in a virtual machine under z/VM requires that the virtual machine be configured using static addressing. The use of DHCP is not allowed under these circumstances. Thus, it is your responsibility to configure the network correctly. If you aren't sure what to use for the various configuration values, ask your network administrator for assistance. > > I would like to know too what we can code into the parmfile. > I didn't fnd any doc related to this ? > > If anyone can bring some light ? That's would be fine :) That is documented in the installation guide. (I am assuming that you want to install Squeeze.) http://d-i.alioth.debian.org/manual/en.s390/index.html See section 5.2, boot parameters. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1953760948.6223.1284578220893.javamail.r...@md01.wow.synacor.com
Re: IBM z/VM 6.1 + z/Series + Debian
need some work. By virtue of being downloaded under the "ascii"
protocol, as shown above, a translation was made between ASCII
and EBCDIC during download. But the files are not in the final
format that they need to be in.
PIPE < DEBIAN EXEC A|JOIN *|SPLIT AT X25|> DEBIAN1 EXEC A
ERASE DEBIAN EXEC A
RENAME DEBIAN1 EXEC A DEBIAN = =
This sequence of commands will create a "DEBIAN EXEC A" file
in the proper format for execution as an "EXEC" (script) under CMS.
Note that X25 (X'25') is the EBCDIC code for a line-feed character, which
is X'0A' in ASCII, but we must use X25 since the data has already
been translated to EBCDIC.
Now we need to work on the "PARMFILE DEBIAN A" file. Edit the
file with the System Product Editor (XEDIT).
XEDIT PARMFILE DEBIAN A
Assuming that you have
SET NONDISP "
in effect, which is the default, the file should look like this:
ro locale=C"
The quotation mark (") at the end of the line represents the
line-feed character (X'25'). This character is not displayable,
so XEDIT substitutes the quotation mark in its place. It is
NOT a literal quotation mark. The first thing we need to do is to issue
some commands on the command line to preserve the data in the file
from unwanted translations:
SET CASE MIXED RESPECT
SET IMAGE OFF
SET NULLS ON
I recommend running the installer in expert mode;
so issue the following commands:
:1
CHANGE :locale=C:locale=C debconf/priority=low:
Notice that we had to use a non-standard delimiter, the colon in this
case, since the new text contains a forward slash.
Now, before filing the data, make sure that the trailing line-feed
character, X'25', is still there and has not been overlaid by issuing
SET VERIFY OFF H 1 *
This will cause the editor to display the file in hexadecimal. The
last two digits displayed (except for trailing blanks, whose code in
EBCDIC is 40) should be 25. The trailing blanks will be stripped off
when the FILE command is issued.
FILE
Now, convert the file into the proper format for use by Linux:
PIPE < PARMFILE DEBIAN A|XLATE E2A|FBLOCK 80 00|> PARMFILE DEBIAN1 A F
ERASE PARMFILE DEBIAN A
RENAME PARMFILE DEBIAN1 A = DEBIAN =
This converts the file from EBCDIC back to ASCII and pads it with nulls
as needed to make it a fixed-length, 80-byte file.
Now check your virtual reader to make sure that there are no reader files
that you want to save. The DEBIAN EXEC file that you are about to
run will purge all files from your virtual reader.
RDRLIST
When you are ready to begin the install, type
DEBIAN
at a CMS "Ready;" prompt. This will spool your virtual punch to your
virtual reader, punch the kernel, parmfile, and initrd images (which get
transferred to the virtual reader), then IPL from the virtual reader.
No CD is required! CDs are used when installing Linux in an LPAR,
but when installing in a virtual machine under z/VM they are not needed.
Perform the first few installation steps in order using the 3215 virtual
console. These steps are as follows:
1. Configure the network device
2. Configure a network using static addressing
3. Continue installation remotely using SSH
Once these steps are done, you must use a remote ssh client to connect
to the virtual server, login to the installation id, and continue the
installation from the network console. I use PuTTY as my remote ssh client
from my Windows workstation. PuTTY is free software and is
available from
http://www.chiark.greenend.org.uk/~sgtatham/putty/
When you configure your PuTTY session, be sure to use the UTF-8 character
set (under Window -> Translation) or the graphics characters used by the
installer will look horrible. Once I get Debian installed, I usually
change the locale to en_us via
dpkg-reconfigure locales
shutdown and reboot, then change my PuTTY session to ISO-8859-1.
You may also want to visit my web site at
http://www.wowway.com/~zlinuxman/index.htm
I have a number of things on that site that may be useful to you, such
as how to implement the dasd diag driver, which I recommend for anyone
running Debian in a virtual machine under z/VM. For more detailed installation
instructions, see the Installation Guide at
http://d-i.alioth.debian.org/manual/en.s390/index.html
This should get you started.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1374346702.4058.1284573981566.javamail.r...@md01.wow.synacor.com
Re: IBM z/VM 6.1 + z/Series + Debian
On Tue, 14 Sep 2010 06:48:39 -0400 (EDT), anandhcoe wrote: > > I am trying to install Debian Linux on Z/VM. Could you pls help me in > this.. It would bve very helpful I'll try. What problem are you having? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1910116579.98150.1284468605046.javamail.r...@md01.wow.synacor.com
Re: Access to s390 porter machine
On Sat, 11 Sep 2010 06:33:42 -0400 (EDT), Matthijs Kooijman wrote: > Stephen Powell wrote: >> Matthijs Kooijman wrote: >>> Never mind, we've managed to test this in an emulator already. >> Sorry for the slow response. > > No problem, I know how it is. I didn't mean to sound bitter, just wanted > to prevent double work :-) Understood. And thank you. By the way, I am just an ordinary user of Debian for s390. I am not a member of the s390 port team or the installer team and do not speak for either of them. Bastian and his teammates are busier than a one-armed wallpaper hanger in the spring right now, trying to get Squeeze out the door; so if I can help people out on the list, I try to do that. If I make any inaccurate statements, I trust that Bastian or someone else will correct me. > In the meanwhile, the packages concerned have all been succesfully > rebuilt with some endian-ness changes, so everything is ok again :-) I'm glad you have things working now. As you discovered, s390 is a "big-endian" architecture, as compared, for example, with i386, which is a "little-endian" architecture. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/961632354.29144.1284215699135.javamail.r...@md01.wow.synacor.com
Re: Access to s390 porter machine
On Fri, 10 Sep 2010 14:17:50 -0400 (EDT), Matthijs Kooijman wrote: > On Wed, 8 Sep 2010 00:10:19 +0200, Matthijs Kooijman wrote: >> I'm a Debian Maintainer who is having some problems with a package >> (grfcode) on s390. Can you get me access to a porter box so I can try to >> fix the problems? > Never mind, we've managed to test this in an emulator already. Sorry for the slow response. Frans Pop, one of the s390 porters, and the one who monitored this list most closely, died recently. (See http://www.debian.org/News/2010/20100831.) It will no doubt take the Debian s390 port some time to recover from his loss. Since Debian is an all-volunteer organization, and since we have no corporate sponsorship from IBM for system z, IBM System z servers are hard to come by for the Debian project. (Not too many private individuals have a 64-bit mainframe in their basements.) Frans himself used the Hercules emulator running under Linux on an Intel box, I believe, to do his work, and I suspect (but do not know for certain) that the production build servers do as well. Frans was doing the daily builds of the squeeze Debian installer for the s390 platform himself, the last I knew. I just tried the link myself: http://people.debian.org/~fjp/d-i/s390/images/daily/ and got a "404 - not found" error; so we have no more daily builds. That issue needs to be addressed. I have access to a real IBM mainframe owned by my employer, and I can sometimes test things for Debian, if it is in my employer's interests to do so; but I am not in a position to offer a "porter box" to Debian. It doesn't belong to me. I run Debian for s390 in a virtual machine under z/VM; so if there's anything VM-specific that needs tested, I might be able to help. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/665488487.14230.1284144761467.javamail.r...@md01.wow.synacor.com
