Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
I realize that you've moved on to version 1.25.0-1 (and beyond), but for what it's worth, I thought you might like to know that I added -fno-delete-null-pointer-checks to CFLAGS in zipl/boot/Makefile and recompiled the package (1.24.1-1) with gcc 4.9 and it now works fine. The only problem with adding this option to the Makefile is that the compiler will choke on it if the compiler version is too old to recognize the option. And I agree with Bastian. -fno-delete-null-pointer-checks should be assumed by default in gcc if -ffreestanding is in effect, unless -fdelete-null-pointer-checks is explicitly specified. Null pointer dereferences are perfectly valid when referring to data in real page 0. I don't know about other machine architectures, but on s390/s390x, such references are sometimes necessary. The case in point was a valid null pointer dereference to examine the external interruption code. I do worry, though, about this being a more general problem. What about the interrupt handler in the Linux kernel? Or any other portion of the kernel that needs to examine (or change) data in real page 0 for whatever reason? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Fri, 22 Aug 2014 08:02:42 -0400 (EDT), Michael Holzheu wrote:
You can get a disassembly for the eckd boot loader code when you go
to s390-tools/zipl/boot and:
1) make
2) objdump -S eckd2.exec eckd2.list
...
static inline int wait(void)
{
do {
load_wait_psw(0x010200018000ULL,
S390_lowcore.external_new_psw);
33d0: e3 20 d0 00 00 04 lg %r2,0(%r13)
33d6: a7 39 01 b0 lghi%r3,432
33da: c0 e5 ff ff fc f7 brasl %r14,2dc8 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
-
Obviously bad code. Something is terribly wrong here. The complete eckd2.list
file is available for download at
http://users.wowway.com/~zlinuxman/zipl/eckd2.list
It was compiled with gcc version 4.9.1 (Debian 4.9.1-4) on a Debian jessie
system.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
Here are the last few instructions prior to the failure on the failing version, thanks to the CP TRACE facility under z/VM on a real IBM z/890: 2A78 STG E310F0A80024 FEB0 CC 2 2A7E LG E320300401B0 CC 2 2A84 LG E3103008000401B8 CC 2 2A8A STG E3403024 01B0 CC 2 2A90 LA 4140F0A0 = FEA8 CC 2 2A94 LARLC05BCC 2 2A9A STG E35040080024 FEB0 CC 2 2AA0 STG E35030080024 01B8 CC 2 2AA6 LPSWE B2B2F0A0FEA8 CC 0 2AAA LMG EBDFF0B4 CC 0 2AB0 STG E3203024 01B0 CC 0 2AB6 STG E31030080024 01B8 CC 0 2ABC BR 07FE - 32E6 CC 0 - 32E6 LH 481000860086 CC 0 32EA BRU A7F40001 - 32EC CC 0 - 32EC 0001 *** 32EC PROG0001 - 39A8 And here is what appears to be the equivalent code on the working version, compiled under wheezy: 2A38 STG E310F0A80024 FEA0 CC 2 2A3E LG E320300401B0 CC 2 2A44 LG E3103008000401B8 CC 2 2A4A STG E3403024 01B0 CC 2 2A50 LA 4140F0A0 = FE98 CC 2 2A54 LARLC05BCC 2 2A5A STG E35040080024 FEA0 CC 2 2A60 STG E35030080024 01B8 CC 2 2A66 LPSWE B2B2F0A0FE98 CC 0 2A6A LMG EBDFF0B4 CC 0 2A70 STG E3203024 01B0 CC 0 2A76 STG E31030080024 01B8 CC 0 2A7C BR 07FE - 32C0 CC 0 - 32C0 LLGHE310008600910086 CC 0 32C6 CHI A71E1004CC 2 32CA BRZ A784000A32DE CC 2 ... And on we go from there. The BRU instruction in the first sequence is clearly bad. In assembler language format, the equivalent instruction would be BRU *+2. This is a bad branch. The instruction branches into the middle of itself, picking up 0001 as the next machine instruction, which causes an operation exception. Since the failing instruction starts at storage address 32EC, and is two bytes long, that means that the updated instruction address in the PSW at the time of the program interruption will be 32EE, which is the value used in the disabled wait PSW. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Fri, 15 Aug 2014 19:12:24 -0400 (EDT), Stephen Powell wrote: The full PSW is as follows: 0002 8000 32EE By the way, Hercules has an instruction tracing facility, similar to the CP TRACE command on z/VM. The T command, along with the T+ and T- commands, are documented in the Hercules User Reference Guide, available as a pdf file from http://hercdoc.glanzmann.org Scroll down to the section for the manuals for version 3.07, which is the version which is currently packaged for Debian. And, by the way, the current main Hercules web site is http://www.hercules-390.eu The 3.07 documentation which ships with the current hercules package in Debian points to the old web site, which is no longer valid. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Fri, 15 Aug 2014 17:24:30 -0400 (EDT), Philipp Kern wrote: ... Do you happen to have the PSW handy? The full PSW is as follows: 0002 8000 32EE It looks like the wait bit is set, 31-bit addressing mode is set, I/O, External, and Machine check interruptions are all disabled, and the instruction address (i.e. disabled wait state code) is set to X'32EE'. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
Package: s390-tools Version: 1.24.1-1 Severity: critical Justification: The entire system is unbootable After installing s390-tools version 1.24.1-1 and re-running zipl, a reboot of the system causes a disabled wait PSW to be loaded during boot, with a wait state code of X'32EE', prior to the zipl menu being written out. The system is unbootable. This may be related to the general brokenness of C on s390x in jessie/sid. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758115: Disabled wait state X'32EE' on IPL of zIPL
On Thu, 14 Aug 2014 10:32:42 -0400 (EDT), Philipp Kern wrote: Hrm. Odd. It shouldn't be because the brokeness relates to the C library, not to the C compiler itself and zipl does not use the C library. Again, we must distinguish between zipl, the Linux command which runs at a Linux shell prompt, and zIPL, the boot loader proper, a customized version of which is written out by zipl when zipl gets run. zipl, the command which runs at a Linux shell prompt, most certainly does use the C library. It is written in C, it is compiled by the C compiler, and, at execution time, it uses the C run-time library, just like any other C program. zIPL, which is written out by zipl, does not use the C library. Or does it? Well, not the regular C library, no. But it does use a minimalist run-time library. In the source package, look at zipl/boot/libc.c. Yes, even zIPL, the boot loader proper, does use a C library of sorts. That being said, I had to recompile s390-tools on sid, Therein lies the problem. and I do not run sid due to the C breakage. You should. You may not be able to directly install jessie or sid, but you can install wheezy and then do an upgrade to jessie or sid. Of course, you will likely experience problems during the upgrade, as I did, most likely with the upgrade of package perl-base. But there are posts to debian-s390 by me that explain how I worked around it. If you had a sid system to test with, you would have realized that this package is unusable and you never would have uploaded it. It worked before the recompilation, hence there might be a change in sid vs. wheezy that caused this. Oh, absolutely. I downloaded the new source package, built it on a wheezy system, transferred the binary package to my jessie system, installed the binary package on my jessie system, ran zipl, shutdown my system, and IPLed. It IPLed just fine. I then took the exact same source package, compiled it on a jessie system, installed the binary package, ran zipl, shutdown, and IPLed. Kaboom! disabled wait state code X'32EE'. The C compiler and run-time library used is the only difference. I think I've proven pretty conclusively that this is C breakage causing this problem. You are talking about Hercules, right? It doesn't matter. I get the exact same results on Hercules as I do on a real mainframe, and vice versa. I have found Hercules to be a deadly accurate emulation of real mainframe hardware, when properly configured. In my opinion, everyone who maintains a package which is mainframe-specific, such as s390-tools, and anyone responsible, in whole or in part, for the s390x port needs their own mainframe system that they can play around with in a totally unrestricted manner, without fear of messing someone else up. And if you don't have access to a real mainframe, a Hercules emulation of one is the next best thing. It's slower than a real mainframe; but architecturally, it is virtually indistinguishable from a real mainframe to the software. And that's what an emulator is all about, right? You need a jessie/sid system to play around with. I must say that the C breakage on s390x is the biggest mess that I have ever seen, and in the case of this package, has produced the worst error yet: a totally unbootable system. By the way, when version 1.17.1 of the package is compiled on a jessie system, it runs fine. To me, the most significant difference between the two packages is that the zIPL portion of the 1.17.1 package, the boot loader proper, is all written in assembly language (zipl/boot/sclp.S, zipl/boot/menu.S, etc.), whereas the zIPL portion of the 1.24.1 package has been rewritten in C (zipl/boot/sclp.c, zipl/boot/menu.c, etc.). Since it's written in C, it needs that minimalist C run-time library (zipl/boot/libc.c), which the 1.17.1 version doesn't need. Yes, this bug has C breakage written all over it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753444: interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d0000]
Bug number 753592 was merged into bug number 753444. Bug number 753444 was then marked as fixed in perl-base version 5.18.2-6. At the time of this writing, this version is now in testing (jessie). So one would think it would be safe now to upgrade one's system, right? Well, yes and no. It can be done, but not in the standard way. If you use apt-get update apt-get upgrade The upgrade will fail. The problem is a trigger in perl-base for man-db. Configuring man-db requires hidden dependencies on other packages which are not yet installed. Here's how I managed to break the deadlock. First of all, I had previously put perl, perl-base, and perl-modules on hold at the 5.18.2-4 level with echo perl hold | dpkg --set-selections echo perl-base hold | dpkg --set-selections echo perl-modules hold | dpkg --set-selections So the first step was to remove the holds with echo perl install | dpkg --set-selections echo perl-base install | dpkg --set-selections echo perl-modules install | dpkg --set-selections Of course, it should go without saying that you have to be root to do all of this. But I'll say it anyway for good measure. Now change your current directory to a directory without any *.deb files in it and proceed as follows: apt-get update apt-get download perl perl-base perl-modules libgdbm3 \ liblocale-gettext-perl libtext-charwidth-perl libtext-iconv-perl dpkg -i perl-base_*.deb Unpacking and configuring of perl-base will succeed, but the trigger for configuring man-db will fail. This leaves perl-base with a dpkg status of ii and man-db with a dpkg status of iF. You can check this with dpkg-query -l perl-base dpkg-query -l man-db if you want. Keep going as follows: dpkg -i perl-modules_*.deb dpkg -i libgdbm3_*.deb dpkg -i perl_*.deb dpkg -i liblocale-gettext-perl_*.deb dpkg -i libtext-charwidth-perl_*.deb dpkg -i libtext-iconv-perl_*.deb Now you have the prerequisites installed to configure man-db dpkg --configure man-db Now check the status of man-db again. dpkg-query -l man-db Now it shows up with a status of ii, which is what you want. Now do some cleanup ... rm *.deb apt-get check If apt-get check gives errors, then use apt-get -f install to fix it. Once this is done, proceed to upgrade the rest of your database. apt-get upgrade apt-get clean apt-get --purge dist-upgrade apt-get clean apt-get --purge autoremove aptitude forget-new aptitude keep-all I hope this helps someone. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753592: interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d0000]
Package: perl-base Version: 5.18.2-4+b1 Severity: grave X-Debbugs-CC: debian-s...@lists.debian.org Justification: essential package broken, affects other packages, prevents system upgrade. For now, this bug appears to affect only the s390x architecture of Debian testing (jessie), since all other architectures still use version 5.18.2-4. While performing an apt-get --purge dist-upgrade on my s390x jessie system, I encountered errors such as this immediately after perl-base was unpacked: - Use of uninitialized value $ARGV[0] in string eq at /usr/share/debconf/frontend line 17. Use of uninitialized value $ARGV[0] in pattern match (m//) at /usr/share/debconf/frontend line 24. Use of uninitialized value $ARGV[0] in concatenation (.) or string at /usr/share/debconf/frontend line 60. Use of uninitialized value $ARGV[0] in pattern match (m//) at /usr/share/debconf/frontend line 61. Use of uninitialized value $ARGV[0] in pattern match (m//) at /usr/share/debconf/frontend line 62. Use of uninitialized value $ARGV[0] in pattern match (m//) at /usr/share/debconf/frontend line 72. Use of uninitialized value $r in HANDLE at /usr/share/perl5/Debconf/ConfModule.pm line 72. readline() on unopened filehandle at /usr/share/perl5/Debconf/ConfModule.pm line 72. - These error messages occurred on the user terminal session. On the system console, errors such as these were encountered: - User process fault: interruption code 0x4003B in libperl.so.5.18.2[3fffcfff000+1d] failing address: 0 - This prevented a successful upgrade, as all packages which are configured through debconf failed their configuration. According to the changelog, there are no source changes between 5.18.2-4 and 5.18.2-4+b1, only a recompile against a newer C library. Either something went wrong with the package build, or the new C library has exposed a previously-hidden bug. Version 5.20.0-1 from experimental solves the problem, but breaks other packages, such as libhtml-parser-perl, liblocale-gettext-perl, etc., which now have unmet dependencies. No newer versions of these packages are available. Therefore, I have had to downgrade perl-base from version 5.18.2-4+b1 to 5.18.2-4 and put the package on hold. I also downgraded perl to version 5.18.2-4 and put it on hold. perl-modules is still at 5.18.2-4, but I put it on hold too, for good measure. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600100: zipl's postinst hook fails upon initial kernel installation by d-i
On Wed, 13 Oct 2010 13:31:26 -0400 (EDT), Philipp Kern wrote: The initial kernel installation through d-i fails with the current squeeze d-i due to zipl's postinst failing. It obviously doesn't have a configuration file yet, because it will be configured in the step after kernel installation: I am not a package maintainer for s390-tools; I am a user who is an interested party to this bug report. This bug is related to bug number 599931, and the hook script templates provided in the body of bug report 599931 will fix both that problem and this one. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594127: Fix for bug number 590028 is incomplete
Package: s390-tools Version: 1.8.3-2 Severity: serious s390-tools version 1.8.3-2 was recently migrated to testing, and it contained a fix for Debian bug report 590028. However, this fix is incomplete, for two reasons: (1) the hook scripts provided, /etc/kernel/postinst.d/zz-zipl and /etc/kernel/postrm.d/zz-zipl, do not maintain the symbolic links. The zipl boot loader typically uses the historic symbolic links (/boot/vmlinuz, /boot/initrd.img, /boot/vmlinuz.old, and /boot/initrd.img.old) in its configuration file (/etc/zipl.conf) so that the configuration file does not need to be updated with each kernel install or remove, as grub-legacy's configuration file does (/boot/grub/menu.lst). The advantage of using the symbolic links is that the configuration file never needs to be maintained when a kernel is installed or removed. The disadvantage of this method is that the symbolic links themselves must be maintained when a kernel image is installed or removed. Historically, the maintainer scripts for the kernel image package, whether they are for a stock kernel or a custom kernel created by make-kpkg, maintained the symbolic links, subject to configuration statements in /etc/kernel-img.conf, such as do_symlinks, relative_links, and link_in_boot. The maintainer scripts for stock kernel images still support this, as far as I know. However, the maintainer scripts for kernel image packages created by newer releases of make-kpkg, as well as the maintainer scripts for kernel image packages created by make deb-pkg (from 2.6.31 kernel source packages and later) do not contain logic to maintain the symbolic links. For boot loaders which rely on symbolic links, such as zipl and lilo typically do, the boot loader hook scripts must maintain the symbolic links. (The alternative, of course, is for the boot loader hook scripts to maintain the boot loader configuration file directly, /etc/zipl.conf in this case, so that symbolic links are not needed.) (2) The second reason that this fix is incomplete is that the package does not contain an initramfs hook script. The latest version of initramfs-tools, 0.98, now expects boot loaders which rely on a list of blocks saved at boot loader map installer time, such as lilo and zipl, to provide a hook script in /etc/initramfs/post-update.d to react to update-initramfs -u This script does not use the zz- prefix, nor does it need to maintain symbolic links, but it does need to re-run the boot loader, redirecting standard output to standard error as the kernel hook scripts do. I one again encourage you to look at the following generic scripts which I have been using for months quite satisfactorily. I believe that they can be made zipl-specific without much effort: http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader (for installation in /etc/kernel/postinst.d) http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader (for installation in /etc/kernel/postrm.d) http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader (for installation in /etc/initramfs/post-update.d) -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553481: 3270-common: dependency problem
On Sat, 07 Aug 2010 11:02:21 -0400 (EDT), Moritz Muehlenhoff wrote: On Tue, Jul 27, 2010 at 09:11:16AM -0400, Stephen Powell wrote: Hello, Bastian. Sorry to bother you. I reopened this bug log because it appears to be installable only on the amd64 architecture. I tried to install it today on the i386 architecture and it failed with the original symptoms. I have subscribed to this bug log; so there's no need to CC me. non-free is no longer autobuilt. I hadn't heard that, but from searching the archives it appears that this has been the case at least as far back as 2002; so I don't think that's the problem. If I understand what's going on here, the problem is that 3270-common has a dependency on libicu40 for all architectures *except* amd64. For amd64, it has a dependency on libicu42 instead. Both of these packages are free. The problem is that libicu40 exists only in unstable and only for the m68k architecture. I think all that needs to be done is to change the dependencies of the package to depend on libicu42 for all architectures, not just for amd64, and to eliminate the dependency on libicu40. Since the popcon is quite low anyway, I'm not sure how useful popcon statistics are in general, but for a package like this they are almost useless. Corporate users of Debian almost always disable popcon for security reasons. popcon statistics are generally from individual home users who have elected to enable popcon, and they generally don't need a 3270 emulator. (Do you have a mainframe in your home?) It is mainly corporate users who need a 3270 emulator, and their desktops almost universally have popcon disabled. we could limit the availability to handbuilt versions for amd64 and i386 In the first place, I don't see the need for that, and in the second place, I use this in the s390 architecture as well. Surely there must be a way to cross-build a package for another architecture. If there isn't, I can at least build an i386 and an s390 package for you from source, but I can't sign them, since I am not a DD or a DM. and file removal bugs for the outdated binaries from Lenny. That would not be good. Currently, installing back-level versions from Lenny is my only circumvention. Just make 3270-common depend on libicu42 for all architectures and remove the dependency on libicu40. That's not hard, is it? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553481: 3270-common: dependency problem
On Mon, 09 Aug 2010 13:37:45 -0400 (EDT), Adam D. Barratt wrote: On Mon, 2010-08-09 at 11:10 -0400, Stephen Powell wrote: On Sat, 07 Aug 2010 11:02:21 -0400 (EDT), Moritz Muehlenhoff wrote: non-free is no longer autobuilt. I hadn't heard that, but from searching the archives it appears that this has been the case at least as far back as 2002; so I don't think that's the problem. No. There was non-free autobuilding on unofficial hosts until some time last year. Since then, there has been some work on integrating it in to the official buildd architecture; that functionality is currently disabled due to it trying to build packages that weren't whitelisted. ibm-3270 doesn't appear to have been built for some time before that, however and isn't on the whitelist. OK. If I understand what's going on here, the problem is that 3270-common has a dependency on libicu40 for all architectures *except* amd64. For amd64, it has a dependency on libicu42 instead. Both of these packages are free. The problem is that libicu40 exists only in unstable and only for the m68k architecture. I think all that needs to be done is to change the dependencies of the package to depend on libicu42 for all architectures, not just for amd64, and to eliminate the dependency on libicu40. The dependencies are generated during the package build process. The source package doesn't say depend on libicu40, it says install libicu-dev during the build and the correct runtime dependency is then generated. It looks like you're right about that. I just downloaded the Squeeze version of the source code and built a binary package from it for i386. dpkg-deb -I reports that the package has a dependency on libicu42. And it installs and runs correctly. So it looks like Morris had the right idea. The binary packages have not been built in a while. And that's the cause of the problem. The amd64 packages in unstable do not depend on libicu at all, which is ideal. Rebuilding to depend on libicu42 would not help - that no longer exists in unstable, due to the ongoing icu transition which we need to finish in the very near future. OK. ... Surely there must be a way to cross-build a package for another architecture. If there isn't, I can at least build an i386 and an s390 package for you from source, but I can't sign them, since I am not a DD or a DM. Cross-built packages aren't suitable for the archive. ... Even if the package is suitable for hand-building on all of the architectures which would be required, this would still require someone with the time and will to do so, and there aren't porter boxes available for all architectures. ... The available options right now are: 1) ibm-3270 gets removed from squeeze 2) Someone hand-builds and uploads the unstable packages on !amd64, filing removal requests for any remaining architectures. The new packages could then migrate to squeeze. 3) The icu transition gets pushed in to squeeze a) leaving the packages in squeeze broken and breaking the squeeze/amd64 packages in the process (as libicu42 will no longer exist). b) and ibm-3270 from unstable gets pushed in at the same time, allowing amd64 to stay installable but leaving other architectures broken. Even if we do 3, the problem will still need fixing before release. I'm afraid you've lost me on this one. Pardon my denseness and my ignorance of what other things are going on in the Debian project that I either don't know about or don't understand, or both. As my experiments have shown, the current Squeeze source package builds and installs just fine on Squeeze. It just has to be built. It seems to me that something needs to be done to get these packages to autobuild again somehow. What needs to be done to make that happen? Whitelist the package? (whatever that means) Whitelist the package plus re-enabling the disabled functionality (with checks for whitelisted packages)? Why is this the wrong approach? From what you've told me, that seems to be the way to go. Am I missing something? As for Sid, if there is no dependency on libicu at all, then they do not depend on libicu for any architecture, right? And the fact that libicu does not exist in Sid is no problem. Again, the packages just have to be built. It seems to me that the solution is to find some way to get the packages to autobuild again, as was done in the past. It seems to me that that will solve all the problems. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553481: 3270-common: dependency problem
On Mon, 09 Aug 2010 15:49:14 -0400 (EDT), Adam D. Barratt wrote: On Mon, 2010-08-09 at 14:54 -0400, Stephen Powell wrote: It seems to me that something needs to be done to get these packages to autobuild again somehow. What needs to be done to make that happen? Whitelist the package? (whatever that means) Some non-free packages we can auto-build on Debian hardware; in some cases, the licence means we can't. The default assumption is (and has to be) that we can't. Understood. It's been a few years since I looked at the license for this package, but I don't think it will be a problem for ibm-3270. In Etch, this package was classified as free. It was downgraded to non-free by some legal person on some technical grounds. But I don't think there's anything in the license(s) that would prohibit Debian from compiling or distributing it. I am aware, for example, that some software has historically required those who distribute it to refrain from distributing competing software. I believe that Sun Java has, or used to have, such restrictions. That's why the Debian package for Sun Java downloads code during installation directly from the Sun site. There's no provision like that in the license for ibm-3270. Whitelist the package plus re-enabling the disabled functionality (with checks for whitelisted packages)? Why is this the wrong approach? It's not. But it needs someone to work on fixing the non-free autobuilding setup to ensure that aren't any windows where it can build packages which haven't been whitelisted. So the default status has to be blacklisted, and then some legal person has to come along and certify a package as whitelisted. Sounds like work for lawyers. I'm not one of them. From what you've told me, that seems to be the way to go. Am I missing something? As for Sid, if there is no dependency on libicu at all, then they do not depend on libicu for any architecture, right? And the fact that libicu does not exist in Sid is no problem. Again, the packages just have to be built. It seems to me that the solution is to find some way to get the packages to autobuild again, as was done in the past. It seems to me that that will solve all the problems. Yep, that would solve all the problems. It's just not as small a just as you appear to be suggesting. :-) I see. OK, well I have a work-around for now (download the source package and build the binaries myself). And I can live with that for now until the autobuild problem gets fixed. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#553481: 3270-common: dependency problem
Hello, Bastian. Sorry to bother you. I reopened this bug log because it appears to be installable only on the amd64 architecture. I tried to install it today on the i386 architecture and it failed with the original symptoms. I have subscribed to this bug log; so there's no need to CC me. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590022: hook scripts for boot loaders
To the Debian package maintainers for lilo and zipl (s390-tools): You may wish to write your own scripts for this purpose; but if they will be of any use, I am offering three hook scripts that I wrote and have been using in production for some time that meet the requirements of the new policy. These hook scripts are generalized to work with a number of boot loaders, but they can be easily renamed and tailored to be specific to your boot loader: Kernel postinst hook: http://www.wowway.com/~zlinuxman/kernel/postinst.d/zz-bootloader Kernel postrm hook: http://www.wowway.com/~zlinuxman/kernel/postrm.d/zz-bootloader initramfs hook: http://www.wowway.com/~zlinuxman/initramfs/post-update.d/bootloader If they are of any use to you, help yourself. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585856: Doesn't boot with large initramfs
Guido, Bug number 505609 has been closed by the kernel team. However, the kernel team is only going to fix the problem for Lenny. To fix the problem in Squeeze and later releases will require that a hook script of some kind be added to the lilo package. The problem is that lilo didn't get run during the kernel upgrade, as it should have been, due to changes in the kernel maintainer scripts which, for Squeeze and later releases, the kernel team regards as a feature and not a bug. Their position is that lilo needs to provide a hook script to make sure lilo gets run during a kernel upgrade. This bug report will remain open until a lilo package with a suitable hook script gets uploaded. In the mean time, here's one way to work around it. (Do this as root.) (1) Make sure that large-memory is specified in /etc/lilo.conf. (2) Create a file called /usr/sbin/lilo-update. It should look like this: #!/bin/sh # This file is referenced by /etc/kernel-img.conf. lilo -v 2 (3) Mark the file executable, like this: chmod +x /usr/sbin/lilo-update (4) Edit the file /etc/kernel-img.conf. Make sure that do_bootloader = yes is specified in this file (for the sake of update-initramfs -u), then add postinst_hook = lilo-update postrm_hook = lilo-update This will cause lilo to get run when a stock kernel image is installed or upgraded. If you are going to use a custom kernel, such as one created by make-kpkg or make deb-pkg, then this is not adequate. I recommend that you read my unofficial kernel building web page, http://www.wowway.com/~zlinuxman/Kernel.htm, for more complete information on how to make sure that lilo gets run (as well as other necessary stuff) when using a custom kernel. If you have any further questions about this lilo problem, please post to this bug log (585856). -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: loader varialbe in kernel maintainer scripts
On Fri, 18 Jun 2010 04:25:38 -0400 (EDT), Joachim Wiedorn wrote: Ben Hutchings b...@decadent.org.uk wrote on 2010-06-18 02:02: On Thu, 2010-06-17 at 20:37 -0400, Stephen Powell wrote: And how would one go about setting this loader variable? The loader variable is not documented in the man page for /etc/kernel-img.conf in Lenny, which appears to be the closest thing there is to documentation for the variables supported by official Debian stock kernel images. Nevertheless, at your suggestion, I tried putting loader = lilo in /etc/kernel-img.conf. (do_bootloader = yes was also set.) Then I issued dpkg-reconfigure linux-image-2.6.26-2-686 There was no evidence from the output that lilo was run. [...] I'm sorry, you're right. Most of the other variables at the top of the postinst script can be overridden by /etc/kernel-img.conf, but not this one. Given that, I think you are right that the 'historical' bootloader setting should be restored in an update to lenny. Now I am a little confused. How is the recommended procedure for using the LILO bootloader within squeeze/sid? How I understand the normal installation of lilo package have the result, that lilo doesn't be started after an kernel update (and also after update of initramfs-tools?). What must I config on my squeeze machine that lilo bootloader will be automatically updated after kernel update? So far, Ben has only agreed to reinstate the historic function of do_bootloader = yes in /etc/kernel-img.conf for Lenny kernel maintainer scripts. It hasn't actually happened yet, but he has agreed to restore its former function in Lenny as it was in Etch and previous releases. I am trying to persuade him to restore its function in Squeeze too. Whether or not I am successful remains to be seen. In the mean time, for lilo users of Squeeze/Sid who use *only* official stock Debian kernels, I recommend that they use the hook script described in an earlier post to this bug log in conjunction with other appropriate settings in /etc/kernel-img.conf. For lilo users of Squeeze/Sid who use custom kernels created by make-kpkg, I recommend that they use the hook scripts provided on my unofficial kernel building web page, http://www.wowway.com/~zlinuxman/Kernel.htm, under Step 10: Customize the Kernel Installation Environment. I must add that this recommendation is my own and not official Debian advice. I have never used the upstream-provided make deb-pkg way of building a custom kernel; so I don't have any hook scripts pre-made for that purpose. There doesn't seem to be a one size fits all solution at this point. If Ben agrees to reinstate the historic function of do_bootloader = yes for Squeeze, then there will be a one size fits all solution for lilo users, at least as it pertains to stock kernels. Users of custom kernels are on their own. They need to figure out what hook scripts they need and how to customize and configure them. And if they don't do it right, you may be sure that they will blame lilo! (That's one of the reasons why I think it would be a good idea for lilo to implement a check sum method of figuring out if something changed in the kernel image or initial RAM file system image without lilo being re-run. But I digress.) As for update-initramfs -u, it *will* invoke lilo if lilo is installed and do_bootloader = yes is specified in /etc/kernel-img.conf, which I highly recommend. There are types of upgrades which do not affect the kernel itself but which do require that the initial RAM file system be re-built. And for lilo users, it is essential that lilo be run after any changes are made to the initial RAM file system. update-initramfs -c and update-initramfs -d, however, will *not* invoke lilo, even if do_bootloader = yes is specified in /etc/kernel-img.conf. HTH -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: loader varialbe in kernel maintainer scripts
On Fri, 18 Jun 2010 11:51:11 -0400 (EDT), maximilian attems wrote: On Fri, Jun 18, 2010 at 10:55:35AM -0400, Stephen Powell wrote: As for update-initramfs -u, it *will* invoke lilo if lilo is installed and do_bootloader = yes is specified in /etc/kernel-img.conf, which I highly recommend. this fall back will be gone as soon as squeeze is out. so you'd really need to gear up. That is interesting. Suppose that the user issues an aptitude update aptitude full-upgrade sequence. And suppose something other than the kernel gets updated that requires that the initial RAM file system be updated. Somehow, aptitude knows to run update-initramfs -u. But if update-initramfs -u does not invoke lilo, and the kernel is not updated, what will cause lilo to get run? The kernel hook scripts won't be run because the kernel itself was not updated. The same principle applies to zipl on the s390 platform, which is the *only* supported boot loader on this platform, by the way. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Tue, 15 Jun 2010 23:25:45 -0400 (EDT), Ben Hutchings wrote: On Tue, 2010-06-08 at 09:43 -0400, Stephen Powell wrote: do_bootloader = yes in /etc/kernel-img.conf means run the historic boot loader for this platform. For the i386 platform (and amd64) the historic boot loader is lilo. For the s390 platform, that boot loader is zipl. The kernel maintainer scripts for the s390 platform still specify zipl as the boot loader my $loader= zipl; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo so that do_bootloader = yes in /etc/kernel-img.conf will work. The kernel maintainer scripts for i386 and amd64 for Lenny and beyond specify a null string. That is inconsistent. It should specify my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo for consistency between platforms. [...] This code and the file /etc/kernel-img.conf are vestiges of kernel-package which are gradually being removed from the official kernel packages. Therefore I don't think we should reinstate this idea of the default loader but we should change the code so that it doesn't silently fail if do_loader is set and loader is not. Well, I agree that the maintainer script should not silently fail. But removing support for the historic boot loader actually makes the official stock Debian kernel image package maintainer scripts *more* like kernel-package, not less. To be more precise, it makes them more like the *Squeeze* version of kernel-package. The maintainer scripts which get packaged with a kernel image package created by make-kpkg under Squeeze and later releases no longer perform *any* post installation activities. They do not create an initial RAM file system (even if the --initrd option was specified on the make-kpkg command line), they do not maintain symbolic links (even if do_symlinks = yes is specified in /etc/kernel-img.conf), and they do not run the historic boot loader (even if do_bootloader = yes is specified in /etc/kernel-img.conf). If you want any of these things done, then either the user or an installed package must provide hook scripts to accomplish this. The maintainer scripts packaged with kernel image packages created by make-kpkg under Lenny and previous releases still do all these things. I can maybe accept your proposal for Squeeze. But for Lenny, I believe that the maintainer scripts should be changed back they way they were. In other words, my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo should be set in the maintainer scripts. After all, Lenny does not have the generalized hook script environment that Squeeze does. I believe that this bug is severe enough to warrant inclusion of the fix in stable-proposed-updates. All packages that need to react to kernel installation or removal should install appropriate hook scripts in the directories under /etc/kernel instead of relying on specific support in the kernel maintainer scripts. Again, I can maybe accept that argument for Squeeze, but not for Lenny. However, to be consistent, if you're going to leave my $loader set to the null string in i386 and amd64 kernel maintainer scripts, you should also set it to the null string for s390 kernel maintainer scripts. This will affect the s390-tools package, which includes the zipl boot loader for the s390 platform; so I'm copying them in on this. If your proposed solution goes through, they will need to create some kind of hook script too, or at least document the need for one. And so will lilo. And when we're all done, that leaves us with one foot in the old way of doing things and one foot in the new way of doing things. The initial RAM file system will still be created automatically, symlinks will still be maintained (if requested in /etc/kernel-img.conf), but the historic boot loader will not be run. I would rather see the the stock kernel maintainer scripts do none of the above, like the new kernel-package, or all of the above, like the historic stock kernel maintainer scripts. And this is pretty late in the Squeeze development cycle to start making design changes. We're getting pretty close to a freeze, are we not? It sure seems to me like a one-line change in the kernel maintainer scripts is a much faster and much simpler fix, not to mention more consistent. The maintainer scripts' support for the historic boot loader should be retained, in my opinion, at least for Squeeze. Then, if you want to change the design of how kernel maintainer scripts work, that can be done in Squeeze+1. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: loader varialbe in kernel maintainer scripts
On Thu, 17 Jun 2010 18:11:04 -0400 (EDT), Ben Hutchings wrote: On Thu, Jun 17, 2010 at 12:33:58PM -0400, Stephen Powell wrote: [...] I can maybe accept your proposal for Squeeze. But for Lenny, I believe that the maintainer scripts should be changed back they way they were. In other words, my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot, or delo should be set in the maintainer scripts. After all, Lenny does not have the generalized hook script environment that Squeeze does. But it does allow users to configure the loader to be run, using either the 'loader' or 'postinst_hook' variable. And how would one go about setting this loader variable? The loader variable is not documented in the man page for /etc/kernel-img.conf in Lenny, which appears to be the closest thing there is to documentation for the variables supported by official Debian stock kernel images. Nevertheless, at your suggestion, I tried putting loader = lilo in /etc/kernel-img.conf. (do_bootloader = yes was also set.) Then I issued dpkg-reconfigure linux-image-2.6.26-2-686 There was no evidence from the output that lilo was run. As for the postinst_hook and postrm_hook variables, they do work, but one can't simply specify postinst_hook = lilo postrm_hook = lilo in /etc/kernel-img.conf. That won't work because lilo doesn't like the parameters passed to it. It is necessary to create a wrapper script around lilo that strips off the parameters passed to it and redirects standard output to standard error. For example, on my unofficial kernel building web page, I recommend that lilo users create a hook script called /usr/sbin/lilo-update that looks like this: #!/bin/sh # The purpose of this script is to strip off any # arguments passed and simply invoke lilo, redirecting # standard output to standard error. It is intended # to be referenced by /etc/kernel-img.conf in the # postinst_hook and postrm_hook variables. # lilo 2 Then mark it executable with chmod +x /usr/sbin/lilo-update Then edit /etc/kernel-img.conf and specify postinst_hook = lilo-update postrm_hook = lilo-update That is how I have been recommending that users circumvent this bug (or feature, depending on your point of view). I believe that this bug is severe enough to warrant inclusion of the fix in stable-proposed-updates. The fact that the historical bootloader is not automatically run is not a bug; it is an intentional change. Only the silent failure is a bug. Preventing the historic boot loader from being run could have been accomplished by simply setting do_bootloader = no in /etc/kernel-img.conf. By setting my $loader to the null string, you made it *impossible* for the user to request that the historic boot loader be run. But OK, if you say it's a feature, not a bug, then I'll have to accept that. I must say I'm disappointed though. However, to be consistent, if you're going to leave my $loader set to the null string in i386 and amd64 kernel maintainer scripts, you should also set it to the null string for s390 kernel maintainer scripts. Yes. I think that's probably a reasonable change for squeeze. I was trying to use that argument to convince you to change it back for i386 and amd64, not to convince you to break it for s390! Oh well. Now it appears that s390 users will be able to look forward to this feature also. [...] The maintainer scripts' support for the historic boot loader should be retained, in my opinion, at least for Squeeze. Then, if you want to change the design of how kernel maintainer scripts work, that can be done in Squeeze+1. It cannot be 'retained' because it is not there at present. Nor will it be reinstated. OK, if you're determined not to set my $loader to the name of the historic boot loader, then please do make a change similar to the one you proposed so that it will tell the user to manually run the boot loader. Then close this bug report. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: loader varialbe in kernel maintainer scripts
On Thu, 17 Jun 2010 21:02:54 -0400 (EDT), Ben Hutchings wrote: I'm sorry, you're right. Most of the other variables at the top of the postinst script can be overridden by /etc/kernel-img.conf, but not this one. Given that, I think you are right that the 'historical' bootloader setting should be restored in an update to lenny. Great! What about Squeeze? It still supports creating the initial RAM file system and updating symlinks via variables in /etc/kernel-img.conf. Doesn't it make sense to allow the historical boot loader code to work as well? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585856: Doesn't boot with large initramfs
Oops! I didn't notice your secondary update until after I had replied. In your secondary update you state that the large-memory option is present in your /etc/lilo.conf file. This is further evidence that this is a duplicate of bug number 505609. lilo did *not* get run after the kernel update and before the reboot. The error message Initial ramdisk loads below 4Mb; kernel overwrite is possible. indicates that lilo loaded the initial RAM file system *below* the 15M line. It would not have done that if the large-memory option had been present in /etc/lilo.conf at the time that lilo's map installer was last run. If it had been, it would have loaded the initial RAM file system above the 16M line and the above error message would not have been issued. Exactly when did you add the large-memory option to your /etc/lilo.conf? Did you add it *before* the kernel-upgrade or *after*? If it was present *before* the kernel upgrade, then this is proof that lilo did not get run during the kernel upgrade. If it was added *after* the kernel upgrade, we still don't know for sure. But if you go back to your original initial RAM file system and manually run lilo, and everything works, then we can be sure that this is a duplicate of 505609. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#585856: Doesn't boot with large initramfs
Guido, I suspect that this bug is a duplicate of bug number 505609. The bottom line is that due to a bug in the kernel maintainer scripts, lilo does not get re-run after a kernel upgrade. Re-try your original scenario after manually running lilo. If necessary, add the large-memory option to /etc/lilo.conf or use MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy. But chances are that manually running lilo is all you need to do. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Tue, 08 Jun 2010 07:39:58 -0400 (EDT), Vincent Danjean wrote:
On 07/06/2010 17:37, Stephen Powell wrote:
But for a kernel install or reconfigure, it is the responsibility of the
kernel maintainer scripts to invoke the bootloader. See also, for example,
linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader
on line 38. This really is an open and shut case, if only I can the kernel
people to actually look at it! Please look at it!
If I recall correctly, kernel maintainers have introduced
/etc/kernel/post{inst,rm}.d/ in order to avoid to hardcode each possible
bootloader in their script.
Can't lilo provide a script here ?
do_bootloader = yes
in /etc/kernel-img.conf means run the historic boot loader for this platform.
For the i386 platform (and amd64) the historic boot loader is lilo. For
the s390 platform, that boot loader is zipl. The kernel maintainer scripts
for the s390 platform still specify zipl as the boot loader
my $loader= zipl; # lilo, silo, quik, palo, vmelilo, nettrom,
arcboot, or delo
so that
do_bootloader = yes
in /etc/kernel-img.conf will work. The kernel maintainer scripts for i386 and
amd64
for Lenny and beyond specify a null string. That is inconsistent. It should
specify
my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom,
arcboot, or delo
for consistency between platforms. For non-historic boot loaders, the method
used is to set
do_bootloader = no
in /etc/kernel-img.conf and supply a hook script of some kind, if needed. For
example,
grub version 1 in Lenny invokes it's hook scripts via
do_bootloader = no
postinst_hook = update-grub
postrm_hook = update-grub
in /etc/kernel-img.conf. Grub version 2 does not need a hook script; so it
simply sets
do_bootloader = no
in /etc/kernel-img.conf. In Squeeze and later, there is an alternate method
for running
hook scripts (so that more than one hook script can be invoked). Simply
install the
script in /etc/kernel/preinst.d, /etc/kernel/prerm.d, /etc/kernel/postinst.d, or
/etc/kernel/postrm.d. But even in Squeeze/Sid, the historic boot loader can
still be run
by setting
do_bootloader = yes
in /etc/kernel-img.conf. That still works for zipl on the s390 platform. But
it's
been broken since Lenny on the i386 and amd64 platforms for lilo.
initramfs-tools also examines this variable and runs the historic boot loader
when
update-initramfs -u
is invoked. That still works, even on the i386 and amd64 platforms, provided
that
do_bootloader = yes
is specified in /etc/kernel-img.conf. But
update-initramfs -c
does not invoke the boot loader. Running the historic boot loader during
installation,
reconfiguration, or upgrade of a kernel is still the responsibility of the
kernel
maintainer scripts. And it cannot do so unless my $loader is set to the name
of
the historic boot loader. On s390, that variable is set properly. On i386 and
amd64,
it is not.
The kernel maintainer scripts provided by kernel image packages created by
make-kpkg
on Squeeze and later are another story. They no longer do *any*
post-installation
actions unless user-provided hook scripts cause it to happen. But the
maintainer
scripts for official stock Debian kernel images still support these historic
post-installation activities.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Mon, 07 Jun 2010 10:33:52 -0400 (EDT), Holger Levsen wrote: Hi Stephen, thanks for stepping up maintaining lilo in Debian! I hope you'll manage this well. Um, thanks; but I don't understand the reassignment of bug number 505609 to package initramfs-tools. If you read my previous posts to the bug log, it is clear that this problem started with a change to the maintainer scripts between Etch and Lenny. Please read my posts again carefully. Then consider whether this is really a bug in initramfs-tools or a bug in the kernel maintainer scripts. initramfs-tools only gets involved when update-initramfs -u is issued. And it *does* invoke the boot loader under these conditions, if do_bootloader = yes is present in /etc/kernel-img.conf and lilo is installed. But for a kernel install or reconfigure, it is the responsibility of the kernel maintainer scripts to invoke the bootloader. See also, for example, linux-image-2.6.26-2-s390.postinst, where zipl is assigned as the bootloader on line 38. This really is an open and shut case, if only I can the kernel people to actually look at it! Please look at it! -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#505609: [SOLVED] Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
After examining the maintainer scripts, this does appear to be a bug in the maintainer scripts. I compared output of dpkg-reconfigure between two different systems: one running Etch and the other running Lenny. Both had lilo installed as the boot loader. In both cases, the contents of /etc/kernel-img.conf were as follows: -- # Kernel image management overrides # See kernel-img.conf(5) for details do_symlinks = yes relative_links = yes do_bootloader = yes do_bootfloppy = no do_initrd = yes link_in_boot = yes -- Here is the output of dpkg-reconfigure on Etch: -- # dpkg-reconfigure linux-image-2.6.18-5-686 Running depmod. Finding valid ramdisk creators. Using mkinitramfs-kpkg to build the ramdisk. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-13 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.18.dfsg.1-13 was configured last, according to dpkg) You already have a LILO configuration in /etc/lilo.conf Running boot loader as requested Testing lilo.conf ... Testing successful. Installing the partition boot sector... Running /sbin/lilo ... Installation successful. # -- Here is the output of dpkg-reconfigure on Lenny: -- # dpkg-reconfigure linux-image-2.6.26-2-686 Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) # -- Notice the absence of any information about running the boot loader in the Lenny output! The boot loader simply was not run, despite a request in /etc/kernel-img.conf to run it. I compared the two relevant maintainer scripts: /var/lib/dpkg/info/linux-image.2.6.18-5-686.postinst and /var/lib/dpkg/info/linux-image.2.6.26-2-686.postinst and quickly discovered the reason. The maintainer scripts for the 2.6.26 kernel define the $loader variable to be the null string. The 2.6.18 maintainer script defines the $loader variable to be lilo. To be specific, line 38 of /var/lib/dpkg/info/linux-image-2.6.26-2-686.postinst currently says: my $loader= ; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo I changed it to say: my $loader= lilo; # lilo, silo, quik, palo, vmelilo, nettrom, arcboot or delo The new output is as follows: -- # dpkg-reconfigure linux-image-2.6.26-2-686 Running depmod. Running mkinitramfs-kpkg. Not updating initrd symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) Not updating image symbolic links since we are being updated/reinstalled (2.6.26-21lenny4 was configured last, according to dpkg) You already have a LILO configuration in /etc/lilo.conf Running boot loader as requested Testing lilo.conf ... Testing successful. Installing the partition boot sector... Running /sbin/lilo ... Installation successful. # -- There is no conflict with grub version 1 or grub version 2 here. If the user has either version of grub installed, then the user will set do_bootloader = no in /etc/kernel-img.conf. In the case of grub version 1, he will also add postinst_hook = update-grub postrm_hook = update-grub A similar change should be made to the preinst, prerm, and postrm scripts for consistency. The Squeeze and Sid scripts have the same problem. OK, I solved the mystery. Now someone on the kernel team actually has to fix it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
Package: initramfs-tools Version: 0.94.4 Severity: serious (Note: I opened this bug report with a severity of serious, since it prevents my system from booting. In my humble opinion this makes the package unsuitable for release in a stable release. But I am not a package maintainer nor the release manager; so you can argue with me about the severity if you think it is warranted.) I run Debian testing (Squeeze) on the s390 architecture. I just performed an aptitude update and aptitude full-upgrade sequence, and among the updates was a new version of initramfs-tools: 0.94.4. (I noticed that Debian bug report 576603 was opened with a severity of serious with the apparent goal of keeping the package from migrating from Sid to Squeeze, and the bug has not been marked as resolved, nevertheless the package did migrate to Squeeze within the past few days.) The new package completely broke my system's ability to boot. Allow me to explain the boot mechanism that the old version successfully accomplished, and then explain how the new version fails. I have four different disks, one partition each, that are mounted on four different mount points, as follows: Device Mount Point 0200 / 0201 /boot 0202 /home 0203 swap I have a file called /etc/modprobe.d/dasd which contains the following statement: options dasd_mod dasd=0.0.0200(diag),0.0.0201,0.0.0202-0.0.0203(diag) This accomplishes two things: (1) it guarantees the correspondence of Linux devices names to s390 device numbers as follows: Device 0200 /dev/dasda 0201 /dev/dasdb 0202 /dev/dasdc 0203 /dev/dasdd and (2) it specifies the device driver used for each disk as follows: -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
Oops! I accidentally sent the e-mail prematurely. Allow me to continue ... and (2) it specifies the device driver used for each disk as follows: Device Device Name Driver -- - /dev/dasda dasd_diag_mod /dev/dasdb dasd_eckd_mod /dev/dasdc dasd_diag_mod /dev/dasdd dasd_diag_mod I run Debian GNU/Linux in a virtual machine under IBM's z/VM operating system, of course. Otherwise, the DIAG driver cannot be used. The way the module dependencies work, the modules must be loaded in the following order: (1) dasd_mod (no dependencies on another module) (2) dasd_diag_mod (dependency on dasd_mod) (3) dasd_eckd_mod or dasd_fba_mod (both have a dependency on dasd_mod) Although strictly speaking neither dasd_eckd_mod nor dasd_fba_mod have a dependency on dasd_diag_mod, nevertheless dasd_diag_mod must be loaded *before* either dasd_eckd_mod or dasd_fba_mod if a dasd of that type is to use the DIAG driver. To guarantee this I have the following lines in /etc/initramfs-tools/modules: dasd_mod dasd_diag_mod in that order. Neither dasd_eckd_mod nor dasd_fba_mod are listed here, since they are loaded as needed by the hot plug system (i.e. udev). I do not use sysconfig-hardware touch files (i.e. /etc/sysconfig/hardware/config-ccw-0.0.0200, /etc/sysconfig/hardware/config-ccw-0.0.0201, etc.), since I have had trouble in the past getting one of these devices varied offline dynamically if they are brought online at boot time via this method. Instead, I bring the devices online at boot time via the dasd option passed to the dasd_mod module via the /etc/modprobe.d/dasd file. All of this has been working flawlessly through a number of releases until now. All of a sudden, nothing works. The boot process times out waiting for the permanent root file system and drops me into an ash shell while the initial RAM filesystem is still mounted as /. I investigated and found that /etc/modprobe.d/dasd was not included in the initial RAM filesystem. That's a problem! Seeing that all other files that were included in /etc/modprobe.d had an extension of .conf, I renamed /etc/modprobe.d/dasd to /etc/modprobe.d/dasd.conf, rebuilt the initial RAM filesystem, re-ran zipl, and rebooted. This time it tried to bring the devices online but got errors of the form: dasd: 0.0.0200 Setting the DASD online failed because of missing DIAG discipline dasd: 0.0.0200: Setting the DASD online failed with rc=-19 0.0.0201 (/dev/dasdb) was the only device that it could get online. I knew immediately what was the cause of this: dasd_diag_mod was not loaded soon enough. By the time it dropped me into an ash shell, dasd_diag_mod was loaded, but at the time that dasd_eckd_mod was trying to bring the devices online, dasd_diag_mod was not loaded. The modules listed in /etc/initramfs-tools/modules must be loaded *before* udev is allowed to do its thing. The message udev: starting version 154 occurs in the log before Begin: Loading essential drivers ... done. To further complicate matters, it appears that the entire /etc/initramfs-tools directory, including /etc/initramfs-tools/modules, is absent from the initial RAM filesystem. How would it even know what modules need to be loaded as essential drivers if this file is not present? A new kernel, linux-image-2.6.32-5-s390x, was also included in the upgrade; so perhaps this is part of the problem as well. Previously, I was using linux-image-2.6.32-3-s390x. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582002: Modules not loading in the proper order (initramfs-tools: s390 architecture)
I just tried a couple of things. First, I thought this might be related to the new dependency-based boot sequencing. I tried adding the line CONCURRENCY=none to /etc/default/rcS to disable parallel booting. But it didn't do the trick. I then rebuilt the initial RAM filesystem and re-ran the boot loader after making the above change. It still didn't fix the problem. Then I booted the old kernel. It booted just fine. But when I rebuilt the initial RAM filesystem for the old kernel with update-initramfs -uk 2.6.32-3-s390x and re-ran the boot loader, then the old kernel wouldn't boot either. So this is not related to the kernel. It is definitely related to the new version of initramfs-tools. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569594: git t7400.24 is failing again
On Thu, 25 Mar 2010 10:03:43 -0400 (EDT), Jonathan Nieder wrote: # git-core’s t7400.24 results: # I have to admit I’m mystified, since nothing has changed recently # in this area of the git source code. # Porters, has anything possibly relevant (configuration changes?) # happened recently? # # Please send follow-ups to the bug address. # ok ia64 (zx6000) 1.6.5-1~bpo50+1 2010-01-19 # ok ia64 (mundy) 1.6.6.12010-01-28 # FAILia64 (alkman) 1.6.6.2 2010-02-12 # ok ia64 (alkman) 1.7.0 2010-02-16 # ok ia64 (alkman) 1.7.0 2010-02-16 # ok ia64 (alkman) 1.7.0.2 2010-03-18 # ok ia64 (caballero) 1.7.0.32010-03-22 # ok hppa (penalosa) 1.6.6.1 2010-01-28 # FAILhppa (peri) 1.6.6.2 2010-02-13 # ok hppa (peri) 1.7.0 2010-02-16 # ok hppa (peri) 1.7.0 2010-02-16 # ok hppa (penalosa) 1.7.0.2 2010-03-18 # ok hppa (peri) 1.7.0.3 2010-03-22 # ok s390 (lxdebian) 1.6.6.1 2010-01-28 # ok s390 (zandonai) 1.6.5-1~bpo50+1 2010-02-01 # FAILs390 (zandonai) 1.7.0~rc2 2010-02-13 # ok s390 (debian-31) 1.7.0 2010-02-16 # FAILs390 (lxdebian) 1.7.0.2 2010-03-18 # FAILs390 (lxdebian) 1.7.0.3 2010-03-22 # Other platforms are fine. reopen 569594 found 569594 git-core/1:1.7.0.2-1 found 569594 git-core/1:1.7.0.3-1 thanks I am trying to reproduce on S/390 with hercules, but it is very slow. The only thing I know of that changed recently is the switch to a 64-bit kernel by the build server for s390. (I am just a regular Joe Schmoe user. I'm not a Debian package maintainer, Debian Developer, or any other kind of official Debian person. So consider the source.) See bug number 573887 for a build problem that surfaced with the mozart package that resulted from this kernel change. Whether that's your problem or not, I have no idea. As for the other architectures, I have no idea about them either. -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569594: git t7400.24 is failing again
On Thu, 25 Mar 2010 11:03:01 -0400 (EDT), Jonathan Nieder wrote: Stephen Powell wrote: The only thing I know of that changed recently is the switch to a 64-bit kernel by the build server for s390. (I am just a regular Joe Schmoe user. I'm not a Debian package maintainer, Debian Developer, or any other kind of official Debian person. So consider the source.) That sounds relevant indeed (and unfortunate for my efforts to reproduce: I haven’t been able to get a 64-bit kernel running on this emulated machine). Thank you; I’ll think harder. If you're using Hercules, you have to define the the machine in Hercules as a 64-bit machine, such as a z800, z900, etc. A 64-bit kernel won't run on an ESA/390 processor. I am fortunate enough to have a real mainframe, a z890; so I don't need to use Hercules. The z890 has an LPAR with a dedicated IFL processor, I run z/VM 5.4.0 in the LPAR, and then I run Linux in a virtual machine under z/VM. I believe the build server for s390 runs Squeeze/Sid, and uses a kernel such as linux-image-2.6.32-3-s390x, linux-image-2.6.32-4-s390, or something close to that. As far as I know, which isn't very far, the user space is still 32-bit for register size and 31-bit for addressing. But the kernel space is 64-bit. Again, I'm speaking exclusively of the s390 architecture here. Someone please correct me if I'm wrong. Note: please reply to the BR and the list, not to me personally. Not only is information missing, but it messes up the threads when you do that. This reply will probably start a new thread, since my e-mail client doesn't give me a way to override the Reply-To field. Ideally, it should be a continuation of the old thread. -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569594: git t7400.24 is failing again
On Thu, 25 Mar 2010 11:41:58 -0400 (EDT), Bastian Blank wrote: That change was done several years ago. The last buildd with a 32bit kernel was debian01, which was discontinued over 3 years ago. Hmm. Interesting. I wonder why, then, that mozart had a problem related to this only a couple of weeks ago? (See BR 573887.) -- .''`. Stephen Powellzlinux...@wowway.com : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523942: linux-image-2.6.26-2-s390 will not boot!
Package: linux-image-2.6.26-2-s390 Version: 2.6.26-15 Severity: critical This particular Linux kernel image will not boot on a virtual machine in ESA mode under z/VM. I have not tried other platforms (LPAR, for example). Here is the boot log: -- Booting default (debian)... [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.26-2-s390 (Debian 2.6.26-15) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Fri Mar 27 03:31:55 UTC 2009 [0.00] We are running under VM (31 bit mode) [0.00] This machine has an IEEE fpu [0.00] Zone PFN ranges: [0.00] Normal 0 - 131072 [0.00] Movable zone start PFN for each node [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 - 131071 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130047 [0.00] Kernel command line: root=/dev/dasda1 vmhalt=LOGOFF vmpoff=LOGOFF BOOT_IMAGE=0 [0.00] PID hash table entries: 2048 (order: 11, 8192 bytes) [17179568.184350] console [ttyS0] enabled [17179569.185299] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [17179568.186409] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [17179569.195235] Memory: 510848k/524288k available (2272k kernel code, 0k reserved, 844k data, 148k init) [17179569.195254] Write protected kernel read-only data: 0x12000 - 0x2eefff [17179568.196240] Security Framework initialized [17179569.196258] SELinux: Disabled at boot. [17179568.196276] Capability LSM initialized [17179568.196413] Mount-cache hash table entries: 512 [17179569.197399] Initializing cgroup subsys ns [17179569.197420] Initializing cgroup subsys cpuacct [17179568.197484] Initializing cgroup subsys devices [17179569.320946] CPUs: 1 configured, 0 standby [17179569.471072] cpu 0 phys_idx=0 vers=FF ident=0503CC machine=2086 unused=8000 [17179568.472235] Brought up 1 CPUs [17179569.472695] net_namespace: 660 bytes [17179569.473175] NET: Registered protocol family 16 [17179569.557633] IP route cache hash table entries: 16384 (order: 4, 65536 bytes) [17179569.557633] TCP established hash table entries: 65536 (order: 7, 524288 bytes) [17179569.560173] TCP bind hash table entries: 65536 (order: 7, 524288 bytes) [17179569.562589] TCP: Hash tables configured (established 65536 bind 65536) [17179569.562616] TCP reno registered [17179568.574245] NET: Registered protocol family 1 [17179568.574569] checking if image is initramfs... it is [17179570.461614] Freeing initrd memory: 3824k freed [17179570.463293] audit: initializing netlink socket (disabled) [17179570.463321] type=2000 audit(1239646960.408:1): initialized [17179570.464285] VFS: Disk quotas dquot_6.5.1 [17179570.464409] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) [17179570.464471] msgmni has been set to 1005 [17179570.464744] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254) [17179570.464768] io scheduler noop registered [17179570.464788] io schedulter anticipatory registered [17179570.464810] io scheduler deadline registered [17179570.464882] io scheduler cfq registered (default) [17179570.470664] brd: module loaded [17179570.470774] cio: Channel measurement facility using extended format (autodetected) [17179570.470804] qdio: loading QDIO base support version 2 [17179570.473469] TCP cubic registered [17179570.473657] NET: Registered protocol family 10 [17179570.476252] lo: Disabled Privacy Extensions [17179570.477111] Mobile IPv6 [17179570.477143] NET: Registered protocol family 17 [17179570.477793] registered taskstats version 1 [17179570.478468] Freeing unused kernel memory: 148k freed [17179570.479271] Kernel panic - not syncing: Attempted to kill init! HCPGIR450W CP entered; disabled wait PSW 000A 8001E8FA -- In comparing this boot to the (successful) boot of its predecessor, linux-image-2.6.26-1-s390, version 2.6.26-13lenny2, the previous version loads essential modules at this point: -- Loading, please wait... Begin: Loading essential drivers ... -- at which point the modules listed in /etc/initramfs-tools/modules are loaded. In my case, these modules are dasd_diag_mod dasd_eckd_mod dasd_mod vmcp loop Without the dasd modules, the permanent root file system cannot be mounted. I tried re-running update-initramfs for this specific kernel version, but it made no difference.
