Re: Booting doesn't: ?
On Wednesday 16 March 2005 22:51, Matthias Urlichs wrote: Any idea what the problem is? Should I wait for RC3? I very much doubt that will fix it. Both RC2 and the current pre RC3 install without problems on the self-compiled Hercules 3.02 I run on my Toshiba Satellite A40 (Pentium 4) laptop. I also successfully installed RC2 several times on a self-compiled Hercules 3.01. Cheers, FJP pgpbZwJKCTKwO.pgp Description: PGP signature
Re: Bug#306026: pgplot5: FTBFS: dh_dhelp: Command not found
On Sunday 24 April 2005 18:39, Frans Pop wrote: I have built the package for s390, but can not upload myself (still waiting for DAM approval). Joey Hess has just done the upload, so it's now complete for all archs. Cheers, FJP pgp7ujbrzUqfp.pgp Description: PGP signature
Re: Debian/S390 cd-based install image
On Wednesday 27 July 2005 18:37, Frans Pop wrote: I think I've managed to create a bootable CD image. It is available for testing from [1]. Basically, I have revived the code that was already available in Woody. The primairy purpose of this image is to test if it boots. I may have made mistakes building it which could cause an installation to fail later on. I've just managed to boot the CD successfully using Hercules: - loopmount the iso on /cdrom - start hercules - ipl /cdrom/boot/d390.ins And it only took me 2 hours to find this ridiculously simple option :-/ pgpumq5aOOXsU.pgp Description: PGP signature
Re: Debian/S390 cd-based install image
On Thursday 13 October 2005 04:24, Patrick Finnegan wrote: [1] http://people.debian.org/~fjp/d-i/debian-testing-s390-netinst.iso Now that I'm finally getting around to testing this on my real S/390 G5, the file has disappeared, and I can't find it anywhere. :/ Yes, I deleted it as I dislike keeping my home directory cluttered with unused things... As the builds for weekly images for testing has now been resumed, the option to ipl from CD should now also be available in this image: http://cdimage.debian.org/pub/weekly/s390/debian-testing-s390-binary-1.iso I'd be very happy if you could test that. Cheers, FJP Note: you may run into a problem during partitioning because current versions of parted do not support DASD. See also: http://wiki.debian.org/DebianInstallerToday pgpIraTnbR89n.pgp Description: PGP signature
Re: Debian/S390 cd-based install image
On Saturday 15 October 2005 02:31, Patrick Finnegan wrote: Frans Pop declared on Thursday 13 October 2005 05:32 am: As the builds for weekly images for testing has now been resumed, the option to ipl from CD should now also be available in this image: http://cdimage.debian.org/pub/weekly/s390/debian-testing-s390-binary- 1 .iso The files to do so aren't in the ISO. You are right. This first build was done with an old version of the CD building scripts. Today new ISOs became available. I have checked that these do contain the needed files. Cheers, FJP pgpRKf14AERU5.pgp Description: PGP signature
Re: Failed to update to 2.6.14 from 2.6.11
On Tuesday 22 November 2005 17:17, Ivan Warren wrote:
I am trying to upgrade my linux kernel from 2.6.11-1 to 2.6.14-2
LOG
Setting up linux-image-2.6.14-2-s390 (2.6.14-2) ...
Using /usr/sbin/mkinitrd.yaird to build the ramdisk.
Full list of probed ramdisk generating tools : /usr/sbin/mkinitrd
/usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs.
yaird error: can't open /proc/bus/input/devices (fatal)
Failed to create initrd image.
Please file a bugreport against Yaird ('reportbug yaird'). On S/390 it
should not fail if /proc/bus/input/devices is not available.
On other architectures this is needed to check which drivers need to be
loaded to support the keyboard, but on S/390 it makes no sense.
If you need to install the 2.6.14 kernel, you will probably have to look
for the relevant check in yaird and comment it out. If not, your best
option is probably just to reinstall the 2.6.11 kernel and remove the
2.6.14 kernel.
Cheers,
FJP
pgpD72d4pkUxH.pgp
Description: PGP signature
Re: Failed to update to 2.6.14 from 2.6.11
On Tuesday 22 November 2005 19:55, Frans Pop wrote: If you need to install the 2.6.14 kernel, you will probably have to look for the relevant check in yaird and comment it out. If not, your best option is probably just to reinstall the 2.6.11 kernel and remove the 2.6.14 kernel. One other alternative. You can also try installing initramfs-tools and try to use that instead of yaird to create the initrd. pgpHXghNFBjXl.pgp Description: PGP signature
Re: Failed to update to 2.6.14 from 2.6.11
On Tuesday 22 November 2005 21:54, Ivan Warren wrote: Now.. Also tried using good ole mkinitrd but now this won't boot : That definitely won't work... Any clue ? Well, did you try initramfs-tools? It's command to create the initrd is 'mkinitramfs'. pgptEtwCIbh5s.pgp Description: PGP signature
Re: Failed to update to 2.6.14 from 2.6.11
On Tuesday 22 November 2005 22:35, Ivan Warren wrote: Hmm.. Should I report a initramfs-tools bugreport ? (now - I see there is a bunch of bugs outstanding on initramfs, so no doubt this would be a dup).. Maybe not. I'm not sure anyone would have taken the plunge for s/390 yet. Done. ALERT× /dev/dasd/0.0.0108/part1 does not exist. Dropping to a shell× Seems it has the same basic problem: does not know how to support dasd... Not sure if this [2] is also a factor here. I might need to customize mkinitramfs first (although it sure didn't complain about anything when the initramfs image was created).. Well, to quote one of the developers involved with yaird : yaird is designed to be anal. It will generate an error whenever it gets into a situation it does not like or support. I guess this is a good viewpoint for an initrd generator as it will prevent you ending up with an unbootable system [1]. It is also designed to generate a minimal initrd: just containing what's needed to boot the current configuration. initramfs-tools has other goals and is more likely to fail on reboot. It will, by default, generate an all inclusive initrd for maximum portability (remove your dasd from your current system, hotplug it into the one in the next room and reboot ;-) Cheers, FJP [1] In a vmware emulator it still fails on reboot because the BusLogic disk driver does not support sysfs and is therefore silently not included. [2] http://lists.debian.org/debian-s390/2005/11/msg00010.html pgpwn9mrgrjuZ.pgp Description: PGP signature
Re: Bug#340508: missing modules on s390/s390x (mkinitramfs for 2.6.14)
(CC to d-s390 as there may be people who can provide additional
information.)
On Friday 02 December 2005 22:58, you wrote:
can you please retest if that device gets created?
OK. I've done some testing and made some progress.
First, the following modules need to be available in the initrd:
- dasd_eckd_mod
- dasd_fba_mod
- dasd_mod
- dcssblk
It I add these in /etc/mkinitramfs/modules, they will of course be loaded,
but the dasd devices are not created. A boot results in:
snip from console
Loading, please wait...
Begin: Initializing /dev ...
Done.
Begin: Loading modules ...
Done.
Begin: Running /scripts/init-premount ...
Done.
Begin: Mounting root file system ...
Begin: Running /scripts/local-top ...
Done.
ALERT /dev/dasda1 does not exist. Dropping to a shell
/snip
Reason is that dasd_mod needs an option to tell it which dasd devices
should be used. I've written a script that creates a config file for
modprobe in /etc/modprobe.d/.
The script is a first approximation and probably needs cleaning up.
Background info and some possible issues are documented in the script.
The script was added in /etc/mkinitramfs/hooks/
During reconfiguration of the kernel-image, I got the following error.
snip
$ sudo dpkg-reconfigure linux-image-2.6.14-2-s390
Using /usr/sbin/mkinitramfs to build the ramdisk.
Full list of probed ramdisk generating tools :
/usr/sbin/mkinitrd /usr/sbin/mkinitrd.yaird /usr/sbin/mkinitramfs.
ln: creating symbolic link `/tmp/mkinitramfs_Znxcw0//etc/modprobe.d/dasd'
to `/tmp/initramfs_dasd': File exists
/snip
I used 'set -x' in the script to debug and that told me it was being
executed twice! This looks like a bug in initramfs-tools.
A boot with the initrd thus created resulted in:
snip from console
Loading, please wait...
Begin: Initializing /dev ...
Done.
Begin: Loading modules ...
dasd(eckd): 0.0.0120: 3390/02(CU:3990/02) Cyl:1113 Head:15 Sec:224
dasd(eckd): 0.0.0120: (4kB blks): 801360kB at 48kB/trk compatible disk
layout
dasda:VOL1/ LX0120: dasda1 dasda2
dasd(eckd): 0.0.0121: 3390/02(CU:3990/02) Cyl:1113 Head:15 Sec:224
dasd(eckd): 0.0.0121: (4kB blks): 801360kB at 48kB/trk compatible disk
layout
dasdb:VOL1/ 0X0121: dasdb1 dasdb2
Done.
Begin: Running /scripts/init-premount ...
Done.
Begin: Mounting root file system ...
Begin: Running /scripts/local-top ...
Done.
Begin: Running /scripts/local-premount ...
Done.
FATAL: Module ext3 not found.
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
Begin: Running /scripts/log-bottom ...
Done.
Done.
Begin: Running /scripts/init-bottom ...
Done.
Kernel panic - not syncing: Attempted to kill init
HHCCP011I CPU: Disabled wait state
PSW=000A 8003025E
/snip
So now the devices are created.
The FATAL: Module ext3 not found. error is bogus as ext3 is built in.
The next lines tell that a ext3 partition is mounted.
I have no idea why init fails after that. As I did not get a shell, I'm
not sure how to debug further. Suggestions welcome.
Cheers,
FJP
[EMAIL PROTECTED]:~$ cat /etc/mkinitramfs/hooks/dasd_cfg
#! /bin/sh
# initramfs hook script: /etc/mkinitramfs/hooks/dasd_cfg
# dasd_mod module needs option listing dasd's to initialize
# Example: options dasd_mod dasd=0120,0121
# Devices are taken from /proc/dasd/devices. Example (from 2.4.27 kernel):
# $ cat /proc/dasd/devices
# 0120(ECKD) at ( 94: 0) is dasda : active at blocksize: 4096, 200340
blocks, 782 MB
# 0121(ECKD) at ( 94: 4) is dasdb : active at blocksize: 4096, 200340
blocks, 782 MB
# TODO
# Maybe /proc/dasd/devices needs to be parsed better.
# I assume that the ordering of devices is determined by their order in the
# module option. I'm not sure of the sorting in /proc/dasd/devices, so it
# may not do the right thing if dasda is 0121 and dasdb is 0120.
# I'm also not sure how reliable the format of the file is.
. /usr/share/initramfs-tools/hook-functions
[ -r /proc/dasd/devices ] || exit 1
dasd_dev=$(cut -d( -f1 /proc/dasd/devices)
for dev in $dasd_dev; do
[ -n $dasd_devs ] dasd_devs=${dasd_devs},
dasd_devs=${dasd_devs}${dev}
done
if [ -n $dasd_devs ] ; then
echo options dasd_mod dasd=$dasd_devs /tmp/initramfs_dasd
copy_exec /tmp/initramfs_dasd /etc/modprobe.d/dasd
fi
pgp9mbRP2NVWV.pgp
Description: PGP signature
Re: Bug#340508: missing modules on s390/s390x (mkinitramfs for 2.6.14)
Some additional info. I've done my research from a system (Hercules emulator) running 2.4.27. For 2.4.27, the dasd modules are built into the kernel. The option to set the dasd devices is therefore passed from the zipl bootloader. The dasd= option in the [debian_26] section was of course ignored by the initrd. $ cat /etc/zipl.conf [defaultboot] defaultmenu = menu :menu target = /boot 1 = debian_24 2 = debian_26 default = 1 prompt = 1 timeout = 3 [debian_24] target = /boot image = /boot/vmlinuz-2.4.27-2-s390 parameters = ro vmpoff=LOGOFF dasd=0120,0121 root=/dev/dasda1 [debian_26] target = /boot image = /boot/vmlinuz-2.6.14-2-s390 ramdisk = /boot/initrd.img-2.6.14-2-s390 parameters = ro vmpoff=LOGOFF dasd=0120,0121 root=/dev/dasda1 pgpQ0tIeYLLP0.pgp Description: PGP signature
Re: Debian installation media question.
On Wednesday 07 December 2005 14:38, [EMAIL PROTECTED] wrote: I want to know if I can download Debian S/390, burn a CD and do most of the installation from the CD on the OS/2 system that supports the HMC? I see from the site that Support to ipl off an installation CD has been added back in the version of the installer that will be released with Etch. Although with Etch you can boot off the CD, the installation is in fact no different from the other installation methods which means that most of the installation will be done over the network. After setting up the network, you will be offered to continue the installation over an SSH connection. All installer components and packages are downloaded from mirrors. If you burn a CD, you can however use that as a source to install additional packages after the reboot, although you may have to configure it manually. See also this README file, which is included on the CD: http://svn.debian.org/wsvn/debian-cd/trunk/data/etch/s390/README.boot?op=filerev=0sc=0 Cheers, FJP pgpg1MxVsCuPY.pgp Description: PGP signature
Status of d-i kernel transition for 2.6.14
(CC'ing port mailing lists where the port does not have 2.6 support in d-i) An update of the table of kernel versions. General comments: - CD images still use 2.6.12 as Etch is installed - only x86 and sparc64 fully switched to 2.6.14 for sid_d-i - powerpc and amd64 have uploaded new udebs, but not yet updated d-i config - hppa should update kernel udebs to 2.6.14 - arm, mips, mipsel have initial (now outdated) 2.6 kernel udeb packaging in the d-i SVN repository, but never yet uploaded - sparc32 was badly supported in 2.6.12 and thus does not have a 2.6 installer, possibly this will be implemented for a later version The 2nd and 3rd columns in this table also show that a lot of arches do not currently have 2.6 kernel udebs in the archive or at least do not have d-i images that boot with a 2.6 kernel. This situation is highly undesirable as 2.6 _is_ the preferred kernel for most architectures when running unstable and will also be the main kernel version for Etch. The D-I Etch beta2 release is provisionally planned for the 2nd half of January and should have the 2.6.15 kernel that is expected to be released within the next few weeks. Porters should really start implementing support for 2.6 in d-i for their architecture in order to be ready for Etch and allow sufficient time for testing and ironing out possible issues. Support for 2.6 should probably be implemented in time for the D-I Etch beta3 release (at the very latest!). Help in this effort is of course available from the rest of the d-i team where needed. arch udebbuild/config base-installer debian-cd --- - --- i386 2.6.14-2/2.4.27-2 2.6.14-2/2.4.27-2 2.6/2.4.27-22.6/2.4.27-2 alpha2.4.27-2/(2.6.12-1) 2.4.27-2 2.4.27-2 amd642.6.14-32.6.12-1 2.6 2.6 arm 2.4.27 2.4.272.4.27 hppa 2.6.12-12.6.12-1 2.6.12-1/2.4.27 2.6 ia64 *) 2.6.12-1/2.4.27-2 2.6.12-1/2.4.27-2 2.6/2.4.27-22.6/2.4.27-2 m68k 2.4.27/(2.6.12-1) 2.4.272.4.27 mac2.2.25 2.2.252.2.25 mips 2.4.27 2.4.272.4.27 mipsel 2.4.27 2.4.272.4.27 powerpc 2.6.14-2/2.4.27 2.6.12-1/2.4.27 2.6/2.4.27 s390 2.4.27-22.4.27-2 2.4.27-2N/A sparc32 2.4.27-22.4.27-2 2.4.27-2 sparc64 2.6.14-2/2.4.27-2 2.6.14-2/2.4.27-2 2.6/2.4.27-2 [1] 2.6.14-2 does not boot on IA64, waiting for 2.6.15 NOTE A new 2.4.27 kernel for x86 has just been accepted into unstable so 2.4 kernel udebs will also need updating soon. Cheers, Frans Pop pgpbqwnLhuLeE.pgp Description: PGP signature
Re: RFH - Debian/S390
On Monday 06 February 2006 19:08, Martin Michlmayr wrote: * Adam Thornton [EMAIL PROTECTED] [2006-02-06 10:09]: The short answer, though, is that the parted problem seems to be basically done, pending rolling it in officially, which is Otavio's I have gotten the patches from Otavio and have just finished testing them in D-I (building parted takes a while on Hercules :-) Parted seems to work fine again. It recognized my existing partitions and partitioning in the installer worked fine too. There are some issues that need to be looked into for the installation (I managed to finish it with some minor manual interventions, but the system failed to boot...). I'll give Otavio the green light to upload the new parted though. I'm not sure exactly what's missing, Frans or waldi will know. There are two things we should aim to do for the next D-I release: - switch to 2.6 for installations If I understand Bastian correctly this mainly requires automatic configuration. I think he started that with his last s390-tools upload. dasd configuration support is still missing in that IIUC. - add full support for dasd in partman So that at least partconf and partitioner can be dropped; not sure if s390-dasd can be dropped. With the better integration in (lib)parted this should probably not be too difficult. Cheers, FJP pgpx7BD1GYFxV.pgp Description: PGP signature
Re: RFH - Debian/S390
On Tuesday 07 February 2006 00:13, Frans Pop wrote: Parted seems to work fine again. It recognized my existing partitions and partitioning in the installer worked fine too. There are some issues that need to be looked into for the installation (I managed to finish it with some minor manual interventions, but the system failed to boot...). Done another installation test yesterday and there are only two issues to have s/390 installable again: - minor issue with kernel selection in base-installer; new version with fix already uploaded; - sysvinit installs incorrect /etc/inittab for installed system resulting in the problem on reboot; RC bug filed: #351871. So, if we get the sysvinit issue fixed in time for the D-I Beta2 release, it looks that S/390 will be installable again (using 2.4 kernel). Thanks to all who contributed. Cheers, FJP pgpLOMBbpxqXj.pgp Description: PGP signature
D-I Etch Beta2 - Status update (3)
I've made a complete mess of CD images for Beta2 so far as the result of a wrong assumption. This means, as some installation reports and comments have shown, that CD images linked from [1] have been broken since last Friday. The good news is that there are now good Beta2 netinst and businesscard CD test images available from [1]. Note that these are not the regular etch_d-i or sid_d-i. The correct link for Beta2 images is currently: http://cdimage.debian.org/cdimage/beta2-test-build/ Initial tests using these images for i386 and sparc64 have shown no problems. Tests for other arches are very much appreciated [2]. This also means that there are no good full CD images available yet. However, some issues with full CD images have been identified [3] and are being worked on. I've also uploaded the (hopefully final) 20060302 build of debian-installer today which includes the new 2.6.15-7 kernels. It has been accepted for i386 and so should now start building for all arches. We will probably have a small further delay in the Beta2 release, but because no blocking issues have been identified as yet, it looks as if we can keep it minimal. I'm somewhat reluctant to post hard dates ATM. I'm very sorry for any confusion. Please blame it on my inexperience as release manager for d-i and the complexity of the whole process. Cheers, FJP [1] http://www.debian.org/devel/debian-installer/ [2] SVN: installer/doc/devel/release-checklist [3] http://lists.debian.org/debian-boot/2006/03/msg00050.html pgpNgyAgryMmF.pgp Description: PGP signature
Re: D-I Etch Beta2 - Status update (4)
(already sent to d-boot) On Tuesday 07 March 2006 13:52, Frans Pop wrote: I am very happy to announce that the debian-installer images targeted for Beta2 are now in testing (except AMD64) and that daily (etch_d-i) netinst and buisinesscard CD images using them are now available from [1]. These images use the 2.6.15-7 kernel. To avoid confusion, the direct link to the correct images is: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/$arch/iso-cd/ pgp3pPnVikvTR.pgp Description: PGP signature
Re: Request (small) porting help for linuxinfo
On Thursday 09 March 2006 19:54, Helge Kreutzmann wrote: Did you call linuxinfo and the ls as ordinary user? I wonder, because the size looks ok. Yes to both. Do you have moment to spare and can I send you a patch to try? As I am not a Debian developer, I do not have access to a s390 machine so I cannot try myself. Sure. I'm fairly busy over the weekend, so a reply to a test request may have to wait until after that. Cheers, FJP pgpLdERXswJ8l.pgp Description: PGP signature
Re: missing modules on s390/s390x
Thanks Bastian. On Thursday 16 March 2006 17:29, Bastian Blank wrote: On Thu, Mar 16, 2006 at 04:13:21PM +0100, Frans Pop wrote: Only problem was that the network interface did not come up. Trying to manually start it resulted in: You need a 2.6.16-rc5 kernel and sysconfig-hardware. Yes, I remembered sysconfig-hardware and already installed it. The new kernel properly loads the network modules, the later is used to configure the hardware. I see that the experimental kernel image does not depend on sysconfig-hardware. Should it (to ensure that users upgrading from Sarge will have it installed)? pgpfkwNDpw070.pgp Description: PGP signature
Fwd: [D-I] Post-release notes
(This was supposed to be BCC'ed to d-ports...) -- Forwarded Message -- Subject: [D-I] Post-release notes Date: Saturday 18 March 2006 03:25 From: Frans Pop [EMAIL PROTECTED] To: debian-boot@lists.debian.org As the last action for the Beta 2 release, the links for the daily images on [1] have been switched back to sid_d-i and thus can again be used to test the daily built images and latest uploads for udebs to unstable. Porters should also be aware that the mirror split [2] may affect new installs as mirrors following the reduced default set will no longer support most arches, but will still be listed the installer's mirror selection list for all architectures they previously carried. The mirror selection component currently does _not_ check if an arch is actually available on a mirror, so errors will only occur later during the installation (during either download of additional d-i components or package installation by debootstrap). There is an erratum [3] that explains the issue and that users can be pointed to. A safe mirror to use is ftp.nl.debian.org but there are probably others. ftp.debian.org is _not_ safe. Mirrors that are currently OK may still drop arches over the next month or so. This issue affects all arches, except i386. Cheers, FJP [1] http://www.debian.org/devel/debian-installer [2] http://lists.debian.org/debian-mirrors-announce/2006/02/msg0.html [3] http://www.debian.org/devel/debian-installer/errata --- pgpaFJQfNORLz.pgp Description: PGP signature
Re: s390 hardware config
On Friday 27 January 2006 14:24, Bastian Blank wrote: I finaly finished a rudimentary hardware configuration. It have some similarities with the redhat and suse sysconfig. (This was the simplest schema I found.) - A config for ccwgroup contains a CCWGROUP_CHANS array: /etc/sysconfig/hardware/config-ccw-0.0.9000: | CCWGROUP_CHANS=(0.0.9000 0.0.9001 0.0.9002) I now have 2.6.16 booting nicely on hercules and can get the net up by: echo 0.0.0a00,0.0.0a01 /sys/bus/ccwgroup/drivers/ctc/group echo 1 /sys/bus/ccwgroup/devices/0.0.0a00/online I've not been able get udev to set up the hardware though. I've created a file '/etc/sysconfig/hardware/config-ccw-0.0.0a00' with: CCWGROUP_CHANS=(0.0.0a00 0.0.0a01) but that does not seem to do anything. By googling I found references to CCW_CHAN_IDS, so I also tried: CCW_CHAN_IDS=(0.0.0a00 0.0.0a01) but that did not work either. Help or tips for debugging welcome. pgpopCN84iwLq.pgp Description: PGP signature
Re: s390 hardware config
On Friday 24 March 2006 15:05, Bastian Blank wrote: After loading the ctc module, a hwup ccw 0.0.0a00 works fine. The ctc module is loaded. I have it in /etc/modules. A manual 'hwup ccw 0.0.0a00' does indeed do the trick. The problem seems to be that loading the ctc module does not trigger the proper events. I think I should just add an explicit loading of the module. I guess you mean that ctc will be loaded as part of the processing of /sys/bus/ccw/devices/0.0.0a00 so loading it manually in /etc/modules is no longer needed? Thanks. pgpLPbk3WjE4S.pgp Description: PGP signature
Re: [D-I] Preparing for update in stable
This is a follow-up to [1] which proposed a plan for the update of D-I using the latest kernel update for stable in preparation for Sarge r3. Follow-ups please in principle _only_ to d-release and d-boot and maybe to one of the CCed lists if relevant for them. On Friday 21 April 2006 02:01, Frans Pop wrote: In more detail: 1) Upload new i386 kernel udebs for both 2.4 and 2.6 to s-p-u (I've already prepared a set) 2) Get these acked by SRM so they actually show up in s-p-u; s-p-u already has debian-installer sections, I'm not sure if the acceptance queue and approval stuff supports udebs though (aj?) 3) Try a local build of d-i using a sources.list that has both stable and s-p-u in it [1]. After a bit of a wait, stage 2 was completed and I have completed the test in stage 3. Building the installer using s-p-u to get kernel udebs worked as expected and the mini.iso booted with the correct kernel and ran successfully for the first installation steps. Attached are the patches that are needed in the installer to make use of the new kernels. One patch for d-i itself and one for base-installer (for alpha). Patches for kernel udeb packages not included as they are trivial. Some comments on the patch for debian-installer: - AMD64 currently has _no_ kernel updates in their s-p-u Packages file; I understand that Joerg Jaspert needs to work on this for AMD64 to be included in the r3 point release. It will probably also need work by him to get the udebs into the debian-installer section in s-p-u. - The following architectures have no ABI version in the packages names and thus do not need a change in their config files: arm, m68k, mips, mipsel - Powerpc did not have any ABI version in the kernel-image package names, but with this release they have been added for 2.6.8 (not for 2.4.27!). As there also seem to be (new?) meta-packages, base-installer should continue to work. - The other arches all has an ABI change from 2 to 3. Request to d-i porters: please check if the changes for your architecture are complete. So, the next steps are: 4) If this works, poke^Wask porters to upload updated kernels udebs for their arches. We are going to delay step 4 until the kernel security updates that are currently being prepared are available in s-p-u. These do not include an ABI change. 5) Upload new base-installer. 6) Get those uploads acked by SRM. 7) Upload d-i and let the buildds do their stuff. The steps after that are: 8) Prepare necessary updates for debian-cd (if any). 9) Release r3 with very clear communication (debian-announce) that old installer images may break and that preferably new images should be used. Also communicate that availability of CD images may take up to a week. 10) Generate new package lists for debian-cd with new kernel versions. 11) Build and test images for all arches (with porter help). Cheers, FJP [1] http://lists.debian.org/debian-release/2006/04/msg00122.html Index: debian/postinst === --- debian/postinst (revision 36545) +++ debian/postinst (working copy) @@ -513,7 +513,7 @@ trykernel=kernel-image-$version-$flavor ;; alpha) - version=2.4.27-2 + version=2.4.27-3 if dmesg | grep -q ^Processors:; then CPUS=`dmesg | grep ^Processors: | cut -d: -f2` else Index: config/powerpc/power3.cfg === --- config/powerpc/power3.cfg (revision 37370) +++ config/powerpc/power3.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot # The version of the kernel to use. -KERNELVERSION = 2.6.8-power3 +KERNELVERSION = 2.6.8-3-power3 KERNEL_FLAVOUR = di KERNELNAME = vmlinux KERNELIMAGEVERSION = $(KERNELVERSION) Index: config/powerpc/powerpc.cfg === --- config/powerpc/powerpc.cfg (revision 37370) +++ config/powerpc/powerpc.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot floppy floppy-2.4 hd-media cdrom-minimal netboot-minimal # monolithic # The version of the kernel to use. -KERNELVERSION = 2.6.8-powerpc +KERNELVERSION = 2.6.8-3-powerpc # Targets for 2.4 kernel images will use this version instead. KERNELVERSION_2.4 = 2.4.27-powerpc KERNEL_FLAVOUR = di Index: config/powerpc/power4.cfg === --- config/powerpc/power4.cfg (revision 37370) +++ config/powerpc/power4.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot # The version of the kernel to use. -KERNELVERSION = 2.6.8-power4 +KERNELVERSION = 2.6.8-3-power4 KERNEL_FLAVOUR = di KERNELNAME = vmlinux KERNELIMAGEVERSION = $(KERNELVERSION) Index: config/alpha.cfg === --- config/alpha.cfg (revision 37370) +++ config/alpha.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot miniiso # The version
Successful 2.6 based installation on s/390 (hercules) - some issues
(This mail is a combination of installation-report and status overview for the S/390 list.) Mostly thanks to the efforts of Bastian Blank, S/390 has now made the switch from 2.4 to 2.6 in the installer. The installer now also uses partman instead of partitioner and partconf. Both network device and DASD detection had to be made sysfs-aware. Together with the switch to partman, that means there have been some major changes. Additional testing is very welcome. I've done two test installs using the Hercules emulator. The results are below. Note: until 2.6.16 kernel packages have migrated to unstable, installations of testing will fail to reboot. Installations of unstable should work (barring any normal breakages in unstable). * Network configuration (CTC) Works fine. Wishlist: - Maybe we should remove the selected read device from the list when asking for the write device - Maybe we could suggest default values (first available device for read; the one following the selected read device for write) * DASD configuration During the first install this failed because the DASD modules were not loaded. Modprobing them initially did not work because depmod had not been run after loading the kernel module udeb. This was solved (worked around rather) by adding the dasd-modules udeb to the initrd so that initial udev runs will load them. The real solution would be to run depmod and rerun udev as part of dasd detection. Issue: - After selecting a dasd device there is no change of the status on the screen which makes it look as if no device has been selected yet. This is only a presentation bug as the selection in fact was done correctly. * Partitioning - general The old udebs used for partitioning (partitioner and partconf) are still in the archives and thus have to be skipped manually. Partitioner will probably fail; after you get back to the menu, select Partition disks instead. This is a temporary problem that will be fixed as soon as the udebs are removed from the archive. * Partitioning - partman-auto Don't use guided partitioning! Instead select Manually edit partition table in the first partman screen. - There are no recipes for S/390 which makes partman-auto use msdos disklabel and try to create a logical partition for swap. This fails miserably. - As guided partitioning currently only supports using one device, it's not much use for S/390 anyway as most installations tend to use multiple DASDs. For the last reason, we'll probably just disable partman-auto for S/390 for now. * Partitioning - manual partitioning Select the s390 disklabel when using Hercules when creating a new partition table. I understand that msdos or gpt can be used in some cases. Issue: - When a new partition is created, it's name is shown strangely: LINUX.V^G^G^G^G^G^G.PART0001.NATI After committing the changes and restarting partman, it looks more normal though: LINUX.V0X0121.PART0001.NATIVE (Not sure where the 0121 comes from; the DASD I created the partition on was 0.0.0122!) * Base installation - kernel selection This is an existing issue, but worth mentioning anyway. Selection of the default kernel could be improved for S/390. Current selection uses the full kernel version (e.g. 2.6.16-2-s390) used in the installer. This means that: - if that kernel is not available, the fallback is not optimal; for example, if I install testing, the 2.6.15-1-s390x kernel will be selected by default (while hercules does not support s390x); - the installer will not install one of the meta packages which means that the user will not get automatic security updates if they have ABI changes. One thing to be aware of is that a new hardware configuration mechanism has been added for 2.6 kernels using the sysconfig-hardware package. The installer may (e.g. for CTC netdevices) create config files in directory: /etc/sysconfig/hardware/. Cheers, FJP pgpbU9Nwlovsh.pgp Description: PGP signature
Re: D-I Beta 3 - release update - please test
(Please reply only to debian-boot; reply-to set accordingly; add other recipients only selectively) A week since the planning was posted, time for an update. Thanks to James, the upload of d-i was processed very quickly. Since then various, mostly minor issues have been identified and resolved. We are now at the stage where final tests before the release can be done for all arches, so if you have some time, please run an installation on your favorite architecture(s). Please file an installation report with your results, or, if you are a d-i team member, update [0] directly. Beta 3 candidate images are available from the following locations: Full CD and DVD images: links weekly snapshot images on [1] Netinst and businesscard CD images: links to daily built images on [1] the daily images now point to the etch_d-i builds [2] Images for other installation methods: http://ftp.nl.debian.org/debian/dists/sid/main/installer-arch/current/images/ Known issues: - S/390 Beta 3 candidate images are broken; will be fixed with next upload - Lowmem settings in Beta 3 images are not yet correct; see below On Monday 24 July 2006 11:52, Frans Pop wrote: One important TODO item is updates to debian-cd, especially for architectures that are dropping 2.4 support in d-i. If your architecture needs such changes, please contact me. Joey and Steve can probably help with the changes where needed. As far as we know all needed updates in debian-cd have been made and successful builds for all types of CD images are now available. A fair amount of changes were needed, so please test CD-based installs. All this does mean that the current lowmem levels need serious review for all architectures. The good news is that memory requirement for a bare install (lowmem level 2) looks be hardly changed. An updated lowmem was uploaded today and will be included in the final upload for Beta 3. The level 1 limits have been increased substantially for all arches. For a few arches level 2 limits have been adjusted as well. We will need to get back to this before the RC releases. Release planning We are mostly running according to schedule. 29Jul Last chance to upload udebs for inclusion in intrds Last expected uploads (localechooser and lowmem) now done. 30Jul Testbuild of weekly images (using d-i images from unstable) Images for all architectures are now available. 1Aug Final upload of d-i images There is one issue that will probably delay the final upload of d-i images. A new upstream version of directfb was uploaded recently which FTBFS on powerpc. This breaks builds of d-i on arches which support the graphical installer. Hopefully this will be resolved soon. 2- 5 Aug Testing This can already start now. 2Aug Last chance to upload udebs not included in initrds 4- 6 Aug Preparation of release notes, errata, etc. 5Aug Migration of d-i to testing 6Aug CD builds 7Aug Release Will slip too depending on when the issue mentioned above is resolved. Cheers, FJP [0] installer/doc/devel/release-checklist [1] http://www.debian.org/devel/debian-installer/ [2] If you need to test sid_d-i images (using daily built d-i images), use http://cdimage.debian.org/cdimage/daily-builds/etch_d-i/arch-latest/arch/iso-cd/ pgpA12p6moYw7.pgp Description: PGP signature
[D-I] mass kernel udeb update and preparations for RC1
(Reply-to set to debian-boot; please only add relevant port if needed.) Dear (d-i) porters, First mass upload of kernel udebs = Today I have uploaded kernel udeb updates to 2.6.17-9 _for all arches_. This is the first time using the 'massbuild' [1] script I wrote recently. Effectively this means that d-i porters won't really have to worry anymore about updating kernel udebs after uploads by the kernel team. Only if the kernel major/minor changes will I request porters to do the upload themselves. For stable releases (including ABI changes) I intend to do these mass builds and do the uploads myself. Hopefully this will help the speed with which kernel udebs are updated and allow you all to spend more time testing d-i ;-) Of course porters are still responsible for maintaining which modules will be included for each arch/flavor. If you have changes between kernel major/minor releases you can either commit them and upload, or commit them as UNRELEASED and they will be automatically included in the next mass build. The massbuild script can be used for single-arch builds too. Its main advantage is that kernel images don't need to be installed and the certainty that the correct kernel version will be used. Feel free to contact me to help you get started. Some comments on today's upload: - I have used the last released version of kernel-wedge and will normally do that in the future too - I have not really checked or tested the udebs [2], so there could be some surprises; please be alert for them - m68k: I had to update the dependencies from kernel-image to linux-image The road to RC1 === We are slowly moving towards RC1. I plan to post an initial planning later this week. As we get closer to Etch, testing the installer for all arches gets to be more important. Any time you can spend on that is very much appreciated. There are some issues that need attention: * type of initrd used Some arches have already switched to using initramfs for d-i initrds, other arches are still using cramfs or ext2. Please check if a change could/should be made for your architecture. * 2.4 support now officially dropped Starting with RC1 d-i will no longer support 2.4 based installations. All arches have been switched now and some cleanup has been started; more cleanup is expected and this may cause unexpected breakage. * support for non-devfs device names Colin Watson has committed a series of changes to make d-i support non-devfs device names. We will be slowly moving away from using devfs names, but the most intrusive work will be postponed until after Etch. Please check for unexpected breakage though. * partman-auto using LVM and crypto partman-auto-lvm now has been available for some time, but is still not available for all arches. LVM support is a prerequisite for partman-auto-crypto support which will be uploaded soon. Note: swap on LVM should be possible now and is even required for partman-auto-crypto. If you would like to add support for it, please see [3]. Feel free to contact me or David Härdeman (Alphix) for help. * mips: keyboard issues We've had a report about a dead keyboard on installation (#382983). This needs to be investigated. * powerpc: oldworld boot problems with recent kernels If there are other architecture specific issues that we should be aware of, please let me know. Cheers, FJP [1] http://svn.debian.org/wsvn/d-i/people/fjp/massbuild?op=filerev=0sc=0 [2] The script does have a number of sanity checks though. [3] http://lists.debian.org/debian-boot/2006/01/msg01054.html pgpWefAnbx6D7.pgp Description: PGP signature
[D-I] Switching initrd filesystem (was: mass kernel udeb update and preparations for RC1)
On Friday 22 September 2006 16:39, Grant Grundler wrote: I didn't see anything for parisc (HPPA). I don't know of any problems with initramfs on parisc. but I don't expect any surprises from the kernel on that. Maybe I was not clear enough on this. The original text was: * type of initrd used Some arches have already switched to using initramfs for d-i initrds, other arches are still using cramfs or ext2. Please check if a change could/should be made for your architecture. The default is: config/common:59:INITRD_FS = ext2 $ wcgrep INITRD_FS config/hppa nothing This means that all hppa d-i initrds currently use the default ext2 filesystem. The question was: should hppa be switched to using initramfs instead of ext2 for Debian Installer images? Whether this is possible depends amongst others on what the bootloaders used for different installation methods support. Note that using intramfs has some advantages as can be seen from these changelog entries from Joey for i386/amd64: * Remove root=/dev/ram from syslinux configs, turns out not to be needed for the kernel to find initramfs. * Remove ramdisk_size= and rw settings, also not needed. The same goes for other architectures: alpha: uses default ext2 arm/armeb: most subarches use cramfs ia64: uses cramfs m68k: uses default ext2 mips: uses cramfs mipsel: uses cramfs (except bcm947xx/netboot/firmware.cfg: jffs2) sparc: uses default ext2 i386, amd64, powerpc and s/390 already use initramfs as default. pgpCLdRRp218m.pgp Description: PGP signature
Re: Need Help In Install debian on s390
On Thursday 05 October 2006 08:45, Shrirang B Kulkarni1 wrote: i want to install Debian (With 2.6 kernel) on z/VM guest image. But i am not able to find kernel.debian, initrd.debian, parmfile.debian. plz can someone help in same from where i can download same ... This page: http://www.debian.org/devel/debian-installer has links to download locations for both the stable release of Debian and for the upcoming Etch release. Cheers, FJP pgpfs81GSEBae.pgp Description: PGP signature
Debian Installer - Call for testing *this week*
(Please reply to the debian-boot list.) Preparations for Release Candidate 1 of the installer have now really started. All important functional changes are now included in the daily images. In order improve the quality of the release and reduce the number of nasty surprises afterwards, it would be great if we could get some help testing the installer during *this week*. Please make sure you use one of the _daily built_ images available from: http://www.debian.org/devel/debian-installer/ or http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/ and file an installation report with your findings: http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#submit-bug See this wiki page for a general overview of the planned release, including known issues: http://wiki.debian.org/DebianInstaller/EtchRC1Prep Testing the installer for your favorite architecture(s) === This is the main focus for this call for testing. Please let us know if there are any important issues, especially regressions from previous releases. If you can, try different installation methods. Note that the installer still uses 2.6.17. Main reason is that 2.6.18 is not yet ready to migrate to testing and switching to 2.6.18 would therefore block RC1 of d-i. Depending on the kernel team and RMs, we may still switch to 2.6.18 before RC1, but switching immediately afterwards looks more likely. Other things to test There is a number of other things that could be tested, mostly new functionality that was added recently: - graphical installer, especially whether your mouse and touchpad work correctly - crypto support in partman: the installer now has crypto support both for guided [1] and manual [2] partitioning; thorough tests, including of the actual security of the installed system, very, very welcome - automatic raid partitioning (preseeded only [1]) - 2.6 based installation floppies for i386 - support for non-standard filesystems (i.e. anything other than ext3) - if you speak a language other than English, consider installing in that language; note that one last round of translation updates is still planned, but reports of issues are still appreciated TIA, Frans Pop [1]http://d-i.alioth.debian.org/manual/en.i386/ch06s03.html#di-partition [2]http://d-i.alioth.debian.org/manual/en.i386/ch06s03.html#partman-crypto [3]http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-partman-raid pgp21MVeeUfV2.pgp Description: PGP signature
Re: Is broken Etch current on S/390 a known problem?
Hello Adam, On Friday 03 November 2006 20:47, Adam Thornton wrote: I tried a few days ago to install Etch on an s390 system, and failed to partition my DASD because kernel modules appropriate to the installer kernel level weren't found. I presume this is a known issue that will be resolved when RC1 rolls out and is just version skew between testing and the installer, but I wanted to ensure that it was known to be a current problem. I did not try building a daily snapshot of the installer--at this point my S/390 box is a Flex-ES emulated solution and it's very painful to do compilation on it. Yes, it is known: http://www.debian.org/devel/debian-installer/News/2006/20061017 Please use daily built images in the mean time. Cheers, FJP P.S. I hope to be able to look into #396228 soon (unless Bastian Blank picks it up first). pgpbR95ZWShMJ.pgp Description: PGP signature
Re: No kernel modules - 2.6 kernel on s390
On Friday 10 November 2006 14:16, Shrirang B Kulkarni1 wrote: No kernel modules were found. This probably is due to a mismatch between the kernel used by this version of the installer and the kernel version available in the archive. See http://www.us.debian.org/devel/debian-installer/News/2006/20061017 Cheers, FJP pgp4M4JI6JV3O.pgp Description: PGP signature
[D-I] Please update kernel udebs to 2.6.18-6
We are ready to make the switch to 2.6.18 for Debian Installer. For most architectures the 2.6.18-6 (ABI -3) should now be available in unstable. Please update the kernel udebs for your architecture ASAP. Cheers, FJP pgpA6QxMZLWGC.pgp Description: PGP signature
Re: Who is actively porting the Debian architectures?
On Wednesday 27 December 2006 10:48, Bastian Blank wrote: On Mon, Dec 25, 2006 at 11:40:02PM +0100, Frans Pop wrote: S/390: add Bastian Blank S/390: remove Gerhard Tonn, he stepped back Updated, thanks. pgpkRKhsEqwzh.pgp Description: PGP signature
[D-I] Last chance to update the Installation Guide for Etch
Hello porters, I've just announced the schedule [1] for the release of the Installation Guide to be included with the Etch release. That schedule leaves room for bigger updates until Dec 31 and for minor ones until Jan 7. This means that if you have any updates you'd like to get in for your port, there is not much time left. From Jan 1, please consult before directly committing any updates (or send patches). My apologies for not sending out a reminder earlier. Cheers, FJP [1] http://lists.debian.org/debian-boot/2006/12/msg01492.html pgp0BZaomfNOP.pgp Description: PGP signature
D-I RC2 - Revisited
Hi all, As you've probably noticed, what's intended to be the final kernel for Etch has been uploaded yesterday. I'm currently building and uploading the kernel udebs for all arches (except arm and m68k for which images are not yet available). I'll also upload new loop-aes module udebs for Sparc as those were binNMUed because of a silent ABI change for sparc32. This means we can also have another go at releasing RC2. As this weekend is Fosdem and as we have to wait until the kernel is ready to migrate anyway, I will start the release process for RC2 early next week. This will include a last upload of udebs with translation updates and a few with minor pending changes. It also means that this is the last chance to make any (important) changes before RC2. If there is anyting that still needs to be done before RC2 (either general or architecture specific), please met me know by replying to the debian-boot list. Note that after RC2 has been released, it will in principle *no longer be possible* to migrate to testing packages that produce udebs if those udebs are included in any D-I initrd. I will check with RMs if there's anything in the pipeline before starting the build and upload of the installer. Cheers, FJP pgpm4A9uunlfc.pgp Description: PGP signature
[D-I] Updating kernel udebs to 2.6.20
Hello D-I porters, Most architectures should now be able to switch to 2.6.20 for D-I (except for arm, hppa and m68k). i386 and amd64 have already been switched. Over the past two weeks Joey has done the needed work for i386 and amd64 (and necessary updates in kernel-wedge), but we've waited with this call until #419458 was resolved (which it was in 2.6.20-3). As this is a fairly big jump (2.6.18 to 2.6.20), please check carefully for new modules that should be included in the udebs. If any updates in kernel-wedge are needed, please let us know (or do them yourself). I suggest that you check the kernel-wedge changelog for an overview of the changes made there. Please also check pending changes already committed in SVN by Joey or me. Note that although new PATA modules were added in kernel-wedge, most of these are not actually available yet in the kernel as a result of #419458. After you upload the new linux-kernel-* package, I will make sure that the linux-modules-* (loop-aes modules) will also be uploaded for your architecture. For mips(el): In input-modules for bcm* kernels, usbmouse is currently included. AFAIK that module should not be needed and that module could be removed. Cheers, FJP pgpkOSQUPZ2jl.pgp Description: PGP signature
Re: Error Writing Partition Changes to DASD
On Tuesday 22 May 2007 19:10, Adam Thornton wrote: On May 22, 2007, at 11:21 AM, Rod Clayton wrote: Error informing the kernel about modifications to partition /dev/dasda5 -- Invalid argument. This means Linux won't know about any changes you made to /dev/dasda5 until you reboot -- so you shouldn't mount it or use it in any way before rebooting. AFAIK, the CKD driver only supports 4 devices per partition. In the S/390 world, you generally use 1 per partition and define additional devices, particularly under VM. Please file a bug report against partman-base for this issue. It should probably check that the maximum number of partitions supported by the disk label/partition table is not being exceeded. Not sure yet if this is an issue in partman or libparted. pgpqC66vUhpfB.pgp Description: PGP signature
Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck
tags 445148 confirmed reassign 445148 s390-tools thanks Install boot went as expected, up until the first re-boot. After rebooting, system fails in fsck because one of the partitions is already mounted. Configuration is a 125 cylinder /dev/dasda1, which is to be mounted as /boot, and a large /dev/dasdb1 which is to be mounted as /. fsck fails for dasda1, but I don't see anywhere that dasda1 is mounted. mount /boot says that it's already mounted or dasda1 is busy, and umount /boot says it isn't mounted. I have reproduced the issue. This does not seem to be an installation problem. Instead it looks like either the boot loader or the kernel is not releasing the partition holding /boot after the kernel and/or the initrd have been loaded. I'll send a mail to the linux-s390 mailing list to ask for help with this. The workaround is easy: - enter the administrator password when requested - type 'exit' when in the root shell; this will complete the boot process - edit /etc/fstab and change the value in the column pass for the /boot partition from 2 to 0 to exclude it from fsck during future boots I must say that I'm not sure what the benefits would be of having a separate /boot partition on s390, but this still seems like a bug that should be resolved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445148: fsck during system boot fails with separate /boot partition
On Monday 08 October 2007, Peter 1 Oberparleiter wrote: Judging from the data found in the bugtracker, this sounds more like a setup problem: That was my initial thought as well. However, I could reproduce the issue without any problems during a new installation in Hercules. I got exactly the same fsck error during boot and I'm fairly sure there are no configuration errors as I checked several times both during and after the installation. - /etc/fstab is correct - except for the fsck failure, the system boots correctly - if pass in /etc/fstab is set to 0 for /boot, the system boots without any problems I have also verified that, while in maintenance mode after the fsck failure, both mount and /proc/mounts really do not show /dev/dasda1 mounted. Only / (/dev/dasdb1) is shown as mounted at that point, as you'd expect. DF shows that /dev/dasda1 is 5G while a dasd with 125 cylinder should be around 80-90MB. That df output (and the whole hardware summary) is almost certainly from his second, successful install where he did *not* use a separate /boot partition. Otherwise /boot would also have been listed there (as it is for my own installation). Confusing, but not relevant. I'm convinced there's a real bug here. Cheers, Frans Pop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445148: Fwd: Re: Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck
-- Forwarded Message -- Subject: Re: Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck Date: Monday 08 October 2007 I must say that I'm not sure what the benefits would be of having a separate /boot partition on s390, but this still seems like a bug that should be resolved. Our standard layout is to have a small /boot, and then use LVM for a system VG and a local VG. System contains root, var, tmp and local contains home and any application specific paths. This way, the individual paths can increased in size easily, just by adding a new ninidisk, and then assigning it to the proper VG and LV. In this scenario, /boot still needs to be an actual first level partition, so that the boot loader can find its files. --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445148: fsck during system boot fails with separate /boot partition
On Monday 08 October 2007, Peter 1 Oberparleiter wrote: This might indicate a timing problem - the init script tries to mount a DASD that has not yet been fully initialized by the kernel (the return code -EBUSY that triggers the already mounted message may indicate different problems). Try to add a sleep 5 into the init script just before the mount command that fails to check if this is the case. I've found the root of the problem. It's a configuration problem after all. We currently do not add the 'dasd=' parameter to the kernel boot arguments. Instead, we let udev assign device names. Because of the 'root=' parameter (in which we use a by-path device name), the first dasd that is detected in my test is 0123, which ends up as dasda and thus 0122 ends up as dasdb, effectively swapping the two dasds. And as we still use the classic device names in /etc/fstab, the result is chaos. The confusion came from the fact that mount still lists / mounted as /dev/dasd_b_1, even if it is actually mounted as /dev/dasd_a_1. So, fsck is completely correct in reporting /dev/dasda1 as already mounted. It also means that when /boot is mounted later, it's not actually the boot partition that is mounted, but it is the root partition that is mounted (for a second time) on /boot. Adding the dasd= boot parameter did not help - it seems to be ignored in our initrds; changing /etc/fstab to use /dev/disk/by-path devices consistently does result in a correct boot. I'll consult with other Debian people how we want to resolve this. Thanks very much for your replies, which did help in straightening this out for me. Cheers, Frans Pop -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck
severity 445148 serious reassign 445148 debian-installer 20070308 thanks On Monday 08 October 2007, Frans Pop wrote: This does not seem to be an installation problem. Instead it looks like either the boot loader or the kernel is not releasing the partition holding /boot after the kernel and/or the initrd have been loaded. It is an installation problem after all. Basically, on boot the dasds for / (LVM) and /boot are swapped. See [1] for a detailed analysis. The correct repair for the issue is as follows: - enter the administrator password when requested - type 'exit' when in the root shell; this will complete the boot process - edit /etc/fstab and use /dev/disk/by-path device names for _all_ partitions, for example (check /dev/disk/by-path for correct names): # file system mount point type options dump pass proc /proc procdefaults 0 0 /dev/disk/by-path/ccw-0.0.0123-part1 / ext3defaults,[...] 0 1 /dev/disk/by-path/ccw-0.0.0122-part1 /boot ext3defaults 0 2 /dev/disk/by-path/ccw-0.0.0122-part2 none swapsw 0 0 - reboot To the D-I team --- This is a fairly difficult issue as there is not really an easy solution or an obvious D-I component that is the culprit (to mind come s390-dasd, partman-target, udev-udeb, initramfs-tools and zipl-installer). Therefore assigning to d-i itself. This issue should IMO definitely be listed in the errata for Etch. I also think the issue is broader than just this use case. Basically any setup that has / on a different dasd than the first one configured in s390-dasd is broken. AFAICT any setup in which during s390-dasd dasds are configured in a different order than their numeric sort order, will *also* be broken as their device names after reboot will be different from what they were during installation. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=58;bug=445148 signature.asc Description: This is a digitally signed message part.
Bug#445148: S390: Build w/ /boot partition succeeds, but re-boot fails in fsck
severity 445148 serious reassign 445148 debian-installer 20070308 thanks On Monday 08 October 2007, Frans Pop wrote: This does not seem to be an installation problem. Instead it looks like either the boot loader or the kernel is not releasing the partition holding /boot after the kernel and/or the initrd have been loaded. It is an installation problem after all. Basically, on boot the dasds for / (LVM) and /boot are swapped. See [1] for a detailed analysis. The correct repair for the issue is as follows: - enter the administrator password when requested - type 'exit' when in the root shell; this will complete the boot process - edit /etc/fstab and use /dev/disk/by-path device names for _all_ partitions, for example (check /dev/disk/by-path for correct names): # file system mount point type options dump pass proc /proc procdefaults 0 0 /dev/disk/by-path/ccw-0.0.0123-part1 / ext3defaults,[...] 0 1 /dev/disk/by-path/ccw-0.0.0122-part1 /boot ext3defaults 0 2 /dev/disk/by-path/ccw-0.0.0122-part2 none swapsw 0 0 - reboot To the D-I team --- This is a fairly difficult issue as there is not really an easy solution or an obvious D-I component that is the culprit (to mind come s390-dasd, partman-target, udev-udeb, initramfs-tools and zipl-installer). Therefore assigning to d-i itself. This issue should IMO definitely be listed in the errata for Etch. I also think the issue is broader than just this use case. Basically any setup that has / on a different dasd than the first one configured in s390-dasd is broken. AFAICT any setup in which during s390-dasd dasds are configured in a different order than their numeric sort order, will *also* be broken as their device names after reboot will be different from what they were during installation. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=58;bug=445148 signature.asc Description: This is a digitally signed message part.
Bug#481421: nfs-common: [s390] mounting nfs4 file system fails with 64-bits kernel
Package: nfs-common
Version: 1:1.1.2-4
The Debian s390 port has a 32-bit userland, but has both a 32-bit (-s390)
and a 64-bit (-s390x) kernel.
If I try to mount an nfs4 file system using the 32-bit kernel all is OK, but
when I do the same with the 64-bit kernel it fails as follows:
# mount -t nfs4 elrond.fjphome.nl:/project /srv/project
mount.nfs4: an incorrect mount option was specified
An strace is attached for both kernels.
System is the Hercules S/390 emulator running Debian unstable; Debian kernel
2.6.24-6 (upstream 2.6.24.4).
Cheers,
FJP
1647 execve(/bin/mount, [mount, -t, nfs4,
elrond.fjphome.nl:/project, /srv/project], [/* 20 vars */]) = 0
1647 brk(0)= 0x412000
1647 uname({sys=Linux, node=mordor, ...}) = 0
1647 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
1647 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x77fe2000
1647 access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
1647 open(/etc/ld.so.cache, O_RDONLY) = 3
1647 fstat64(3, {st_mode=S_IFREG|0644, st_size=17245, ...}) = 0
1647 mmap(NULL, 17245, PROT_READ, MAP_PRIVATE, 3, 0) = 0x77fdd000
1647 close(3) = 0
1647 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
1647 open(/lib/libblkid.so.1, O_RDONLY) = 3
1647 read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\26\0\0\0\1\0\0-\310\0\0\0004\0\0\254|\0\0\0\0\0004\0
\0\5\0(\0\31\0\30\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\241T\0..., 512) = 512
1647 fstat64(3, {st_mode=S_IFREG|0644, st_size=45156, ...}) = 0
1647 mmap(NULL, 48080, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x77fd1000
1647 mmap(0x77fdc000, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0xa000) = 0x77fdc000
1647 close(3) = 0
1647 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
1647 open(/lib/libuuid.so.1, O_RDONLY) = 3
1647 read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\26\0\0\0\1\0\0\23p\0\0\0004\0\0B\254\0\0\0\0\0004\0
\0\6\0(\0\33\0\32\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0?\\\0\0..., 512) = 512
1647 fstat64(3, {st_mode=S_IFREG|0644, st_size=18148, ...}) = 0
1647 mmap(NULL, 16880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x77fcc000
1647 mmap(0x77fd, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0x77fd
1647 close(3) = 0
1647 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
1647 open(/lib/libselinux.so.1, O_RDONLY) = 3
1647 read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\26\0\0\0\1\0\0J\374\0\0\0004\0\1\262\370\0\0\0\0\0004\0
\0\7\0(\0\32\0\31\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\1\256..., 512) = 512
1647 fstat64(3, {st_mode=S_IFREG|0644, st_size=112392, ...}) = 0
1647 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
= 0x77fcb000
1647 mmap(NULL, 117572, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x77fae000
1647 mmap(0x77fc9000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1a000) = 0x77fc9000
1647 close(3) = 0
1647 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
1647 open(/lib/libc.so.6, O_RDONLY) = 3
1647 read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\26\0\0\0\1\0\1\207\274\0\0\0004\0\25\330\0\0\0\0\0004\0
\0\n\0(\0D\0C\0\0\0\6\0\0\0004\0\0\0004\0\0\0004\0\0\1@..., 512) = 512
1647 fstat64(3, {st_mode=S_IFREG|0755, st_size=1388920, ...}) = 0
1647 mmap(NULL, 1397704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0x77e58000
1647 mmap(0x77fa8000, 12288, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x14f000) = 0x77fa8000
1647 mmap(0x77fab000, 9160, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x77fab000
1647 close(3) = 0
1647 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
1647 open(/lib/libdevmapper.so.1.02.1, O_RDONLY) = 3
1647 read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\26\0\0\0\1\0\0:\364\0\0\0004\0\1\207\4\0\0\0\0\0004\0
\0\5\0(\0\31\0\30\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\1n\34\0..., 512) = 512
1647 fstat64(3, {st_mode=S_IFREG|0644, st_size=101100, ...}) = 0
1647 mmap(NULL, 99964, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0x77e3f000
1647 mmap(0x77e56000, 8192, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x77e56000
1647 close(3) = 0
1647 access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
1647 open(/lib/libdl.so.2, O_RDONLY) = 3
1647 read(3,
\177ELF\1\2\1\0\0\0\0\0\0\0\0\0\0\3\0\26\0\0\0\1\0\0\v\354\0\0\0004\0\0001\200\0\0\0\0\0004\0
\0\t\0(\0\35\0\34\0\0\0\6\0\0\0004\0\0\0004\0\0\0004\0\0..., 512) = 512
1647 fstat64(3, {st_mode=S_IFREG|0644, st_size=13832, ...}) = 0
1647 mmap(NULL, 16556, PROT_READ|PROT_EXEC,
Re: FCP problem on Debian s390 hardware
Please do not start two separate threads for basically the same question/problem in two days! Shrirang Kulkarni wrote: Steps 1. chccwdev -e 0.0.b001 2. echo 0x5005076305080310 /sys/bus/ccw/devices/0.0.b001/port_add 3. echo 0x40104001 /sys/bus/ccw/devices/0.0.b001/0x5005076305080310/ enabled all SCSI devices of FCP 4. cd /sys/bus/ccw/devices/0.0.b001/0x5005076305080310/ 5. /sys/bus/ccw/devices/0.0.b001/0x5005076305080310 # ls 0x40104001 0x4010400b 0x40104015 0x4011400a 0x40114014 0x4011401e 6. So able to see all devices on FCP and made partions and mounted able to use in Debian Linux 7. I tried to create initrd as new devices added by mkinitrams -o initrd.img-2.6.18-6-s390 2.6.18-6 8. But when i reboot machine No FCP devices detected. Once again I need repeat 1-6 steps for FCP to get enable Right, so you enabled things manually on one boot and now expect them to somehow magically be enabled on the next boot too, without laying anything down in configuration. Seems to me you are making some flawed assumptions here about how things are supposed to work... Please take a look at the sysconfig-hardware package. That is the tool intended to set up devices at boot on s390 based on info from /sys. Quite probably it will need some extentions to support FCP, but I think it should be relatively straightforward. If you figure out what/how, please send a patch (by opening a wishlist bug report against the sysconfig-hardware package with the problem description and patch)! Cheers, FJP signature.asc Description: This is a digitally signed message part.
Re: Lenny installer hanging?
Ivan Warren wrote: The question is : would it be possible to have a more recent DI build for s390 (more recent than October 27th 2008) - and especially with a newer kernel ? You could try a daily built image from [1], which uses 2.6.26-12 (current unstable/testing kernel based on upstream 2.6.26.8). note that 2.6.25 might be an issue. Hmmm? The Lenny RC1 image also uses 2.6.26, though based on a somewhat older upstream stable update. So .25 cannot be an issue here. PSF/PRSSD issue that's of some concern to me) 2.6.26 version updated by Frans Pop should be fine.. and 2.6.27 shouldn't have any problem) 2.6.27 is likely to get skipped for Debian as the kernel will not be updated until after Lenny is released and that will certainly be with 2.6.26. Cheers, FJP [1] http://www.debian.org/devel/debian-installer/ signature.asc Description: This is a digitally signed message part.
Re: Problem on Instalation of Debian Lenny
On Thursday 09 July 2009, Frans Pop wrote: I can confirm this. If I install the Lenny kernel on an already installed Hercules system (running unstable) I also get the panic, so it clearly is a kernel issue, not an installer issue. But it will definitely need to be investigated, but this will take time. I'll see what I can do myself. I'll start with filing a bug report against the kernel for this issue. http://bugs.debian.org/536354 I'll file a bug report against the installer for the bad signature problem so Etch installs can be fixed. http://bugs.debian.org/536353 -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problem on Instalation of Debian Lenny
Hi, On Thursday 09 July 2009, Shrirang Kulkarni wrote: I am trying to install kernel 2.6 version from yesterday none of the mirrors are working If you really want help from people on a Debian mailing list, you will really need to improve the way you ask your question... 1) Do not hijack an existing thread for an unrelated question! Do not reply to an existing mail, but send a new mail. 2) Do *not* CC individual people, only mail the list! See the Debian mailing list code of conduct [1]. 3) Preferably do not use top posting when you reply to a mail [2]. 4) Don't ask vague questions: they cannot be answered. * kernel 2.6 version from yesterday - what version exactly? - what debian release are you running (stable, testing, unstable)? - is it a security update or a regular package version? * none of the mirrors are working - that is *extremely* unlikely - which mirrors did you actually try? * what exact commands did you use? * what exact errors did you get? Make sure any output you include is in English! Can someone help me on same? No sorry, I cannot help you because I really don't have a clue what your actual problem is. I understand that asking a question in a different language than your own can be difficult, but please spend some extra time to make your problem clear to the people you ask for help. Try to avoid wasting *their* time! And the most likely result is that you don't get an answer at all. Cheers, FJP [1] http://www.debian.org/MailingLists/#codeofconduct [2] http://www.caliburn.nl/topposting.html -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Lenny: Unable to mount initrd
(No need to CC me.) On Monday 03 August 2009, Peter Senna Tschudin wrote: How can I check if the kernel supports ext2, ext3 and cramfs? Looks like it does not... $ cat /proc/filesystems But note the the installer will only get some file system modules available when additional installer components are loaded in the step after a mirror has been selected. The initrd is an initramfs (compressed cpio archive) and thus does not require any of these file systems, and thus they may not be enabled/included in the generic kernel and initrd. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
Marco d'Itri wrote: On Aug 31, Bastian Blank wa...@debian.org wrote: I doubt that I would be able to push this port through another release in the current state. The consequence would by that the port dies completely and with it the only free and released distribution for this machines. Is this really an important problem? Does a significant number of people actually use Debian/s390 on production servers? That's hard to say, but I've seen 4 or 5 separate reports from people who've wanted to install stable on s390 systems in the past 2 months [1]. That was more than I'd expected for s390. Cheers, FJP [1] We got the reports because the stable kernel for s390 was broken. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Problem on Instalation of Debian Lenny
On 8 Juli 2009, Fernando Gieseler wrote: Well, I trying install Debian Lenny on System z behavior z/VM. The first attempt was: I downloaded the essentials files from the official mirror ftp server (ftp://ftp.debian.org/debian/dists/lenny/main/installer-s390/current/im ages/generic/) but, the message [17179570.468526] Kernel panic - not syncing: Attempted to kill init! was displayed and the installation stop. With the stable point release that's now available from the mirrors, s390 should be installable again for Lenny. Note that new CD images with the fixed version will only become available sometime in the next few days. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Trying To Get Started
First of all, when you ask a question on a mailing list, please always follow up to that mailing list instead of replying to the person who replied to you. On Wednesday 23 September 2009, Martin, Larry D wrote: I downloaded 5.0.3 from mirrors.usc.edu and that seemed to work fine. I then burned CD1 (using Easy CD Creator). I then use the HMC and Load from CD/ROM. I get the following: [17179570.168401] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) Can I not use this technique to install Debian? What is the proper methodology? I have just confirmed that booting from CD does not work. We'll have to look into that. As I said in my previous mail, it is a rather unusual installation method (only confirmed by the fact that nobody reported it is broken, and has been for quite some time). Please use the generic images I linked to in my previous mail instead. Unfortunately I cannot give you detailed instructions myself on how exactly to use them as I'm only familiar with the Hercules emulator [1] and not with real hardware. Cheers, FJP [1] On hercules it is done by defining a '3505' type device as kernel.debian parmfile.debian initrd.debian autopad eof and IPLing off that. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[RFH] Installer fails to boot from CD
Hi all, As reported yesterday by Larry Martin, Debian Installer fails to boot from CD on s390. I worked on that early in the Etch release cycle [1] and when it was implemented in debian-cd it worked fine. But if I now try an Etch image, that fails as well. The problem seems to be that it fails to recognize the initrd and thus fails to mount the root fs. From a boot from an Etch CD: snip checking if image is initramfs... it isn't (bad gzip magic numbers); looks like an initrd [...] RAMDISK: Compressed image found at block 0 No filesystem could mount root, tried: ext3 ext2 cramfs Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) /snip I've looked at the changes during Etch, and the most likely cause of the failure is that later in the Etch cycle we switched from an ext2 initrd to initramfs. The way we boot from CD is by IPLing d390.ins, which has: $ cat d390.ins * Debian GNU/Linux for S/390 (boot from CD-ROM or FTP-Server) linux_vm 0x parmfile 0x00010480 root.bin 0x0080 linux_vm is identical to generic/kernel.debian; root.bin is identical to generic/initrd.debian (and is a valid initramfs). If I create a 3505 (RDR) device in Hercules with linux_vm parmfile root.bin autopad eof the identical images boot correctly. Does anyone know how to set up the CD correctly for booting using an initramfs? Cheers, FJP [1] http://bugs.debian.org/318021 signature.asc Description: This is a digitally signed message part.
Re: Problem on Instalation of Debian Lenny
STEPHEN POWELL wrote: Hmm. These are the same symptoms as Debian bug report number 523942. Does that mean that stock kernel image linux-image-2.6.26-2-s390 version 2.6.26-19 will work for me? Current stable kernels should work fine. Don't ask me why the version created by make-kpkg works but the stock kernel image doesn't work, but that's how I've been circumventing the problem. I'd really like to get back to a stock kernel if I can. Probably because you use a different compiler version. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Future of the s390 port
Stephen Powell wrote: I shall be happy to do all of the above. I do have access to a real mainframe. It's a z/890 (2086). It's not one of the newest machines. It's not a z9 or z10. But it is 64-bit. And I do have a spare LPAR I can test with. And yes, I do know how to IPL Linux in an LPAR from CD. I don't know how to create an ISO image that the mainframe considers bootable; but if you point me to an ISO image I can burn a copy onto CD and IPL the thing and let you know if it came up OK. That would be great. Please see [1] for details. If you need additional info, just ask. Cheers, FJP [1] http://lists.debian.org/debian-s390/2009/09/msg00027.html -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian for S390 (lenny ) installation problem
Mike Kirjanov wrote: 1. We are trying to install Debian for S390 (lenny ) distribution on the virtual machine (via z/VM 5.4 on the real mainframe ) and via Hercules 3.05 on the Linux Intel box. All our attempts is ended with the WARNING **: bad d-i Packages file message. We are using local repositories of the 5.0.3, 5.0.2 (stable ) and unstable verion (12.10.09 ) via http/ftp protocols. We are doubt what is wrong ? All our attempts to install the previous version of the Debian for S390 (etch ) were successful and we hadn't any installation problems at all. As far as I know installing Lenny with current images should work fine. It sounds as if your local repository is invalid, incomplete or corrupt in some way. Have you tried installing using official mirrors? Can you send us the system log (/var/log/syslog) for the installation? Maybe we can get additional info from that. Please make sure you gzip the syslog. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installation Question
Martin, Larry D wrote: Does anyone know if the problem installing Debian on zSeries from CD-ROM has been corrected? Yes, it has. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Minidisk support (was: Installation Question)
(No need to CC me; I read the list; see the Debian mailing list policy.) Hello Stephen, A few misconceptions in your mail. Let me try to correct them and offer some advise on who to proceed. But first of all: please don't hijack an existing thread for an unrelated issue; next time, please just start a new thread instead. On Monday 14 December 2009, Stephen Powell wrote: Given the low frequency of stable release updates, You are mixing two different things in this mail: - the next stable release (Squeeze) - the next update (point release) for the existing stable release (Lenny) The rules, limitations and methods for getting changes included are completely different for them, and you should clearly separate between them. perhaps I should ask if the fix for Debian bug #550898 is scheduled to be The people to ask are the kernel team. And for inclusion in a stable update, you may need to specifically need to make the person within that team who takes care of preparing those updates (Dan Frazier) aware of the issue. Bastian Blank as kernel team member and s390 porter would be a logical person to drive this, but possibly he does not personally think the issue important enough to get involved. I don't know. included in the next update, both in the Debian installer and in the regular stock kernels. There is no difference between regular and D-I kernels, especially not for the next stable release. D-I merely repackages the regular kernel into udebs it does not build its own kernels. So, any change included in the regular kernels almost automatically gets included in the installer (except when it requires additional new kernel modules to be included, which is not the case here). For stable updates it is a bit different as not every point release includes an update of the Installer, and even if the installer is updated, it does not necessarily include a kernel update. This fix is an s390/s390x-specific fix. An upstream developer promised me that he would get this fix in the next kernel release, which at the time was going to be 2.6.33. Right. The fix (22825ab7) _is_ now in mainline, which means your chances of getting this included in Debian Squeeze has just increased from 10% to about 98%. And the chance to get it included in Lenny from 0% to 20%. Why? Simple. The kernel team policy is to only include patches that already have been accepted upstream or look certain to get included upstream very soon. For stable updates added criteria are: - it must fix an important *bug* (affecting a significant number of users), or - it must be an enhancement that is very important to a significant number of users *and* has no risk of introducing regressions. This patch is IMO more an enhancement than a bug fix, so I'm not certain it qualifies for a stable update. But since stable Debian releases tend to go with even numbered kernel releases, the earliest upstream That is a totally random deduction based on nothing else than coincidence for the last few releases. There is no difference between odd and even upstream releases, so no reason for Debian to prefer even ones. The choice of kernel version is mostly a timing issue (when is the upstream release relative to Debian's freeze date) and possibly what kernel other distributions use for their releases (so we can profit from long term maintenance of that kernel release). version which contains this fix that Debian actually uses is likely to be 2.6.34. So this is nonsense. That might not even be available in Squeeze. I'd really like to see this fix in production as soon as possible. I don't know what the kernel team are currently planning for Squeeze: .32 or .33. It depends a lot on when Debian actually freezes. I guess .32 is more likely than .33, but .33 is a possibility. Now, assuming that it will be .32, how can you get this fix that's been included upstream in .33 included in Debian? By far the best way is to try to get *upstream* to include the patch in one of their stable updates for .32, so in 2.6.32.1 or 2.6.32.2. I would suggest proposing that on the linux-s390 mailing list. If that does not happen, you can try asking the Debian kernel team to backport the fix to .32. The way to do that is: - follow up to the bug report - include a link to the upstream commit in .33 (this is essential!) - get the attention of the kernel team: keep following up regularly and ask (politely) if someone has had a chance to consider this To get the patch included in a Lenny point release you need to do the same, but with the following additional things: - provide a solid rationale why this is an important change for Lenny - check whether or not the upstream patch applies to the current Lenny kernel - if it does, test it thoroughly - if it does not, provide a backported patch after testing that thoroughly - make sure the maintainer for the stable kernel is aware of the issue As mentioned before, I'm not sure
Re: Minidisk support (was: Installation Question)
On Monday 14 December 2009, Frans Pop wrote: Stephen Powell wrote: I *did* ask the kernel team. Yes, and I gave several reasons that could explain why they may not have replied. P.S. I never meant to imply that anything you did was wrong. I was just trying to explain why it was not effective. Obviously it would have been much better if the kernel team had replied to your bug report themselves. But things become much easier if you try to look at things from their PoV. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
Stephen Powell wrote: When I click on reply, the To field is pre-filled-in with the poster's e-mail address. So, it's a limitation of *your* email client. The choice of client is up to you, but forcing its limitations on others is backwards. I don't think I understand what you are trying to say. Every DASD device which is supported by the DIAG driver, with or without the patch, is also supported by either the ECKD driver or the FBA driver. The only thing that the DIAG driver buys you that's useful is a performance boost. OK. My s390 knowledge is very limited. My understanding was that minidisks were not supported at all (as there's a longstanding BR open to add support for them in the installer). This might increase the chances of getting it accepted for Lenny, but someone will still need to do the work to prepare things cleanly for the kernel team. *If* things are presented correctly I see no reason why the kernel team would not accept it. OK, I'll try. But in exchange, I'll ask that you attempt to persuade Eh, what? Why would I have to do that? I have no special status here. the kernel team to hold off on freezing Squeeze until a kernel with this patch on it is adopted by Squeeze. There isn't much point in going through the effort to get the patch into 2.6.32 if Squeeze is going to be frozen at 2.6.30 or 2.6.31. As 2.6.32 is already in unstable and Squeeze will only freeze in March, there is zero risk of that. If that had been a realistic risk, I would have mentioned it in earlier mails. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installation Question
Martin, Larry D wrote: The S390 directory appears to me to be empty this week. Yes, unfortunately there was a build error this week (which sometimes happens for daily and weekly builds). The images should be back next Monday. There was stuff there last week (can I point to that?). Afraid not. Full CD/DVD images just take too much space to keep multiple versions around. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installation Question
Martin, Larry D wrote: The iso directory for s390 is empty (as far as I can tell) again this week. Unfortunately the server that hosts the Debian Installer images for s390 looks to be down today, which means that the server that builds the CD images could not download them and so the weekly CD build failed. There's nothing much I can do about that. Sorry for the inconvenience. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Installation Question
On Monday 21 December 2009, Frans Pop wrote: Martin, Larry D wrote: The iso directory for s390 is empty (as far as I can tell) again this week. Unfortunately the server that hosts the Debian Installer images for s390 looks to be down today, which means that the server that builds the CD images could not download them and so the weekly CD build failed. There's nothing much I can do about that. Sorry for the inconvenience. I've just created a bootable s390 CD for Lenny. You can download it from: http://cdimage.debian.org/cdimage/unofficial/fjp/ Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
RE: Installation Question
Martin, Larry D wrote: All goes well until the install asks which site I want to use. I chose ftp.us.debian.org (and a couple of others) and I get ...site either not available or does not contain a valid release... The ftp.us.debian.org mirror works perfectly for me (using the same CD). Sounds as if you don't have an internet connection because of incorrect networking setup. But that's hard to tell without knowing the actual errors. Did you already switch to using an SSH session to complete the installation, or are you still using the text interface from the console? If you're still on the console you can see them by choosing Execute a shell from the installer's main menu and typing 'cat /var/log/syslog'. If you're using SSH, you can see the syslog by starting a second session and choosing the Start shell option and then use either cat or nano to view the syslog. If you need help, please copy and paste the full syslog (if possible). -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
Stephen Powell wrote: OK, so if all three drivers support minidisks, then what is Debian bug report 447755 all about? The issue here is the *format* of the minidisk. A DASD device, be it a dedicated device or a minidisk, can have one of four formats under Linux for s390: cdl, ldl, CMS non-reserved, and CMS reserved. The FBA driver supports two of the four formats: CMS non-reserved and CMS reserved. The DIAG driver supports three of the four formats: ldl, CMS non-reserved, and CMS reserved. The ECKD driver supports all four formats. Debian installer includes 2 drivers: - dasd_fba_mod - dasd_eckd_mod The second one is the one that's normally loaded AFAIK, so that means all four formats should be supported. CMS non-reserved: Low-level formatting: CMS FORMAT command Partitioning: none (a single partition is implied) High-level formatting: mke2fs or mkswap CMS reserved: Low-level formatting: CMS FORMAT command Partitioning: CMS RESERVE command (a single partition is created) High-level formatting: mke2fs or mkswap Here's one of the reason why I cannot do anything about this: I only have access to Hercules running Linux, so I cannot create CMS formatted disks. The issue in 447755 is that the Debian installer only supports cdl format. Why? It has the eckd kernel driver which supports all four formats if I understand you correctly. The fact that you cannot do a low-level CMS format is IMO not relevant as the first thing should be to support pre-formatted disks anyway. High level formatting (partitioning and file system creation) is not an issue here. Once the basic device is recognized, that should be automatic (unless the device has a special naming convention that's not recognized by partman, but that is trivial to implement). The s390-dasd udeb takes care of identifying available channels. Are minidisks maybe not listed as ccw channels maybe, or are they of a special type? The s390-dasd C program is relatively simple: it's a state engine and all actual functionality is based in info from /sys/. So what exactly is missing there? At what point does it go wrong: is it in s390-dasd, or is it in partman? I still don't get it... And since this is the only format that the DIAG driver *doesn't* support, the DIAG driver cannot be used, even after installation, without migrating the data to other minidisks after the installation. The installer currently does not include the DIAG driver. I'm not sure why, but possibly to avoid having to choose between two different drivers supporting the same device. But if the ECKD driver really does support all formats, then shouldn't you be able to use that initially and then switch over to DIAG after the installation? If so, missing DIAG in the installer would be no huge issue. There is also another issue mentioned in 447755, and that is a problem with mounting devices in the wrong order. In hindsight, I should have created two separate bug reports: one for the lack of support for CMS minidisks and one for the mount order issue. You can still do that... I apologize for the long reply, but again; I don't know what you know and what you don't know. Well, the thing this has clarified most for me is that my original position is still correct: I cannot do anything about this as the problem is not clear. Especially without access to a CMS formatted minidisk I cannot even start to see what's missing. It also still seems to me that anybody who *does* have access to such devices should be able to implement basic support, even without much coding skills. And they could at least specify *in detail* what's missing by doing all the needed steps manually: - what kernel modules are involved? - what are the relevant files in /sys/ and what are their contents? - what must be done to activate a device? - does the kernel recognize the device (see dmesg)? - do device nodes get created for the device? - ... If a kernel module is missing, simply scp it from an installed system into the D-i environment, run 'depmod -a', modprobe it and it should work. Working on Debian Installer is not rocket science, really. As an official Debian developer, you carry more weight than I do. I can appeal to the kernel team, of course; but if you say I'm full of excrement, they'll believe you more than they will me. No really, I do not have *any* influence over this. Even the kernel team does not have that much influence over the release date. Things just slowly move towards the critical mass needed to release, and at that point only serious release critical issues can stop it. And this simply does not qualify. So what you should do is just work to get any pet issues fixed in time and not make a huge issue of things. That's exactly the same basis on which everybody works. There's *plenty* of time to get it done. You just have to make it happen. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a
Re: Minidisk support (was: Installation Question)
Stephen Powell wrote: If I were to boil the problem definition down to one sentence it would be: Partman does not recognize the pre-existing partition on disks which are pre-formatted in the CMS non-reserved format or the CMS reserved format. Right. That narrows it down a lot. Partman is almost exclusively shell script, and is because of that relatively easy to play around with. Main problem is that it's a *HUGE* amount of shell script, so the main challenge is to find the correct place in the code. This should be fairly simple to solve. Well, I'm working on it, but I'm not there yet. I am currently teaching myself bash scripting by reading online tutorials and man pages. After that, I'll probably tackle awk, perl, and sed. For this issue shell scripting (plus basic sed, find, etc.) is all that's needed. What I have is a real mainframe, a legitimate z/VM license, and a willingness to help. If you can provide me with *exact* info I need and if you can reply quickly, I may be able to add support for this. If you could provide me with access to a system that has these disks mounted that might work as well. To start with: - What device name does such a partition have? - How could it be distinguished from a partitionable dasd? Please send the replies for these questions to the BR instead of the list! -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On Thursday 24 December 2009, Frans Pop wrote: Stephen Powell wrote: Partman does not recognize the pre-existing partition on disks which are pre-formatted in the CMS non-reserved format or the CMS reserved format. Right. That narrows it down a lot. Partman is almost exclusively shell script, and is because of that relatively easy to play around with. Main problem is that it's a *HUGE* amount of shell script, so the main challenge is to find the correct place in the code. This should be fairly simple to solve. Hmmm. Possibly that info should come from libparted instead of partman itself. That would make it rather more difficult and probably beyond my skills. But we can give it a try. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Minidisk support (was: Installation Question)
On Thursday 24 December 2009, Frans Pop wrote: To start with: - What device name does such a partition have? - How could it be distinguished from a partitionable dasd? The output of the following command would be useful as well: # parted /dev/device print Please send the replies for these questions to the BR instead of the list! -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566642: s390-tools: Document 'optional' option in zipl.conf man page
Package: s390-tools Version: 1.6.2-1 Severity: wishlist Tags: patch The 'optional' option is currently undocumented. Please find attached a proposed patch. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: s390 Kernel: Linux 2.6.33-rc5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages s390-tools depends on: ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib s390-tools recommends no packages. s390-tools suggests no packages. -- no debconf information --- s390-tools-1.6.2.orig/zipl/man/zipl.conf.5 +++ s390-tools-1.6.2/zipl/man/zipl.conf.5 @@ -349,6 +349,22 @@ .BR 'segment' . .PP +.B optional += +.IR 0 / 1 +(configuration only) +.IP +.B Configuration section: +.br +If this option is set to 1 the configuration section will only be included in +the boot menu if the referenced image file exists, and running +.BR zipl +will not fail if the image file is missing. + +The default value for +.B 'optional' +is 0. + .B parameters = .I kernel\-parameters
Bug#566675: lstape: fails with dash as default shell due to bashisms
Package: s390-tools
Version: 1.6.2-1
Severity: important
$ sudo lstape
/sbin/lstape: 30: Syntax error: ( unexpected
Line 30 contains:
function RequireArgument() {
And 'function' is a bashism. Changing the shebang to /bin/bash fixed the
problem.
Other scripts in the package may well have the same issue.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: s390
Kernel: Linux 2.6.33-rc5 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages s390-tools depends on:
ii libc6 2.10.2-5 Embedded GNU C Library: Shared lib
s390-tools recommends no packages.
s390-tools suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#486946: FCP problem on Debian s390 hardware
reassign 486946 sysconfig-hardware tag 486946 moreinfo thanks At install time Debian was not showing any FCP which is attached to Guest image thought let me try to enable same after install of OS. [...] Once again I need repeat 1-6 steps for FCP to get enable Enabling devices during system boot is the job of the 'hwup' script of the package sysconfig-hardware. And AFAICT FCP devices are supported. It uses info in /etc/sysconfig/hardware to determine which devices to enable. So all that should be needed is to add a correct config file there. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#486526: Please enhance zipl to support booting from the RECOMP area of a CMS minidisk
From your last comment in this BR it looks as if it can be closed. Agreed? If not, the request should really be put to the upstream developers of s390-tools. You can find contact information at: http://www.ibm.com/developerworks/linux/linux390/s390-tools.html Note that there have been several upstream changes in zipl since the version currently available in Debian (see the release info on the upstream website). Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566649: s390-tools: New upstream version 1.8.3 available
Bastian,
I've packaged the new upstream version. Most debian/patches could be
refreshed or updated without too many problems. I've also updated the
packaging and fixed some BRs.
I've chosen to leave the following components disabled for now as I'm
unsure how relevant they are for Debian:
- osasnmpd (was already disabled)
- cpuplugd (daemon, so would require some work)
- ipl_tools
- ziomon
The debdiff for the deb and udeb are clean. I've done some light testing
and e.g. zipl works correctly for me.
The changelog is:
* New upstream version.
* Update debhelper compatibility to level 6.
* Document 'optional' parameter in zipl.conf man page. Closes: #566642.
* lstape, chccwdev: use bash as shell. Closes: #566675.
* Add dependency on gawk as lsdasd calls awk with the --posix option.
Closes: #564893.
* Update debian/copyright and add upstream web site in debian/control.
* Add README.source because of use of quilt.
* Fix dpkg-genchanges warning 'missing Priority for source files'.
* Add upstream README in /usr/share/doc.
Other fixes (Lintian cleanup):
- change section to admin (same as current overrides)
- added ${misc:Depends}
- fixed encoding of debian/copyright
- updated standards version
Remaining Lintian warnings:
W: s390-tools: copyright-without-copyright-notice
W: s390-tools: script-with-language-extension sbin/dbginfo.sh
(maybe that script should just be excluded?)
W: s390-tools: manpage-has-errors-from-man usr/share/man/man8/vmcp.8.gz 2:
warning: macro `LO' not defined
W: s390-tools: binary-without-manpage sbin/dasdinfo
W: s390-tools: binary-without-manpage sbin/dbginfo.sh
W: s390-tools: binary-without-manpage sbin/scsi_logging_level
I've created a (temporary) git repository that includes all changes
relative to the current 1.6.2-1 version:
git clone alioth.debian.org:git/s390-tools.git
I hope you can use that as a base for your update. Alternatively I can also
upload the new version myself (and add myself as Uploader), but a review
would be welcome.
Note that the debian revision I used needs fixing before upload!
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499833: chccwdev cannot set device offline in Lenny
Given that, what are the guidelines for when to file the initial bug report directly with upstream vs. when to file a bug report with Debian? It's mostly a question of what's most effective. The kernel team is already drowned in bug reports and has very little manpower to deal with relatively minor or very specific issue, especially not for the less popular arches. There are very few Debian-specific patches in the kernel, especially not for s390. So any s390 kernel issue is almost certain to be an upstream issue. Besides that I'm *not* saying your original report was wrong. But based on the information in it (and its lack of progress) I'm now suggesting that contacting upstream directly is probably most efficient. In this case my (not so) humble opinion as a Debian Developer is that there is zero benefit from having a DD acting as a middleman for this issue. I've done quite a lot of work with kernel upstream myself, so I think I'm a fair judge of that. So the general rule is to report bugs in Debian, but there is no rule that says a Debian Developer cannot refer you to upstream developers. Also: rules are nice, but one should always use ones own judgement. The rule is there to avoid having upstreams swamped with distro-specific issues. As we've determined that's unlikely, there's no reason not to contact them directly. The same is true if a user is himself certain an issue is upstream, especially if there's no progress on a Debian BR. The main thing is to get things done. Whatever works without annoying people (volunteers) is good in free software. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566649: s390-tools: New upstream version 1.8.3 available
Frans Pop wrote: I've packaged the new upstream version. Most debian/patches could be refreshed or updated without too many problems. I've also updated the packaging and fixed some BRs. I found I'd missed updating the files to be installed. I've now updated that too and made some other (mostly minor) improvements. I've chosen to leave the following components disabled for now as I'm unsure how relevant they are for Debian: The new list is: - osasnmpd (was already disabled) - vmur (was enabled, but files were not included in the deb) - cpuplugd (daemon, so would require some work) - ip_watcher - ziomon So I've disabled ip_watcher. There were several executables that were built in the previous version, but not included in the deb: chchp, lschp, tape390_crypt, vmconvert. I guess the main reason to exclude things is because either: - they are not useful on Debian systems - using them would conflict with the Debian way of configuring devices (using sysconfig-hardware) That the basis on which I've excluded ip_watcher and also the following additional executables: chzcrypt, lszcrypt, mon_fsstatd, mon_procd. However, as my s390 experience is limited to the Hercules emulator it's quite possible that I've been too conservative. Convincing me that something should be included should be fairly easy ;-) I've created a (temporary) git repository that includes all changes relative to the current 1.6.2-1 version: git clone alioth.debian.org:git/s390-tools.git That should have been (requires SSH access to alioth): git clone alioth.debian.org:~fjp/git/s390-tools.git I'm not 100% if that works for others than me, but it's updated with my latest changes. I hope you can use that as a base for your update. Alternatively I can also upload the new version myself (and add myself as Uploader), but a review would be welcome. That's unchanged :-) Note that the debian revision I used needs fixing before upload! Already done in current version. Cheers, FJP -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Daily Debian Installer builds
FYI I've taken over the daily builds of Debian Installer for s390 as lophos has been down for well over a month now. If the service on lophos is ever reinstated, or if someone wants to set up (and manage) the builds on a regular buildd I'll be happy to stop them again. The link on the D-I page [1] (after next website build) and the build overview page have been updated. Cheers, FJP [1] http://www.debian.org/devel/debian-installer/index.html signature.asc Description: This is a digitally signed message part.
Bug#499833: [SOLVED] - chccwdev cannot set device offline in Lenny
Stephen Powell wrote: I finally found the cause of this pesky bug! At some point, an aptitude full-upgrade seemed to fix this problem. That was probably at times that sysconfig-hardware was broken... A next fixed version of that package would have reintroduced your problem. The problem is that I could never come up with a consistent failure scenario. Well, today, I finally did. It turns out that, for me, the failure only occurs when using four device numbers: 0400, 0401, 0402, and 0403. When using any other device numbers, everything works fine. Searching my machine, I found four mystery files: They are not mystery files at all. They are part of sysconfig-hardware and their exact purpose is to bring up devices during system boot! They were almost certainly created when you installed the system because you selected at that time to activate the devices. These were all empty files, zero bytes each, the kind one would get with touch executed against a non-existent file name. The files are essentially a trigger to bring the device up, so they don't need any content. But they can contain configuration settings (depending on the type of device). -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#499833: [SOLVED] - chccwdev cannot set device offline in Lenny
Stephen Powell wrote: So whenever a dynamically linked device showed up using one of the device numbers 0400-0403, sysconfig-hardware was convinced it needed to be brought online immediately! What I don't understand is why, when it is *manually* varied offline *after* being brought online automatically, sysconfig-hardware thinks that it has to be brought right back online again! Because sysconfig-hardware gets triggered by udev when the kernel tells udev there's a new device... When you dynamically add hardware that way I guess it's a new device for the kernel, just like inserting/removing/reinserting a USB stick in a PC. But if I *manually* take one of these devices offline, it *stays* offline! Because they don't disappear for the kernel. I will leave it up to your discretion whether to re-open this bug [...] There is no bug. Everything works as designed. -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Looking for access to an s390 (git-core: [FTBFS] t7400-submodule-basic.sh fails)
I’m looking for someone who could give access to an s390 or ia64 to track down a test failure in git-core. I can't help you with access to an s390 system, but one option could be for yourself to use the Hercules s/390 emulator and run your own s390 system. Hercules is available as a package in Debian. The emulator isn't fast and I wouldn't use it for any huge compilations, but it should do well enough for working on a test case. The emulator is very solid. I've been using it to run s390 for the past 5 years or so. Some info on getting started can be found here: - http://www.josefsipek.net/docs/s390-linux/ The main thing is to set up networking correctly. The hercules package should have some info on that in /usr/share/doc. Feel free to contact me if you get stuck. Cheers, FJP -- 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/201002142049.27917.elen...@planet.nl
Re: buildd on s390
István Németh wrote: How can I setup a buildd environment to join the autobuilder network? I didn't find any working documentation. I don't think this is the correct list for that question. I suggest you try debian-wb-t...@l.d.o (although I'm not 100% that is the correct list either, but they definitely should be able to tell you). Cheers, FJP -- 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/201003171101.25257.elen...@planet.nl
Re: [RFH] Rebuild of Polyorb package on s390
I'm not sure this is the right place to request this, can someone give a try to a rebuild of polyorb ? Such requests should be sent to arch@buildd.debian.org. Cheers, FJP -- 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/201005281559.34380.elen...@planet.nl
