Re: Sparc release requalification
On Thu, Aug 20, 2009 at 10:45:46AM +0200, Bastian Blank wrote: On Thu, Aug 20, 2009 at 07:09:44AM +0200, Mike Hommey wrote: On Wed, Aug 19, 2009 at 04:33:32PM +0200, Bastian Blank wrote: If I understand this correctly, this would need the modification off all library packages to implement biarch semantic. ... which will be needed anyways. So your choice is actually between doing it and doing it plus some extra intermediate work. No, we don't need to do that. Thats what is multiarch for. It's not intended that multiarch supports switching architectures. Of course it would help to import some 64bit packages selectively from a sparc64 port but most of your binaries would still be 32bit with the only partially supported code generation? Even on a rebuild you would have to pull in the 64bit libs in a way you build against them by default? (Or would that boil down to passing another DEB_*_ARCH so that config.guess targets 64bit and stuffing that into simple packages with arch:sparc?) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Differences between zelenka and zandonai
On Sun, Oct 31, 2010 at 10:51:36AM +0100, Mike Hommey wrote: During the build, this is what happens: INFO | negative control allocated at 0x40028000 INFO | positive control allocated at 0x4002a000 INFO | poison area assumed at 0xf0dea000 (preferred addr) TEST-PASS | reading negative control TEST-PASS | executing negative control TEST-PASS | writing negative control TEST-PASS | reading positive control | Segmentation fault TEST-PASS | executing positive control | Segmentation fault TEST-PASS | writing positive control | Segmentation fault TEST-UNEXPECTED-FAIL | reading poison area TEST-PASS | executing poison area | Illegal instruction TEST-UNEXPECTED-FAIL | writing poison area It's interesting to see the addresses used for negative and positive control are significantly different, while running the program on zelenka and zandonai by hand give an address in 0x77xx. Could that be related to personality ? schroot should yield the same personality as for the buildd, given that the same chroot definition is used. Kind regards, Philipp Kern signature.asc Description: Digital signature
Re: DSO linking changes for wheezy
On Mon, Nov 15, 2010 at 11:02:57PM +0100, Matthias Klose wrote: maybe, and fix it in N - ~100 packages? Or fix the ~100 packages? The point of injection is for discussion. I would prefer having this set in dpkg-buildflags, and then disabled by these ~100 packages. Note that this is probably the same like modifying the N - ~100 packages, as almost no package respects dpkg-buildflags yet. Did you actually do a build test? Kind regards Philipp Kern signature.asc Description: Digital signature
s390-netdevice: my_debconf_input
Hi,
I discovered the following function in s390-netdevice/netdevice.c:
| static int my_debconf_input (const char *priority, const char *template, char
**p)
| {
| int ret;
|
| debconf_fset(client, template, seen, false);
| debconf_input(client, priority, template);
| ret = debconf_go(client);
| debconf_get(client, template);
| *p = client-value;
| return ret;
| }
This seems to prevent preseeding of s390 netdevice settings. Is the
debconf_fset of the seen variable useful here or can it just be dropped?
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Re: valgrind port to system Z
On Wed, Feb 02, 2011 at 12:32:21PM -0500, Florian Krohm wrote: I've been working on the valgrind port to system Z for some time and an initial patch set has been posted here: http://bugs.kde.org/243404 The port is fairly functional already and is currently awaiting review. What's left to be done is performance enhancements and adding support for tools beyond memcheck and massif. I'd like to continue working on the port but I no longer have access to a system Z machine. I've tried the hercules emulator but a valgrind build takes several hours to complete on my hardware, never mind running regression buckets. So, unfortunately, it's not really workable. Is there a possibility that the Debian project could provide access to a mainframe machine? In theory that could be possible. The porterbox in question is listed as public. [0] requires a DD signing off the request, though. Kind regards Philipp Kern [0] http://dsa.debian.org/doc/guest-account/ signature.asc Description: Digital signature
Re: Debian 6 - qdio Device
On Wed, Feb 16, 2011 at 04:45:04PM +0100, Riedel, Alexander 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 ? What does `ls -R /etc/sysconfig' show? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Debian 6 - qdio Device
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? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: s390 weekly builds are failing, unable to download d-i
On 2011-04-25, Steve McIntyre st...@einval.com wrote: Subject: testingcds Bsids390 has failed; log included [...] (Optionally) making the image bootable for s390: Running tools/boot/sid/boot-s390 1 /org/cdbuilder.debian.org/src/deb-cd/tmp/Bsids390/wheezy/CD1 --2011-04-25 08:59:55-- https://lophos.multibuild.org/d-i/images/daily/generic/parmfile.debian Resolving lophos.multibuild.org... 195.243.109.163 Connecting to lophos.multibuild.org|195.243.109.163|:443... failed: No route to host. FAILED: error 4 Failed to start disc 1, error 1024 make: *** [image-trees] Error 9 Shouldn't that just download from [0]? Kind regards Philipp Kern [0] http://d-i.debian.org/daily-images/s390/daily/generic/ -- 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/slrnirb2el.6tq.tr...@kelgar.0x539.de
Re: [Linux/390 under z/VM 4.2.0] CP works forever (Lenny)
On Fri, Apr 29, 2011 at 10:36:34AM +0700, Christian Boitet wrote: 12 *-* 'CP IPL 000C CLEAR' CP IPL 000C CLEAR 003 FILES CHANGED It seems 100% OK, but then it hangs. We checked of messages from CP (it supports VINPUT) to the Support Element (SE), no messages. For completeness: how did you transfer the files to CMS? Kind regards, Philipp Kern signature.asc Description: Digital signature
Re: [Linux/390 under z/VM 4.2.0] CP works forever (Lenny): details
On Sat, Apr 30, 2011 at 02:39:15PM +0700, Christian Boitet wrote: Actually, as ftp on this VM did not work, we did the operation on another VM and copied (using COPYFILE) the 4 files obtained to the VM (LINUX7 in our installation) on which we want to install Debian/Lenny, and on which we did the necessary transformation of DEBIAN EXEC and PARMFILE DEBIAN. Where did you get the files from? Double-checking as you didn't state it and Stephen's talking about newer locations with s390x-only kernels. FWIW the current dailys are at [0] but this won't help you because they're s390x-only. We followed exactly the instructions indicated in the Debian installation documentation. I copy them below, with a few comments. We had to convert the PARMFILE DEBIAN back from ebcdic into ascii F 80, I did it under Xedit and checked the correctness by visulizing the Hex form, it was OK, including for the EOL character (X'2A'). As far as I know Linux can cope with the PARMFILE being in EBCDIC. I had no trouble editing the preseed information in it verbatim in XEDIT, at least. 5.1.2 on [1] confirms this. Kind regards, Philipp Kern [0] http://d-i.debian.org/daily-images/s390/daily/ [1] http://www.debian.org/releases/stable/s390/ch05s01.html.en -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: [Linux/390 under z/VM 4.2.0] CP works forever (Lenny): details
On Sat, Apr 30, 2011 at 02:39:15PM +0700, Christian Boitet wrote: by ftp, in binary F 80 format for KERNEL DEBIAN and INITRD DEBIAN, and in ascii for PARMFILE DEBIAN and DEBIAN EXEC. Actually, as ftp on this VM did not work, we did the operation on another VM and copied (using COPYFILE) the 4 files obtained to the VM (LINUX7 in our installation) on which we want to install Debian/Lenny, and on which we did the necessary transformation of DEBIAN EXEC and PARMFILE DEBIAN. I get different record counts for my successful 31-bit boot (on VM 6.1, though): 00: 003 FILES PURGED 00: RDR FILE 0028 SENT FROM PRKTLIN0 PUN WAS 0028 RECS 042K CPY 001 A NOHOLD NO KEEP 00: RDR FILE 0029 SENT FROM PRKTLIN0 PUN WAS 0029 RECS 0001 CPY 001 A NOHOLD NO KEEP 00: RDR FILE 0030 SENT FROM PRKTLIN0 PUN WAS 0030 RECS 035K CPY 001 A NOHOLD NO KEEP 00: 003 FILES CHANGED 00: 003 FILES CHANGED FILELIST says this: Cmd Filename Filetype Fm Format LreclRecords Blocks Date Time KERNEL DEBLENNY A1 F 80 42020798 2011-04-30 16:25:13 INITRD DEBLENNY A1 F 80 34861681 2011-04-30 16:25:06 DEBLENNY EXEC A1 V 40 11 1 2011-04-30 16:23:51 PARMFILE DEBLENNY A1 V 11 1 1 2011-04-30 16:22:42 I still sense corruption there. I.e. are lrecl, records and blocks the same for you? Given that I just fetched a Lenny image from current it ought to be identical. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: [Linux/390 under z/VM 4.2.0] CP works forever (Lenny): details
On Sat, Apr 30, 2011 at 11:23:16PM +0700, Christian Boitet wrote: I am not sure he got DEBLENNY filetypes the last time he tried, hence there may be a problem already there. Nah. As filetypes don't mean anything to me I took the liberty to rename the files to not collide with the ones already present on the CMS disk. What's important are the lengths. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Debian Version for System Z
On Thu, May 12, 2011 at 11:41:35AM -0300, 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 ? There are basic s390x support libraries in the archive (libc6-s390x, some lib64* libraries). With those I'm able to run IBM Java 64bit just fine on Debian. If the ISV applications are not linked statically to all the libs Debian does not provide, then they won't work. I'd assume that most are, though. You can check it by running ldd against the binary application. For IBM Java I get this: pkern@i43z10deblin0:/opt/ibm-java-s390x-60/bin$ ldd ./java libpthread.so.0 = /lib64/libpthread.so.0 (0x0201) libjli.so = /opt/ibm-java-s390x-60/bin/./../jre/lib/s390x/jli/libjli.so (0x0202f000) libdl.so.2 = /lib64/libdl.so.2 (0x0203a000) libc.so.6 = /lib64/libc.so.6 (0x0203f000) /lib64/ld64.so.1 = /lib/ld64.so.1 (0x02aaa000) You'll get a not found in place of a library in there if you miss one. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Debian Version for System Z
Stephen, am Thu, May 12, 2011 at 09:53:39PM -0400 hast du folgendes geschrieben: 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. ;-) 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. If something needs fixing please tell us. (That said: non-proprietary software is more fun, too.) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: gdm3 on s390
Hi, On Tue, Mar 22, 2011 at 04:22:53PM +0100, 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) please file a proper bug report against the package. You should still be able to get an X server through vncserver. Normally gdm/kdm are used with XDMCP to provide remote desktops, so the combination with vnc seems strange to me. If that isn't possible anymore, I'd say it's a bug. If you just want a graphical environment, use vncserver. (Also vncviewer's -via option is pretty helpful to connect via SSH.) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: preprocessor symbol to distinguish s390, s390x?
Hi, On Tue, Aug 30, 2011 at 08:52:01PM -0500, Steve M. Robbins wrote: I just uploaded a fixed version of gmp that builds on s390x. However, I realized that both s390 and s390x use the same include file, gmp-s390.h. In order to avoid this clash (see /usr/include/gmp.h), I need a C preprocessor symbol that s390x defines but s390 does not. Perhaps __s390x__ ? yep. __s390__ is defined on both of them, __s390x__ is only defined on s390x. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: s390-tools_1.13.0-1_s390.changes ACCEPTED into unstable
Hi, On Thu, Oct 06, 2011 at 09:36:05PM +, Debian FTP Masters wrote: Accepted: s390-tools-udeb_1.13.0-1_s390.udeb to main/s/s390-tools/s390-tools-udeb_1.13.0-1_s390.udeb s390-tools_1.13.0-1.debian.tar.gz to main/s/s390-tools/s390-tools_1.13.0-1.debian.tar.gz s390-tools_1.13.0-1.dsc to main/s/s390-tools/s390-tools_1.13.0-1.dsc s390-tools_1.13.0-1_s390.deb to main/s/s390-tools/s390-tools_1.13.0-1_s390.deb s390-tools_1.13.0.orig.tar.bz2 to main/s/s390-tools/s390-tools_1.13.0.orig.tar.bz2 I would be grateful if people could test this. It did boot with the updated zipl on my sid machine, but more testers certainly won't hurt. I attached the relevant IBM changelog. However, please note that this initial release does not add any new utilities over the ones shipped with Squeeze. I'll try to activate more when this build migrated to testing. (And hopefully some feedback told me that it isn't broken.) Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Bug#645836: Missing build dependency on libfuse-dev
severity 645836 serious thanks On Tue, Oct 18, 2011 at 07:58:42PM -0400, Stephen Powell wrote: 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. Thanks for the report. I'll fix it in due course. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: New Install
Hi, On Thu, Nov 24, 2011 at 04:18:07PM -0200, João Henrique Viana wrote: It's a pleasure announce a successful installation of a Debian GNU/Linux Squeeze 6.0.3 on a LPAR of a Mainframe IBM z10. Thats nice!!! Linux linux02 2.6.32-5-s390x #1 SMP Thu Nov 3 04:24:39 UTC 2011 s390x GNU/Linux thanks for the feedback. Out of curiosity: how did you boot up the installer? Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: New Install
Hi João, On Fri, Nov 25, 2011 at 10:21:04AM -0200, João Henrique Viana wrote: I burned the CD #1 with the file d390.ins copied from /boot to / with the correct paths to the directory /boot and boot up the image via the HMC. thanks. Indeed that works. The next CD re-spin should contain a suitable d390.ins. Cheers, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: New user help
On Thu, Dec 22, 2011 at 07:38:14AM -0500, Martin, Larry D wrote: I am doing an install on an IBM Z9 LPAR of 6.0.3. The install was going smoothly until I got to Configure direct access storage device. I supplied an address and was ask if I wanted to format it; I said yes and when it finished it went back to the previous screen. It just keeps alternating these screens. In another session if I do # cat /proc/dasd/devices I get: 0.0.2249(ECKD) at ( 94: 0) is dasda : active at blocksize: 4096, 1803060 blocks, 7043 MB 0.0.224a(ECKD) at ( 94: 4) is dasdb : active at blocksize: 4096, 1803060 blocks, 7043 MB Could you provide us with a dump of /var/log/syslog, please? Thanks Philipp Kern signature.asc Description: Digital signature
Re: use Hercules to emulate our build host?
Hi, On Tue, Dec 27, 2011 at 02:14:35PM -0500, Yaroslav Halchenko wrote: I see that hercules has lots of logic around DFP but I am not clear which hercules's model compatible with our kernel (e.g. it doesn't boot on ESA/370) would provide DFP? what did you try as ARCHMODE? S/370 is wrong, ESA/390 might or might not boot Linux, z/Arch is what you want to use. That said I don't have any experience wrt DFP emulation within Hercules. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Trying to install SQUEEZE
On Thu, Feb 02, 2012 at 09:35:17AM -0500, Martin, Larry D wrote: I attempted to ask this question on 6.0.3 but never got a resolution. Someone suggested it was because there were too many devices available. And I asked you to provide /var/log/syslog. The command in question would be cat, but I currently don't have the time to walk someone through Linux basics, I'm afraid. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: tips for understanding systemtap build failure?
Hi, On Sat, Feb 11, 2012 at 03:19:33PM +0200, Timo Juhani Lindfors wrote: Philipp Kern pk...@debian.org writes: Done (chroot: sid_s390x). Thanks, you can remove the build-dependencies now. Btw, would you like us to add s390x to the architecture list for systemtap? Currently it only lists s390. If you do, I'd appreciate if you could run the testsuite on some s390x machine: it needs root privileges so I can't do it on a porterbox. sure, if you tell me what to run. make install didn't work with the pristine source. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: tips for understanding systemtap build failure?
On Tue, Feb 21, 2012 at 11:43:36PM +0200, Timo Juhani Lindfors wrote:
Philipp Kern pk...@debian.org writes:
sure, if you tell me what to run. make install didn't work with the
pristine source.
I test the debian packages with
apt-get source systemtap
cd systemtap-*
touch -d @0 stap
./configure --prefix=/usr
sudo make installcheck
This assumes that systemtap has already been installed so you'd need to
add s390x to debian/control, build the package and then install it
before running the above commands.
Same failure as before:
(sid-s390x)pkern@pkernl0:~/systemtap-1.6$ sudo make installcheck
if test \! -e /usr/bin/stap; then \
echo /usr/bin/stap doesn\'t exist, run make install; \
exit -1; \
fi; \
if test ./stap -nt /usr/bin/stap; then \
echo /usr/bin/stap is not recent, run make install; \
exit -1; \
fi;
make -C testsuite installcheck RUNTESTFLAGS=
make[1]: Entering directory `/home/pkern/systemtap-1.6/testsuite'
Making a new site.exp file...
rmmod uprobes 2/dev/null
make[1]: [installcheck] Error 1 (ignored)
make check-DEJAGNU RUNTESTFLAGS= --tool_opts \'install \'
make[2]: Entering directory `/home/pkern/systemtap-1.6/testsuite'
srcdir=`CDPATH=${ZSH_VERSION+.}: cd . pwd`; export srcdir; \
EXPECT=expect; export EXPECT; \
runtest=env LANG=C SYSTEMTAP_TESTREMOTES= SYSTEMTAP_TESTAPPS=
SYSTEMTAP_RUNTIME=/usr/share/systemtap/runtime
SYSTEMTAP_TAPSET=/usr/share/systemtap/tapset LD_LIBRARY_PATH=/usr/lib/systemtap
CRASH_LIBDIR=/usr/lib/systemtap PATH=/usr/bin:$PATH SYSTEMTAP_PATH=/usr/bin
SYSTEMTAP_INCLUDES=/usr/include PKGLIBDIR=/usr/libexec/systemtap ./execrc
runtest; \
if /bin/bash -c $runtest --version /dev/null 21; then \
exit_status=0; l='systemtap'; for tool in $l; do \
if $runtest --tool $tool --tool_opts \'\' --srcdir $srcdir
--tool_opts \'install \'; \
then :; else exit_status=1; fi; \
done; \
else echo WARNING: could not find \`runtest' 12; :;\
fi; \
exit $exit_status
./execrc: 1: eval: runtest: not found
make[2]: Leaving directory `/home/pkern/systemtap-1.6/testsuite'
if test -n ; then mail systemtap.sum; fi
make[1]: Leaving directory `/home/pkern/systemtap-1.6/testsuite'
Kind regards
Philipp Kern
signature.asc
Description: Digital signature
Re: tips for understanding systemtap build failure?
Timo, am Wed, Feb 22, 2012 at 07:33:02AM +0200 hast du folgendes geschrieben: Philipp Kern pk...@debian.org writes: ./execrc: 1: eval: runtest: not found Installing the dejagnu package should fix this. then it fails with this: Checking /lib/modules/2.6.32-5-s390x/build/.config failed with error: No such file or directory I did install the linux-image package from the s390 host within the chroot with --force-architecture, but that doesn't give me its .config in the right place. Should it be enough to place the .config there or does it need to be a full kernel build tree? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: tips for understanding systemtap build failure?
Timo, am Wed, Feb 22, 2012 at 09:58:59AM +0200 hast du folgendes geschrieben: that should give you a list of packages that you need. Upstream has integrated similar functionality for redhat/fedora but I don't think my proof-of-concept is ready for upstream inclusion yet. My guess is that you need: linux-image-2.6.32-5-s390x linux-image-2.6.32-5-s390x-dbg linux-headers-2.6.32-5-s390x linux-kbuild-2.6.32 that's annoying given that the -dbg flavour doesn't seem to exist. Neither on s390/squeeze nor s390x/sid. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: Fwd: Bug#659294: [libarchive-discuss] Fwd: Bug#659294: libarchive: FTBFS on various architectures (hurd, mipsel, s390, s390x)
On Wed, Feb 22, 2012 at 08:37:38PM -0500, Andres Mejia wrote: The issue is resolved for s390 but not for s390x. I see there's no porterbox available for s390x so I won't be able to help out much with the test suite failure in s390x. Chroot sid_s390x on zelenka. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#666399: s390-dasd fails to work with 20 devices visible (mostly in LPAR mode)
Package: s390-dasd
Version: 0.0.27
Severity: important
s390-dasd has the following code snippet in dasd-config.c:
| static enum state_wanted get_channel (void)
| {
| if (di_tree_size (channels) 20)
| return get_channel_input ();
| else if (di_tree_size (channels) 0)
| return get_channel_select ();
| return WANT_ERROR;
| }
I'm not sure about the rationale for this. When removing the check, the
program segfaults upon hitting Finish, despite listing the devices
correctly and allowing to configure them. Sadly strace didn't help at all
and gdb was unable to generate traces.
If you've got a lot of devices visible, because you're in LPAR mode, you
cannot configure the disks because the state machine goes GET_CHANNEL -
ENABLE - FORMAT - WRITE - GET_CHANNEL and there's no way to exit the
GET_CHANNEL input field with a finished state. So you're caught in an
endless loop instead. An alternative to just showing the select widget all
the time would be to fix the state machine so that it's possible to exit with
sucess from the channel input when at least one device was brought online (or
is in configured).
Kind regards
Philipp Kern
--
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/20120330125258.15203.95839.report...@spike.0x539.de
Bug#666879: s390(x): please add a netboot image
Package: debian-cd Severity: normal You can boot CDs on s390, which is why we generate ISOs. However, nobody implemented to actually pull the debs from the disc. Instead booting CD1 is basically equivalent to booting a netboot image. You can, of course, copy the debs onto some FTP and then install from there. Hence it would be useful to provide a real netboot image that only contains the usual documentation, the d390.ins and the boot subdir of a normal CD images, but no further debs. Please note (for someone's reference) that copying the .ins and boot from the CD to a FTP server does not seem to work when trying to boot in LPAR mode. CD booting does work with current squeeze images, however. -- 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/20120402060940.20903.96971.report...@spike.0x539.de
Re: Access to s390 porter machine
shahanawaz, on Thu, Apr 05, 2012 at 07:58:11AM + you and possibly Stephen wrote the following: take the Debian s390 port some time to recover from his loss. Since Debian is an all-volunteer organization, and sincete 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 e builds. That issue needs to be addressed. that's now available in the usual place[1] since quite a while. FWIW debian-s390@lists.debian.org is the right point to ask questions. 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. Well, we do have a porter box, but it does not allow for low-level installation testing. 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. There's a problem with DASD picking when seeing more than 20 devices in the LPAR. The trouble I had with OSAs was that too many were detected and hence you are unable to pick the right ones if they don't come first, because of the way the chooser works at that point. One way to workaround that would be to edit the IOCDS to hide the irrelevant devices (you can reenable them post-installation of course). Installation in z/VM with the device numbers that should be used in LPAR mode is usually the easiest way, but I understand that this is not available for those trying Debian directly in LPAR mode. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Squeeze install successful, now a NIC / OSA / eth0 problem
am Thu, Apr 12, 2012 at 08:24:34PM -0600 hast du folgendes geschrieben: Notice how eth0 gets renamed to eth5 ( this copied version gets incremented by 1 every time I IPL .. don't know why either ) Sadly that's a known problem with the udev rules. Just do this for the time being: touch /etc/udev/rules.d/75-persistent-net-generator.rules rm /etc/udev/rules.d/70-persistent-net.rules I'll try to put this back onto the agenda for wheezy. Kind regards Philipp Kern -- 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/20120413071914.gc11...@spike.0x539.de
Re: Squeeze failing during Select and Install Software
On Fri, Apr 13, 2012 at 06:12:26AM -0600, The VM Wizard wrote: Hi Mr. Kern. In .. the first place I tried using 4 regular 3390-3's, which have 3339 cylinders, one each for /, /home, /usr, and /var, plus a 3390-1 ( 1113 cylinders ) for a SWAP disk. And as I found, that wasn't enough if one chose everything from the Select and Install Software step of the install process. On the other hand maybe a full desktop environment isn't that useful on a s390 if you don't setup a terminal server. Packages are easily installed after the installation with aptitude and apt-get. But yeah, a 3390-3 is sufficient for a bare install. A realistic server installation needs about 3G. So a -9 is usually sufficient. (Not necessarily for everything ticked on as above, though.) Kind regards Philipp Kern -- 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/20120413113708.ga14...@spike.0x539.de
Re: Using total storage tapes from Debian
Hi, On Sun, Apr 15, 2012 at 01:14:58AM +0400, Alex Popov wrote: The question is how to use IBM tapes from Debian (we have TS3500)? Is there any way to load/change and read/write cartridges from Debian? it's probably better to ask this on linux-...@vm.marist.edu. Kind regards, Philipp Kern -- .''`. Philipp KernDebian Developer : :' : http://philkern.de Stable Release Manager `. `' xmpp:p...@0x539.de Wanna-Build Admin `-finger pkern/k...@db.debian.org signature.asc Description: Digital signature
Re: wheezy installer images fail on hercules
On Sat, May 19, 2012 at 07:19:32PM +0200, Andreas Metzler wrote: FYI I just tried to install wheezy on hercules, using http://ftp.at.debian.org/debian/dists/wheezy/main/installer-s390/current/images/generic/* with http://www.josefsipek.net/docs/s390-linux/hercules-s390.html I got ERROR: No CTC or ESCON connections although devlist showed otherwise. Switching to http://ftp.at.debian.org/debian/dists/stable/main/installer-s390/current/images/generic/* (without any changes to my setup, I just switched images) worked. Indeed, thanks for the report. It seems that the kernel driver switched from cu3088 to ctcm (the driver name is hardcoded in s390-netdevice). Furthermore I only see «/sys/bus/ccw/devices/0.0.0a00», i.e. just one device instead of its write partner 0.0.0a01. The same issue has been fixed in sysconfig-hardware with #566632, but there both devices turned up. Stephen, Waldi, do you know of a corresponding upstream change apart from the driver renaming? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.
On Sun, May 20, 2012 at 10:37:00PM +0200, Bastian Blank wrote: On Sun, May 20, 2012 at 10:22:58PM +0200, Philipp Kern wrote: you cannot reinterpret a size_t as an int. size_t might be unsigned, might have another length, etc. On 64bit big endian you fill the top bits and leave the lower ones untouched, because size_t is 64bit. So yeah, that code was broken. (nbd had something similar, glib too. I don't know why it only turns up with 64bit big endian.) Because on little endian 64bit, it touches the lower bytes. Yeah, but that assumes that the other ones are 0? Or ok, maybe it's just working when going from size_t to int, because it's truncation, but it shouldn't work for the other way round? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: wheezy installer images fail on hercules
On Sun, May 20, 2012 at 12:37:44AM +0200, Philipp Kern wrote: Indeed, thanks for the report. It seems that the kernel driver switched from cu3088 to ctcm (the driver name is hardcoded in s390-netdevice). Furthermore I only see «/sys/bus/ccw/devices/0.0.0a00», i.e. just one device instead of its write partner 0.0.0a01. The same issue has been fixed in sysconfig-hardware with #566632, but there both devices turned up. This works for me (with the adjusted initrd): 0A00.2 CTCI 10.1.1.1 10.1.1.2 Does that also work for you, Andreas, with the squeeze kernel? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: s390 qualification for Wheezy
On Wed, May 23, 2012 at 07:35:29PM +0100, Adam D. Barratt wrote: On Wed, 2012-05-16 at 13:19 +0100, Adam D. Barratt wrote: With the sound of the ever approaching freeze ringing loudly in our ears, we're (somewhat belatedly) looking at finalising the list of release architectures for the Wheezy release. Comments on / additions and corrections to the content of http://release.debian.org/wheezy/arch_qualify.html would be appreciated, as would any other information you think is relevant to helping us determine s390's status for the release. *prod* just in case anyone did have any comments... Not really. For wheezy I don't see a problem releasing with s390. For wheezy+1 it might not make sense, due to upstreams dropping s390 support and the fact that few people use the 31bit toolchain. With three buildds we're pretty much redundant now, package building is generally very fast. OTOH this arch is already marked as yes anyway… ;-) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: wheezy installer images fail on hercules
On Sun, May 27, 2012 at 10:40:15AM +0200, Andreas Metzler wrote: On 2012-05-22 Philipp Kern pk...@debian.org wrote: On Sun, May 20, 2012 at 12:37:44AM +0200, Philipp Kern wrote: Indeed, thanks for the report. It seems that the kernel driver switched from cu3088 to ctcm (the driver name is hardcoded in s390-netdevice). Furthermore I only see «/sys/bus/ccw/devices/0.0.0a00», i.e. just one device instead of its write partner 0.0.0a01. The same issue has been fixed in sysconfig-hardware with #566632, but there both devices turned up. This works for me (with the adjusted initrd): 0A00.2 CTCI 10.1.1.1 10.1.1.2 Does that also work for you, Andreas, with the squeeze kernel? -v please. ;-) I am s390 agnostic, I would need something like at the hercules console type in the exact string when X happens That network line should work with the squeeze d-i. It should also work with the newest s390 (or s390x) daily. And as said the line in the tutorial was wrong. BTW I have been unable to complete installations with stable images either. - The virtual machine just hangs at some point during the unpack phase. Symptoms like a hardware/heating or memory problem. I have never experienced anything like this in other circumstances but hercules generates a rather peculiar workload (100% CPU for a long time). Or is this related to AMD64 kernel with i386 userland? I guess you'd need to be more specific here. amd64 vs. i386 shouldn't be any problem, it's a pure user-level program. However it's very intense for anything laptop-ish or desktop without proper cooling. This means that you get to the SSH installer, configure everything and then it hangs without you being able to invoke a new SSH connection? Kind regards Philipp Kern -- 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/20120527153357.ga20...@hub.kern.lc
Re: wheezy installer images fail on hercules
On Sun, May 27, 2012 at 07:28:34PM +0200, Andreas Metzler wrote: the newest s390 (or s390x) daily - That is the one from May 8, 2012? http://d-i.debian.org/daily-images/s390x/ or http://d-i.debian.org/daily-images/s390/ Something post-May 23-ish. Kind regards Phliipp Kern signature.asc Description: Digital signature
Re: Bug#672290: RFS: uhub/0.4.0-1 (updated) -- High performance Advanced Direct Connect p2p hub
On Thu, Jun 07, 2012 at 10:58:57PM +0300, Boris Pek wrote: This version of package should fix FTBFS on s390 and s390x. Which is now important as I see in debian-devel-announce mailing list [2]. Sorry, but no: 117 files changed, 7945 insertions(+), 1683 deletions(-) I'm ok with sponsoring targetted fixes, but not new upstream versions. Please ask on mentors or your former sponsor. (This looks like drive-by sponsoring which makes me sad.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: S390 Release 6.0.5
On Thu, Jun 14, 2012 at 09:34:47AM -0400, Martin, Larry D 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? ftp.us.debian.org? That one's supposed to carry s390 (and does for me). If that doesn't work, /var/log/syslog should have some information why. Kind regards Philipp Kern -- 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/20120614180330.ga3...@hub.kern.lc
Bug#684766: persistent-net-generator broken on s390(x)
Package: udev
Version: 175-3.1
Severity: important
The network devices on s390(x) seem to increase their dev_id by one on every
reboot. Hence we get something like this with a new device coming up whenever
the VM is rebooted:
| # S/390 device at 0.0.0300 (qeth)
| SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==e4:1f:13:4e:25:1a, ATTR{dev_id}==0x14, ATTR{type}==1,
KERNEL==eth*, NAME=eth0
|
| # S/390 device at 0.0.0300 (qeth)
| SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==e4:1f:13:4e:25:1a, ATTR{dev_id}==0x15, ATTR{type}==1,
KERNEL==eth*, NAME=eth1
|
| # S/390 device at 0.0.0300 (qeth)
| SUBSYSTEM==net, ACTION==add, DRIVERS==?*,
ATTR{address}==e4:1f:13:4e:25:1a, ATTR{dev_id}==0x16, ATTR{type}==1,
KERNEL==eth*, NAME=eth2
This is not overly helpful. The persistent-net-generator has these rules
commented out:
| # S/390 interfaces are matched only by id
| SUBSYSTEMS==ccwgroup, \
| ENV{MATCHDRV}=$driver, ENV{MATCHID}=$id, ENV{MATCHADDR}=
This establishes persistent naming based on the device ID, which is stable on
s390(x). That's the 0.0.0300 listed in the comment. I don't think it should
match on the MAC address, as this is not configured explicitly by default.
Instead the commented out matching rules make more sense. However they alone
are not sufficient as this rule creates dev_id matching unconditionally:
| ATTR{dev_id}==?*, ENV{MATCHDEVID}=$attr{dev_id}
With this rule commented out I get this (two NIC case):
| # S/390 device at 0.0.0300 (qeth)
| SUBSYSTEM==net, ACTION==add, DRIVERS==qeth, KERNELS==0.0.0300,
ATTR{type}==1, KERNEL==eth*, NAME=eth0
|
| # S/390 device at 0.0.0304 (qeth)
| SUBSYSTEM==net, ACTION==add, DRIVERS==qeth, KERNELS==0.0.0304,
ATTR{type}==1, KERNEL==eth*, NAME=eth1
This seems to be stable.
Marco, could you come up with a fix that rearranges the dev_id properly so that
it's not added to the matching rules for ccwgroup devices? The only solution
so far for squeeze and wheezy is to delete the persistent-net-generator, but I
don't agree with that one. And I don't suppose that we want to add
SUBSYSTEM!=ccwgroup to that dev_id rule.
Thanks in advance
Philipp Kern
--
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/20120813163842.12928.94626.report...@spike.0x539.de
Re: installing s390x on hercules
On Mon, Aug 13, 2012 at 07:49:20PM +0900, KURASHIKI Satoru wrote: I've tried to install debian wheezy s390x on hercules, but I can't boot it. Please tell me correct procedure to do so. The very latest daily at the place you found should select a bootloader and a kernel. It was broken until this weekend. A blog post shall appear on planet.d.o about that work in the next days. I did not test it in hercules though. The netcfg link detection timeout will be fixed with the next daily. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: No security updates available for s390x
On Mon, Oct 15, 2012 at 09:22:01AM -0400, Stephen Powell wrote: 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? 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.) Kind regards Philipp Kern -- 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/20121015192302.ga22...@hub.kern.lc
Re: Wheezy NSS...
Hi, On Tue, Oct 23, 2012 at 08:45:25PM -0700, Jonathan Nieder wrote: Dave Jones wrote: Can the wheezy s390x kernel be saved as an NSS? If so, how? Based on [1], it looks like the answer is currently no, based on the following line in the kernel config file: # CONFIG_SHARED_KERNEL is not set The description of that option says Select this option, if you want to share the text segment of the Linux kernel between different VM guests. This reduces memory usage with lots of guests but greatly increases kernel size. You can build a custom kernel using that option if you wish. It works like this[2]: $ apt-get source linux # apt-get install build-essential fakeroot # apt-get build-dep linux $ cd linux-version $ fakeroot debian/rules source $ fakeroot make -f debian/rules.gen setup_s390_none_s390x as we're talking about s390x here that would be setup_s390x_none_s390x. $ cd debian/build/build_s390_none_s390x Same here. $ scripts/config --disable DEBUG_INFO $ scripts/config --enable SHARED_KERNEL That's «../source_none/scripts/config». $ cd ../../.. $ fakeroot make -f debian/rules.gen binary-arch_s390_none_s390x And again s390x_none_s390x instead of s390_none_s390x. I just did the recompilation. AFAICS the kernel size is indeed increased quite a bit. We currently have: -rw-r--r-- root/root 6303232 2012-10-22 15:36 ./boot/vmlinuz-3.2.0-4-s390x With SHARED_KERNEL on and DEBUG_INFO off as above: -rw-r--r-- root/root 7945728 2012-10-25 21:53 ./boot/vmlinuz-3.2.0-4-s390x So a NSS shareable kernel is 1.26 times larger than a plain one. And I fear that the additional bits cannot be discarded at runtime neither, but I cannot test this right now. Interestingly enough the kernel is already in its plain form 2.23 times bigger than an amd64 build of vmlinuz-3.2.0-3-amd64. Kind regards Philipp Kern [1] http://www.vm.ibm.com/linux/linuxnss.html [2] http://kernel-handbook.alioth.debian.org/ch-common-tasks.html -- 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/20121025221758.ga22...@hub.kern.lc
Re: dcssblk device driver configuration
Hi, On Sat, Oct 20, 2012 at 09:29:50PM -0500, Dave Jones wrote: I'm working with the s390x wheezy release of Debian and I want to use the dcssblk to access some existing DCSSes. How do I configure the kernel to load the dcssblk driver and access the DCSS at boot time? I can do this manually after boot by a modprobe dcssblk and a echo DCSSNAME /sys/devices/dcssblk/add but I want this done automatically at boot time? I think that really depends on when you need the driver to be loaded. The usual way would be to add a driver to /etc/modules. In theory the last script to execute during the boot process would be /etc/rc.local, but you should try to be idempotent there. Obviously that wouldn't help you if you need it ready for any earlier script to run properly. Kind regards Philipp Kern -- 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/2012102538.ga22...@hub.kern.lc
Re: Unable to run kde or gnome
On Tue, Nov 20, 2012 at 02:12:36PM -0500, Martin, Larry D wrote: I have installed Debian (2.6.32-5-s390x Sun Sep 23 08:59:07 UTC 2012) on a z9 - LPAR mode. I can login but cannot get either gnome or kde to work. Whenever I issue startx, I get: xf860OpenConsole: Cannot open /dev/tty0 (No such file or directory). On what graphical console would you expect X to appear? z doesn't have any. All you can do is using some kind of remote desktop, but not through startx. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Unable to run kde or gnome
On Wed, Nov 21, 2012 at 09:12:00AM -0500, Martin, Larry D wrote: I have logged on through Putty from my desktop. Are you saying that because Debian is running on the Mainframe there is no graphical interface available? No Linux system supports startx over putty. You can install GNOME or KDE and run it via X forwarding or xdmcp or VNC. But that's all not s390-specific. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Unable to run kde or gnome
On Wed, Nov 21, 2012 at 10:08:18AM -0500, Martin, Larry D wrote: Any idea why startx will not run. If I run it as root I get all the messages I posted earlier and if I run it as a user I get that I am not authorized. When I type gdm3 all I get is repeated messages about the display running for 0.2nnn seconds and have to break to get out of the loop. As I said it's not supported. I don't know what else to tell you. There's nothing startx could draw a display on. gdm/xdm/kdm needs an xdmcp configuration before they can be used. Xnest seems indeed one way to go. Another one is vncserver. But I already said all of that (granted, except Xnest, thanks for the hint.) Try startx on any x86 Linux box. It might start an X session on VT7 if you're root, but not in your Putty. (That question is not s390-related, so debian-u...@lists.debian.org might be a better fit for support.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Rebuilding Wheezy kernel
Hi, sorry for the late answer. I marked it as »to-do« and forgot about it. (Also I hoped that somebody else would answer.) On Wed, Nov 07, 2012 at 02:33:55PM -0600, Dave Jones wrote: fakeroot make -f debian/rules.gen binary-arch_s390x_none_s390x wakeup_source_unregister module: vmlinux, version: 0x7c778579, export: EXPORT_SYMBOL_GPL make[1]: *** [debian/stamps/build_s390x_none_s390x_plain] Error 1 make[1]: Leaving directory `/root/linux-3.2.23' make: *** [binary-arch_s390x_none_s390x_real] Error 2 root@debian:~/linux-3.2.23# Where might I find the build log that would expound on what's really wrong here? The reason for this is that Debian kernel builds check that no symbols unexpectedly appear or disappear. If that happens modules that were compiled against a given kernel version would break. That's the -4- in 3.2.0-4-s390x. This is increased when symbols are incompatible and modules need to be rebuilt. It might work to comment out the following line in »debian/rules.real«: python debian/bin/buildcheck.py $(DIR) $(ARCH) $(FEATURESET) $(FLAVOUR) Then probably rules.gen needs to be regenerated. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: s390x Install
On Wed, Nov 07, 2012 at 09:52:54AM -0600, Dave Jones wrote: Larry, you might try using the cio_ignore= kernel option to limit the number of addresses the zLinux kernel looks for at boot time. You might try something like this: cio_ignore=all,!0.0.1150,!0.0.fd00-0.0.fd02 will ignore at boot time all devices except those at addresses 1150, and FD00-FD02. I would put it in the generic parameter file you use at boot time to load the kernel and initrd files. Thanks Dave. I just added this to s390 Boot Parameters[1]: | If you boot the installer in a logical partition (LPAR) or virtual | machine (VM) where a lot of devices are visible, you might want to | instruct the kernel to restrict the list to a fixed set of devices. This | is advised for the installer's boot process if a lot of disks are | visible. The cio_ignore option supports both a blacklist (to only | disallow a few devices) and a whitelist (to only allow specific | devices): | | informalexample role=examplescreen | # blacklist: just ignore the two devices 300 and 301 | cio_ignore=0.0.0300-0.0.0301 | # whitelist: ignore everything but 1150, FD00, FD01 and FD02 | cio_ignore=all,!0.0.1150,!0.0.fd00-0.0.fd02 | /screen/informalexample | | Please note that all devices numbers' hex digits need to be specified in | lower case. To be considered during the installer's boot process the | above option needs to be added to filenameparmfile.debian/filename. But I'm neither an English native speaker nor a documentation guy. Kind regards Philipp Kern [1] http://d-i.debian.org/manual/en.s390/ch05s01.html#idp5194000 signature.asc Description: Digital signature
Bug#694826: unblock: s390-tools/1.16.0-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package s390-tools
The udev rules of s390-tools referred to the now non-existing udev tool
vol_id. The update to 1.16.0-2 correct this and use blkid instead. This
eliminates a spurious warning on-boot.
diff -Nru s390-tools-1.16.0/debian/changelog s390-tools-1.16.0/debian/changelog
--- s390-tools-1.16.0/debian/changelog 2011-12-14 10:06:36.0 +
+++ s390-tools-1.16.0/debian/changelog 2012-11-30 22:11:16.0 +
@@ -1,3 +1,10 @@
+s390-tools (1.16.0-2) unstable; urgency=low
+
+ * Drop the now non-existent vol_id from the shipped udev ruleset
+and use blkid instead.
+
+ -- Philipp Kern pk...@debian.org Fri, 30 Nov 2012 22:10:43 +
+
s390-tools (1.16.0-1) unstable; urgency=low
* New upstream release.
diff -Nru s390-tools-1.16.0/debian/s390-tools.udev
s390-tools-1.16.0/debian/s390-tools.udev
--- s390-tools-1.16.0/debian/s390-tools.udev2011-10-06 18:57:51.0
+
+++ s390-tools-1.16.0/debian/s390-tools.udev2012-11-30 22:10:41.0
+
@@ -17,7 +17,7 @@
KERNEL==dasd*[0-9], ENV{ID_UID}==?*,
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_UID}-part%n
# by-label/by-uuid (filesystem properties)
-IMPORT{program}=/sbin/vol_id --export $tempnode
+IMPORT{program}=/sbin/blkid -p -o udev $tempnode
ENV{ID_FS_USAGE}==filesystem|other|crypto, ENV{ID_FS_UUID}==?*,
SYMLINK+=disk/by-uuid/$env{ID_FS_UUID}
ENV{ID_FS_USAGE}==filesystem|other, ENV{ID_FS_LABEL_SAFE}==?*,
SYMLINK+=disk/by-label/$env{ID_FS_LABEL_SAFE}
unblock s390-tools/1.16.0-2
Kind regards and thanks
Philipp Kern
--
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/20121130221826.4240.22884.reportbug@spike.Speedport_W723_V_Typ_A_1_00_096
Re: Bug#694826: unblock: s390-tools/1.16.0-2
Hi, am Mon, Dec 03, 2012 at 08:40:15AM -0800 hast du folgendes geschrieben: I am really a novice with DEBIAN (LINUX in general) and am having a problem trying to apply this fix. I have tried 'aptitude' but it doesn't seem to find any updates. I don't seem to find the 'how to do' doc. How do I download and apply a fix? /etc/apt/sources.list lists all the package sources your system knows about. You can add a new deb line with wheezy replaced with sid to have access to newer packages that didn't trickle down to your distribution yet. You need to do »sudo apt-get update« to fetch the lists. But your system would then prefer the newer packages, hence you need something like this: pkern@spike ~ % cat /etc/apt/preferences Package: * Pin: release o=Debian,a=testing Pin-Priority: 500 Package: * Pin: release o=Debian,a=unstable Pin-Priority: 300 Package: * Pin: release o=Debian Pin-Priority: -1 Then you can do »sudo apt-get install s390-tools=1.16.0-2«. In eight days it will probably enter wheezy, but obviously more eyes are appreciated. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#695057: udev's custom persistent-storage rules should not call dasd_id
Package: udev
Version: 175-7
Severity: normal
Hi,
udev in Debian currently ships with custom persistent-storage rules that
also contain a snippet about s390's DASDs in debian/patches/debian_rules:
+KERNEL==dasd*, \
+ IMPORT{program}=dasd_id --export $tempnode
dasd_id is no longer shipped by s390-tools. Instead the package now
provides its own rules using dasdinfo:
# by-id (hardware serial number)
KERNEL==dasd*[!0-9], IMPORT{program}=/sbin/dasdinfo -a -e -b $kernel
KERNEL==dasd*[!0-9], ENV{ID_SERIAL}==?*,
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}
KERNEL==dasd*[0-9], ENV{ID_SERIAL}==?*,
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_SERIAL}-part%n
KERNEL==dasd*[!0-9], ENV{ID_UID}==?*,
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_UID}
KERNEL==dasd*[0-9], ENV{ID_UID}==?*,
SYMLINK+=disk/by-id/$env{ID_BUS}-$env{ID_UID}-part%n
Could you please drop the above two lines, preferably for wheezy?
Currently it produces spurious warnings during the boot process about
dasd_id not being found.
Kind regards and thanks in advance
Philipp Kern
--
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/20121203204610.882.89097.report...@spike.0x539.de
Re: Can't start VNCSERVER
On Tue, Dec 18, 2012 at 07:44:12AM -0800, Tom Huegel wrote: I am trying to start the VNCSERVER but it is not working. I think the problem has to do with not being able o find the font library. Couldn't start Xtightvnc; trying default font path. Please set correct fontPath in the vncserver script. *** glibc detected *** Xtightvnc: free(): invalid next size (fast): 0xad59a280 *** I installed the x11 font library,but can't find where. Any ideas where to look? What do you invoke exactly? »vncserver« is a wrapper script that should invoke Xtightvnc with the right options. Still it's of course possible that there's a bug in the software. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: QEMU s390/s390x install.
On Wed, Dec 19, 2012 at 12:32:00PM -0600, Mestnik, Michael J - Eagan, MN - Contractor wrote: Any advice? Would there potentially be a how-to posted? Sounds like I'm not the only one to have problems here, though from what I can tell it looks like ppl are figuring it out and then abandoning their posts. True. KVM (which is basically »-enable-kvm« passed to qemu) on s390x itself works, it's just plain qemu-system-s390x on non-System z hardware that doesn't. Hence you could also use hercules to get started. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Add a dasd volume.
Nelson, am Fri, Mar 01, 2013 at 05:48:50PM -0600 hast du folgendes geschrieben: To get it online and mounted I had to resort to the following: In /etc/rc.local I added: /sbin/chccwdev -e 0.0.0240 mount -ato reread /etc/fstab I am looking for a way to make the /dev/dasdb(1) come online at ipl and therefore the /etc/fstab entry will mount the filesystem at ipl also. Debian adopted the same mechanism as the RPM-based distributions on s390 (AFAIK, never having touched one): /etc/sysconfig/hardware. Just touch a config-ccw-0.0.0240 (be sure to use lowercase hex digits if applicable) and potentially rebuild the initrd if it's needed early on (using »update-initramfs -u -k `uname -r`«). That should activate the disc on-boot. If you used debian-installer there should be a file for your existing disk already. The alternative is passing »dasd=240« (among with the other DASDs you need) on the kernel command-line. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Wheezy FCP problem
Hi, On Mon, Mar 18, 2013 at 02:39:09PM +, PROT Pierre-François wrote: But a chccwdev -e 3400 or chccwdev -e 4400 does nothing. I have the /sys/bus/ccw/drivers/zfcp/0.0.3400 directory, but not the wwpn subdirectory. please try to write 1 into /sys/bus/ccw/drivers/zfcp/0.0.3400/port_rescan. Apart from that the output of dmesg would be helpful to see why no port has been detected. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Wheezy FCP problem
Hi, On Tue, Mar 19, 2013 at 10:04:57AM +, PROT Pierre-François wrote: I have already made a port rescan, but the result is the same (no more wwpn subdirectory and nothing in the log). [ 315.807811] qdio: 0.0.3400 ZFCP on SC 2 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W A that looks correct. In the hope that there weren't more clarifying messages in dmesg, I'd suggest that you send your question to linux-...@vm.marist.edu. It might be Debian-specific in the sense of the kernel version being special, but it might be a general problem, too. Sadly I currently lack time and a wheezy test environment, but that's what I get on squeeze with a working zfcp: [3.106777] qdio: 0.0.2000 ZFCP on SC 0 using AI:1 QEBSM:1 PCI:1 TDD:1 SIGA: W AO [3.177469] scsi 0:0:9:1: Direct-Access IBM 2145 PQ: 0 ANSI: 6 I.e. the next message is already the result of the probe. To automate the startup one writes the LUN into a special file, there should be no need to create manual udev rules: /etc/sysconfig/hardware # cat config-ccw-0.0.2000 ZFCP_DEVICES=(0x:0x0001) (WWPN masked.) This setup does not use NPIV, so I'm a bit at a loss. The WWPNs of the peers should turn up in /sys/bus/ccw/drivers/zfcp/0.0.3400 in any case, if it's properly configured. Maybe somebody on LINUX-390 knows more about it. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#704080: unblock: libarchive/3.0.4-3
Hi, On Fri, Apr 05, 2013 at 03:21:43AM +0100, peter green wrote: Specifically it seems that s390x has not successfully built this package for some time (since before s390x stopped being considered a broken and fucked architecture). As a result the s390x package is out of date in both testing and unstable. Britney will not migrate the package if there are out of date binaries in unstable (even if there are also out of date binaries for the same package in testing). The cause of the build failures seems to be a testsuite failure. Afaict there are several options in this scenario. my personal guess is that there's probably nothing s390x-specific to it, it's probably broken with 64bit big endian. The d-ports build for sparc64 fails as well. Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#710675: please build for s390 and s390x
Package: crash Version: 6.0.6-1 Severity: normal crash contains support for s390x, please build it on this architectures. It can confirm that it builds and that the result works. Thanks Philipp Kern -- 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/20130601125218.6928.22394.report...@simplex.0x539.de
Bug#710674: please build for s390x
Package: makedumpfile Version: 1.4.3-1 Severity: normal makedumpfile contains support for s390x, please build it on this architecture. I can confirm that it builds and that the result works. Thanks Philipp Kern -- 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/20130601125216.6488.51686.report...@simplex.0x539.de
Re: How do I get the box-drawing characters to look right for Debian Installer? (SOLVED)
On Sat, Jun 29, 2013 at 05:59:34PM -0400, Stephen Powell wrote: 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). UTF-8 has been the default on Debian for ages now and there really is no reason to run it with a different charset. (convmv helps if you're dealing with wrongly encoded files.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: status of s390 toolchain maintenance
On Mon, Jul 01, 2013 at 11:42:44AM +0200, Matthias Klose wrote: yesterday Aurelian Jarno did switch the GCC default to 4.8 in the VCS. However I don't see him in the Debian GCC maintainer list as GCC port maintainer. In the past I only did see s390 contributions and s390 related bug triage from Bastian Blank. Is this change coordinated with Bastian? Please could both of you add the relevant information to the README.Debian (or send me patch), if you are actively involved in GCC maintenance on s390(x)? Aurelien did a lot to bootstrap s390x and is also working on the port both wrt buildd maintenance and debugging. He is listed on [1], too. But obviously that does not imply GCC maintainance for s390*. And indeed, we should've copied Bastian on this. I apologize. Kind regards Philipp Kern [1] http://release.debian.org/wheezy/arch_qualify.html -- 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/20130703041030.ga5...@hub.kern.lc
Re: Using netboot Debian installation images in the Hercules emulator
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. Thanks Philipp Kern -- 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/20130706163125.gc12...@thaum.roam.corp.google.com
Re: Qt5 switching qreal from float to double on arm*
On Thu, Nov 07, 2013 at 02:46:27PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: - If we decide to do the change in Qt5, it will be *without* soname bump. Yes, I know many of you will think of this as **ugly**, but so far means 3 binNMUs per arch. Now if this is not acceptable, then no change will be made, because I won't change Qt5's SONAME. What is your plan to support partial upgrades? BinNMUs can require new Qt versions to be installed, but Qt can be upgraded independently to the newer version, causing the rdepends to crash. This can potentially be solved by Breaks, but it still breaks assumptions of people using Debian in that such ABI breaks will be communicated through SONAME bumps. And the old lib will not even be coinstallable. (Of course a good time to do such changes are in fact SONAME bumps, but I realize that this won't happen for Qt for quite some time.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Hercules Bus Error
On Wed, Feb 19, 2014 at 03:15:06PM -0500, Stephen Powell wrote: Now back to my main subject. For network devices in Debian for s390x, hardware configuration is designed to be done by sysconfig-hardware, and software configuration is designed to be done by ifupdown. These two packages front-end the lower level commands. [...] 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!) Kind regards Philipp Kern -- 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/20140224022210.ga22...@simplex.0x539.de
Re: Debian-390 / Hercules Problems
On Tue, Feb 18, 2014 at 11:23:19PM -0500, Stephen Powell wrote: 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? Is znetconf solely doing runtime configuration or does it also try to persist it? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Debian-390 / Hercules Problems
On Tue, Feb 18, 2014 at 01:09:43PM -0600, 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. Well, we are living in a world where IBM does not take our patches. More utilities add to the maintenance burden, especially if it's essentially duplicated functionality to /etc/sysconfig/hardware. More construtively: znetconf seems to hardcode the path to lsznet.raw, which hardcodes the path to znetcontrolunits. We could ship the latter two in /lib/s390-tools, I guess, so that's ok. I'd encourage you to file a bug against s390-tools in Debian so that it's not forgotten. Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Thu, Aug 14, 2014 at 06:49:20AM -0400, Stephen Powell wrote: 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. 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. That being said, I had to recompile s390-tools on sid, and I do not run sid due to the C breakage. It worked before the recompilation, hence there might be a change in sid vs. wheezy that caused this. You are talking about Hercules, right? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Fri, Aug 15, 2014 at 10:46:54AM +0200, Michael Holzheu wrote: On Thu, 14 Aug 2014 21:45:53 -0400 (EDT) Stephen Powell zlinux...@wowway.com wrote: 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. Just for confirmation: Stephen is right. The zipl tool is a normal C program that uses the glibc. The zipl boot loader code under the boot source directory does not use the glibc or any other external library. Before s390-tools-1.24.0 it was written 100% in assembler. With s390-tools-1.24.0 we have rewritten the code in C and have added our own minimal libc. I should've written (e)glibc instead of C library. It's what I meant. I tried to simplify things and failed. The question of is this Hercules was also more related to where is the value coming from, as CP might do things differently. So Hercules should log the whole PSW. I can also only see it logging that and the CPU address/ID, not a wait state code. Do you happen to have the PSW handy? Kind regards Philipp Kern signature.asc Description: Digital signature
Bug#758488: python3: float conversion broken on s390x
Package: python3-minimal Version: 3.4.1-1 Severity: serious X-Debbugs-Cc: debian-s390@lists.debian.org The datetime module fails its initialization assertions on s390x with python3 upon import: import datetime Traceback (most recent call last): File stdin, line 1, in module File /usr/lib/python3.4/datetime.py, line 619, in module microseconds=99) File /usr/lib/python3.4/datetime.py, line 395, in __new__ assert abs(microseconds) 3.1e6 AssertionError (Disregard slight shifts in the line numbers.) The actual problem is this: float(99) 1073740750258176.0 Sadly python3-minimal fails to configure because of this, which in turn lets other packages being upgraded fail to fully install. int to float casts are working with python2, but are completely broken with python3: float(1) 1073741824.0 float(-1) -1073741824.0 Kind regards Philipp Kern -- 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/68f19e31a303b711a62c42ce7b0da...@hub.kern.lc
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Fri, Aug 22, 2014 at 07:21:31PM -0400, Stephen Powell wrote:
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 load_wait_psw
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
sclp_wait_for_int+0x9a
33ee: a7 28 00 02 lhi %r2,2
33f2: a7 f4 00 08 j 3402
sclp_wait_for_int+0xa6
return ETIMEOUT;
} while (S390_lowcore.ext_int_code != 0x2401);
33f6: a7 1e 24 01 chi %r1,9217
33fa: a7 74 ff eb jne 33d0
sclp_wait_for_int+0x74
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 load_wait_psw
if (S390_lowcore.ext_int_code == 0x1004)
32e6: 48 10 00 86 lh %r1,134
32ea: a7 f4 00 01 j 32ec sclp_wait_for_int+0x84
32ee: 07 07 nopr%r7
-
With gcc-4.8:
static inline int wait(void)
{
do {
load_wait_psw(0x010200018000ULL,
S390_lowcore.external_new_psw);
331e: e3 20 d0 00 00 04 lg %r2,0(%r13)
3324: a7 39 01 b0 lghi%r3,432
3328: c0 e5 ff ff fb ac brasl %r14,2a80 load_wait_psw
if (S390_lowcore.ext_int_code == 0x1004)
332e: e3 10 00 86 00 91 llgh%r1,134
3334: a7 1e 10 04 chi %r1,4100
3338: a7 84 00 0a je 334c sclp_wait_for_int+0x9c
return ETIMEOUT;
} while (S390_lowcore.ext_int_code != 0x2401);
333c: a7 1e 24 01 chi %r1,9217
3340: a7 74 ff ef jne 331e sclp_wait_for_int+0x6e
return 0;
3344: a7 28 00 00 lhi %r2,0
3348: a7 f4 00 04 j 3350 sclp_wait_for_int+0xa0
That does look much better for 3338, 3340, not really for 3348 (to 3350). It
does fix the issue at hand, but it's a band-aid at most. I installed the
package on wheezy (compiled on sid) and it booted...
Kind regards
Philipp Kern
--
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/20140824184913.ga6...@hub.kern.lc
Re: Adding DASD to a Debian guest
On Thu, Aug 13, 2015 at 07:02:21AM -0400, Howard V. Hardiman wrote: I am configuring a golden image that will live on one piece of dasd with LVM. 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 I encountered the same problem recently on a crash-and-burn machine and it needed some coercing. I see the following in dmesg: [0.472658] dasd-eckd 0.0.0100: New DASD 3390/0C (CU 3990/01) with 2 cylinders, 15 heads, 224 sectors [0.484985] dasd-eckd 0.0.0100: DASD with 4 KB/block, 1440 KB total size, 48 KB/track, compatible disk layout [0.488496] dasda:VOL1/ 0X0100: dasda1 dasda2 And the partitions are set up like this: # fdasd -p /dev/dasda WARNING: Your DASD '/dev/dasda' is in use. If you proceed, you can heavily damage your system. If possible exit all applications using this disk and/or unmount it. reading volume label ..: VOL1 reading vtoc ..: ok Disk /dev/dasda: cylinders : 2 tracks per cylinder ..: 15 blocks per track .: 12 bytes per block ..: 4096 volume label .: VOL1 volume serial : 0X0100 max partitions ...: 3 --- tracks --- Device start end length Id System /dev/dasda1 2 5462 54611 Linux native /dev/dasda2 5463 29 2945372 Linux lvm exiting... # cat /proc/mounts | grep dasd /dev/dasda1 /boot ext2 rw,relatime 0 0 # pvs PV VGFmt Attr PSize PFree /dev/dasda2 sysvg lvm2 a-- 13.48g0 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 When the zipl-installer part failed you can always do two things: Go to a shell (debian-installer) offers you this in the menu. Then run `sh -x /var/lib/dpkg/info/zipl-installer.postinst'. That should show you where the bootloader installation actually fails. (I.e. calling zipl, maybe with a few log lines of what's missing.) Then you can also manually run it via `chroot /target /bin/bash' and then running `zipl' in there. How does it complain and what do the above commands show? 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? You will always need zipl. You could in theory punch the files from within the chroot during installation and load that up, but the correct way is to get zipl to install. Kind regards and thanks Philipp Kern
Re: binNMUs: please exercise some care
On Fri, Oct 23, 2015 at 02:46:23PM +0200, Thorsten Glaser wrote: > On Fri, 23 Oct 2015, Adam D. Barratt wrote: > > and testing), so the only way to be certain what binNMU number to use is to > > check manually. In practice what actually happens is that people forget > > about > Maybe wb could do a “dak ls” and whatever the equivalent for dpo mini-dak is. Unfortunately it is not being run on the same host as dak either. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: specifying virtio block device as root filesystem for Debin S390X install?
On Wed, Oct 28, 2015 at 08:47:51PM -0400, Kevin Kwan (Personal) wrote: > Is it possible to specify a virtio block device as a root filesystem within > the Debian s390x installer? I specified a virtio disk for > qemu-system-s390x, and through some miracle was able to get the virtio > networking up and running via the latest debian s390x kernel/initrd, and had > no issues up until the disk partitioner. The partitioner was able to see > the disk (/dev/vda) and allows partitions to be created (vda1/2/etc), but it > does not allow it to be used. The partition disks section only allows the > option of swap space, physical volume for encryption, and "do not use". I wonder how you got into the disk partitioner in the first place. All my tries caused fatal errors in the DASD configuration part and it wouldn't let me proceed. So s390-dasd will need a fix to detect this situation. After I deactivated s390-dasd's postinst, it proceeded into the installer and offered all filesystem options. (I'm not saying that the result would work, just that the partitioner created filesystems correctly.) How did you invoke qemu? (Which seems to be incredibly fiddly, especially at HEAD.) What version? Kind regards Philipp Kern signature.asc Description: Digital signature
Re: specifying virtio block device as root filesystem for Debian S390X install?
On Mon, Nov 02, 2015 at 10:46:39AM -0500, Kevin Kwan (Personal) wrote: > it turns out that since I was running the Debian 9/stretch kernel/initrd, it > was not loading the ext3/4 modules due to missing modules. This is likely > the reason why partman failed to give me an option to make the filesystem. > I had to boot the machine up on the Debian 8/jessie kernel/initrd, shoehorn > in the netcfg_1.134_s390x udeb to get rid of that virtio eth0 error, and > then mess with the dasd postint to bypass the DASD designation. However, I > was able to get partman working and got the filesystem doing, and it's > installing the base system now, so I suppose that it is okay. FWIW, there are daily builds on [1] that should have matching-up kernel/modules. But yes, that breaks quite often during testing's lifetime until it's cut to stable. Please do report bugs that you encounter. Kind regards Philipp Kern [1] http://d-i.debian.org/daily-images/s390x/daily/generic/ signature.asc Description: Digital signature
RE: specifying virtio block device as root filesystem for Debian S390X install?
On 2015-11-04 05:23, Kevin Kwan (Personal) wrote: If I use the CCW version: qemu-system-s390x.exe -machine type=s390-ccw-virtio-2.5 -m 512 -hda linux.disk -device virtio-net-ccw,netdev=net0 -netdev user,id=net0 -k en-us -redir tcp:9022::22 I just use -nographic on Linux and it does the right thing. Then I'll see a console, followed by some complaints about missing /sys/bus/ccw/devices/virtio/cutype (sysfs not populating info on the CCW bus?) Can you transcribe the actual failure you see? Kind regards Philipp Kern
RE: specifying virtio block device as root filesystem for Debin S390X install?
Hi, On 2015-11-02 00:24, Kevin Kwan (Personal) wrote: I actually do run into fatal errors if I run this on my Debian x64 machine, but I think it's possible issues with the S390X TCG in the older builds of QEMU - actually have both the Windows and Linux version running side-by-side - the Windows version does get me further...although I do suspect other issues down the line. qemu master actually segfaults[1] if you try to use s390x. [2] hopefully fixes that (untested). How did you deactivate the s390 postinst on the installer shell? You can go back to the menu, go down and "Execute a shell". Then edit /var/lib/dpkg/info/s390-dasd.postinst with nano and add an "exit 0" after the shebang. I did push a fix to s390-dasd[3] yesterday night. If you use the unstable udebs, you should get it. Otherwise in five days. With that it will simply exit if there's no DASD channel found on the bus. I think that we could stuff that into stable as well. The interesting side-bit is that I tried to define the machine as a virtio-ccw machine using the following command, and then define the disk and networking as channel devices: qemu-system-s390x.exe -machine type=s390-ccw-virtio-2.5 -m 512 -kernel kernel.debian9 -initrd initrd.debian9 -hda linux.dsk -device virtio-net-ccw,netdev=net0 -netdev user,id=net0 -k en-us -redir tcp:9022::22 I was able to define it, but Debian cannot initialize it on boot (virtio_ccw 0.0.: Failed to set online: -5), so that's a bit of a dead end. Yeah, I had the same issue back in August. With current qemu and current kernel (4.1 worked, but also 4.2) it worked for me. Kind regards Philipp Kern [1] http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg7.html [2] http://lists.nongnu.org/archive/html/qemu-devel/2015-11/msg00025.html [3] https://packages.qa.debian.org/s/s390-dasd/news/20151101T222109Z.html
Re: Adding DASD to a Debian guest
On Sun, Aug 16, 2015 at 05:27:21PM -0400, Stephen Powell wrote: > 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. 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 was under the impression -- mostly because of the presence of the mentioned hook script -- that this already happened. > 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. The correct thing is to fix that. There are multiple facets to that. I guess the easiest is to include the list of /etc/sysconfig/hardware in the initrd, in the hope that the installer writes it out already with all configured DASDs. Otherwise you need to figure out the root disks, which is hard to generalize on Linux. (No "give me all underlying disks for this mount point" command.) > 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. I'm sympathetic to making it more alike other platforms. 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. (OTOH, if someone wants to implement that for Debian that'd be great.) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: [OT] Re: Hercules - how to get a zVM OS (legally bought!) and put it on a VM under Hercules?
On Wed, Aug 26, 2015 at 09:56:32PM -0400, Stephen Powell wrote: > 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. 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 Kind regards Philipp Kern signature.asc Description: Digital signature
Re: [OT] Re: Hercules - how to get a zVM OS (legally bought!) and put it on a VM under Hercules?
On Sat, Aug 22, 2015 at 11:24:54AM -0400, Stephen Powell wrote: 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. It doesn't help in this specific instance, put qemu can emulate System z now and provides much better performance than Hercules. That being said, it also relies on virtio devices, which means that it isn't of much use to run z/VM on it. (Plus the emulation might be incomplete and/or IBM's products might depend on undocumented instructions.) 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. Kind regards Philipp Kern [*] There's also z/PDT. But well, that one really need discussions with IBM and all.
Re: Adding DASD to a Debian guest
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.) Kind regards and thanks Philipp Kern signature.asc Description: Digital signature
Re: Please bootstrap uuagc
Hi Colin, On Tue, Dec 22, 2015 at 02:25:37PM +, Colin Watson wrote: > Could somebody with appropriate access bootstrap the uuagc package on > s390x, please? It has a circular build-dependency on itself, but in > version 0.9.42.3-8 I've made it straightforward to break this cycle > using build profiles: you need to do an initial build with the "stage1" > profile (e.g. sbuild --profiles=stage1), install the resulting .deb, > then do a normal build. I uploaded it. Thanks. :) Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Bug#808041: s390-zfcp: Install Debian on FC-attached SCSI devices on s390
Hendrik, On Wed, Dec 16, 2015 at 04:36:19PM +0100, Hendrik Brueckner wrote: > So that's why there the DASD and the FCP device configuration module: to > enable DASD and FCP devices and block devices and SCSI devices available > to the Linux instance. Then, they can be partitioned like any other > SCSI disk. (I have installed Debian on zFCP in the past, but I moved it from zVM.) Is there a way I could test FCP installation? As far as I understand there is no emulation of a zFCP-like setup anywhere right, and you'd need to have access to a zFCP controller? (Which are harder to partition/segment than DASD-based storage…) Kind regards Philipp Kern
Re: [Stretch] Status for architecture qualification
On 2016-06-05 12:01, Niels Thykier wrote: * amd64, i386, armel, armhf, arm64, mips, mipsel, powerpc, ppc64el, s390x - *No* blockers at this time from RT, DSA nor security. - s390, ppc64el and all arm ports have DSA concerns. What is the current DSA concern about s390x? Kind regards and thanks Philipp Kern
Re: Packaging libica
On Tue, Feb 02, 2016 at 12:26:39AM +0100, Dimitri John Ledkov wrote: > I have packaged libica for Ubuntu, and I'm now planing to package > ibmca too. I would like to upload these into debian. > > May I "join" the debian-s390 team? and use this mailing list as the > Maintainer field? In general this is fine with me as long as you add yourself as an uploader. Where are updates to this package published? Kind regards Philipp Kern
Bug#813491: s390-tools: packaging updates
On Tue, Feb 02, 2016 at 01:57:56PM +, Dimitri John Ledkov wrote: > I've modernised packaging a bit, and fix a bunch of lintian tags. > > I also made a patch to prevent FTBFS, when toolchain has PIE enabled by > default. > > Please consider applying the below patch. Please use your connections with IBM to apply the spelling fixes upstream. Every divergence we keep on the Debian side needs to be justified as they are a pain to rebase on a new release. The same is obviously true of the error-manpages diff as well, but that was already there. I'd appreciate if IBM could look through the patches if anything could be done to get them upstream so that we can carry less of a delta. The other changes are fine to me if there's no change to the actual package output except descriptions and build output. Did you test the resulting package on an actual s390 machine on *Debian*? I'm a bit surprised about the explicit addition of the hardening flags, given that none of the binaries is suid nor a network daemon. So we could just follow the distro-default here. But I'm not too bothered by it. Kind regards and thanks Philipp Kern
Re: cmsfs on debian
On 12/06/2015 12:52 PM, Offer Baruch wrote: > I was wondering if the following commands are available on Debian, i > can't seem to find them: > cmsfscp, cmsfslst and cmsfscat. > > all i can find is cmsfs-fuse. > although i can manage using cmsfs-fuse instead of the other commands i > already have some code working that is depended on these... > on Rehdat for example there is a special rpm for that (s390utils-cmsfs). > couldn't find a package for it on Debian. > > I am using Debian 8.2. A very (much too) late reply: This would require a different piece of software that seems to be unmaintained. For us it's much easier to just ship the IBM-provided and -maintained cmsfs-fuse that's part of s390-tools. I'd expect that all your use cases can also be mapped to that and I'd expect other distributions to carry that as well. Kind regards and thanks Philipp Kern signature.asc Description: OpenPGP digital signature
Bug#840230: When installing to rootfs on LVM, an empty subvol= is appended to rootflags
Package: zipl-installer
Version: 0.0.33
Severity: serious
zipl-installer 0.0.33 breaks installation for normal non-btrfs root
filesystems.
(initramfs) cat /proc/cmdline
root=/dev/mapper/vg-root rootflags=subvol= BOOT_IMAGE=0
The empty subvol= makes mount barf as it's not a valid ext4 flag. The code
does not seem too healthy to me either:
if subvol="$(btrfs subvolume show /target 2>/dev/null | sed -n '2s/.*:[\t
]*//p')"
then
info "Root filesystem on btrfs subvolume ${subvol}"
PARAMETER="$PARAMETER rootflags=subvol=${subvol}"
fi
It'd have been more helpful to take the output and compare it to the empty
string instead.
Re: Scripts building kernel and initrd images
On 12/13/2016 01:51 AM, Tuan M. Hoang wrote: > As far as I learnt from the debian-s390 archive, mainframes 'prefer' to > boot using kernel image (kernel.debian, initrd.debian) rather than from > ISO/CD images. > > I would like to learn the code that build up these kernel & initrd > image files, which are located at > http://ftp.nl.debian.org/debian/dists/stable/main/installer-s390x/current/images/generic/. > If the code is publicly accessible, where should I can find them ? I > guess the code shares some similarities with those building ISO images > on other arch but I don't even know where to get them neither. https://anonscm.debian.org/cgit/d-i/debian-installer.git/tree/ has the code. I suppose for ISOs you need https://anonscm.debian.org/cgit/debian-cd/debian-cd.git/tree/ Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Bug#858943: unblock: systemd/232-22
On 04/01/2017 01:45 AM, Cyril Brulebois wrote: >>> * udev: Create persistent net names for virtio CCW devices. >>> This only affects s390x as only this has CCW devices. This provides >>> stable network interface names for those and avoids changing the names >>> on updating Stretch to Buster. (Closes: #856559) >> >> https://anonscm.debian.org/git/pkg-systemd/systemd.git/commit/?h=stretch=bb9ad652f309a90a5424381503083ee9a530a888 >> >> (might be relevant for the installer) >> >> This only affects s390x, so regression potential is low and it's >> important to get into stretch, otherwise we'd have migration issues in >> buster (as names would change, which would be ugly) > > Adding debian-s390@lists.debian.org to the loop to make sure they're > aware of this. Can't really judge whether this could be annoying in d-i, > it seems to me that's just fixing a move which hadn't happened with the > net.ifnames transition, for specific hardware? FWIW, I have tested this on an installation and haven't seen any problems. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: OSA and bridge_role=primary on boot
On 04/26/2017 02:05 PM, Dimitri John Ledkov wrote: > Yeah, in Ubuntu we kind of cheat. The installer is using sysconfig > stuff, but at the end of the install uses chzdev to take a dump of the > running configuration and store that on disk. This way all installed > systems only use chzdev/lszdev. > > You can install and use ubuntu package, and chzdev/lszdev configs are > not conflicting with existing stuff as they simply generate udev rules > that one places in /etc/udev/rules.d/ dir. > > I was late on many things for stretch =/ > > Ideally I was hoping to have full chzdev support in d-i, such that one > can preseed any devices, with any of the supported args (e.g. to be > able to install the system with e.g. bridge_role=primary et al) FWIW, you don't need to hold back on git commits to d-i for chzdev support even during freeze time. We can also negotiate uploads to experimental for s390-tools if needed. Now if something like Viktor's suggestion would've worked, I think we could've fixed stretch using that as well. But then it's true that chzdev should be the way forward. And there's too little man power to just make it happen in Debian right now.[*] Kind regards Philipp Kern [*] I hold that Ubuntu could've just made it happen within Debian without much trouble. Even though I sort of understand the context why that didn't happen. signature.asc Description: OpenPGP digital signature
Re: Debian 9 on hercules
On 19.08.2017 20:40, Bercik wrote: > Hello again, > > I did it! Problem is not fixed, but I figured out a workaround: > - install Debian 8.1 > - do upgrade with 9 sources.list > - do dist-upgrade after that > > > proof: > bercik@rescue:~$ cat /etc/issue.net > Debian GNU/Linux 9 > bercik@rescue:~$ uname -a > Linux rescue 4.9.0-3-s390x #1 SMP Debian 4.9.30-2+deb9u3 (2017-08-06) > s390x GNU/Linux > bercik@rescue:~$ date > sob, 19 sie 2017, 20:38:28 CEST > bercik@rescue:~$ > > > So it's not kernel issue or anything else. It must be something wrong > with installer itself. Should I report a problem somewhere? or we are > only ones who can't do fresh install on hercules? I'm happy to retest if you can give me the hercules.cnf you used. Kind regards Philipp Kern
Re: Debian 9 on hercules
On 08/19/2017 09:34 PM, Philipp Kern wrote: >> So it's not kernel issue or anything else. It must be something wrong >> with installer itself. Should I report a problem somewhere? or we are >> only ones who can't do fresh install on hercules? > > I'm happy to retest if you can give me the hercules.cnf you used. Bercik sent me their config and I'm able to confirm the bad behavior. But it looks to me as if console messages are swallowed. As soon as I add sleep() calls around all my writes, they succeed. (Which makes printf debugging very weird.) And indeed, if I enter ".1" it continues with "The following device numbers might belong to CTC or ESCON connections.". So all that happens is that either Hercules or the kernel while sending swallows the output and you can't actually see the prompts. That also matches the fact that there are very few startup messages from the kernel altogether. Essentially every message that doesn't have a bunch of other messages following (plus the first of the batch) lands on the console, the other ones are discarded. That makes me incredibly suspicious that this is a problem in Hercules. It's also not in the typescript generated by script(1), so it's not simply overwriting screen content either. I guess we'd need to either raise this with the Hercules people or instrument Hercules to see where the lines are missed. Kind regards Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Please give back golang-1.8 (1.8.3-1) on s390x
On 06/25/2017 04:42 PM, Anthony Fok wrote: >>> Or, better yet, is there a way to find out what went wrong on >>> zemlinsky? Is it an older machine with an older CPU that does not >>> support some newer CPU instructions? (Sorry, I know nothing about >>> s390x and I am likely completely wrong.) >> >> That is actually the problem. On s390x golang requires a higher ISA than >> the one Debian targets. I have started to patch golang-1.7 to avoid these >> new instructions a few months ago, but upstream is not interested by >> supporting older CPUs and keep adding more usage of new instructions. > > Thank you for your detailed explanation, and thank you for your > efforts in trying to solve it. > > But yeah, I guess golang users on s390x would just have to accept the > fact that they need a newer CPU. Thankfully, the majority of Debian's > s390x machines (buildd and porterbox), 3 out of 4, support the newer > instructions. :-) What's the current ISA requirement for golang? zEC12? z13? I suppose popcon (as misleading as it is) likely doesn't have h/w stats? (And I know that the current count of actual submissions is... 12.) Kind regards and thanks Philipp Kern
Re: Choose a mirror for install, no (old..)oldstable releases at all mirrors
On 18.06.2017 21:03, Maxim Bochagov wrote: > Can anyone say, what happened with http/ftp mirrors? > > Now I can select, for S390, only one of three: > stretch - stable > buster - testing > sid - unstable > > Where is Jessie, other releases?!! I'm not sure where you look for it and you included no details whatsoever. Jessie aka oldstable is still on the mirrors for s390x (s390 has been unsupported for a long time now). Kind regards Philipp kern signature.asc Description: OpenPGP digital signature
Bug#685134: [s390-tools] please add patch from qemu
On 02/03/2016 09:27 AM, Viktor Mihajlovski wrote: > On 02.02.2016 01:01, Dimitri John Ledkov wrote: >> On Fri, 17 Aug 2012 11:21:04 +0200 bastien ROUCARIES >> <roucaries.bast...@gmail.com> wrote: >>> Please add http://repo.or.cz/w/s390-tools.git for booting s390 from qemu. >>> it port virtio. >>> I have ported the pach queue to recent s390-tools. Not tested only merge >>> without conflict. >> Is this still required? I see that qemu-2.5 has support for booting El >> Torito .iso images, and it boots Debian off virtio block drives just >> fine. >> >> Granted, it looks like debian packaging strips the s390 firmware file, >> and doesn't rebuild it. Maybe that should simply be fixed and that's >> it? > Right, including the firmware file would be the proper way to enable > QEMU for booting on s390. If I understand it correctly, this is now obsoleted by the fact that qemu dropped s390-virtio and runs with their own s390-ccw rom now that's built from the qemu source. Is that correct? Can we close the s390-tools bug at least? And I suppose arrange for s390-ccw.rom to be shipped from the qemu package? Kind regards and thanks Philipp Kern signature.asc Description: OpenPGP digital signature
Re: Problems/Bugs installing via CD and qemu on native hw
On 11/03/2017 10:30 AM, Benjamin Jakob Zimmermann wrote:
> I get stalled installing a new VM via qemu with missing files
> (/bin/hw-detect and /bin/check-missing-firmware) and missing kernel ('No
> installable kernel found').
>
> I work around the first issue by switching to a bash terminal and
> creating dummy files with exit code 0:
> $ echo -e '#!/bin/sh\nexit 0' > /bin/hw-detect
> $ chmod +x /bin/hw-detect
> $ cp /bin/hw-detect /bin/check-missing-firmware
> Then continue with installation before running into the aforementioned
> kernel issue.
>
> I got a more complete log on this.
Please file a bug against debian-installer (reportbug has a template)
and attach the installer's syslog (or optimally all of /var/log/installer).
Kind regards and thanks
Philipp Kern
signature.asc
Description: OpenPGP digital signature
