Re: lilo removal in squeeze (or, "please test grub2")
On Sun, 23 May 2010 16:11:30 -0400 (EDT), William Pitcock wrote: > "Stephen Powell" <zlinux...@wowway.com> wrote: >> (blah blah blah blah) > > Nobody cares if you are opposed to it. Unless you are offering to become > lilo upstream, it's going away. > > William I do understand why a Debian package maintainer does not wish to become "upstream". And I hope that someone who is both willing and able to do so steps up to the plate. But withdrawing it from the distribution seems like overkill to me, especially since you want to withdraw it from Squeeze and not Squeeze+1. Lilo, as it exists today, works just fine for my purposes. And apparently it works just fine for a lot of other people too. The Lord bless you, William. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1170680188.363342.1274662130640.javamail.r...@md01.wow.synacor.com
Bug#714581: Debian Installer partition disks step fails on s390/s390x when a small disk is used
Package: debian-installer Version: 20130613 Severity: important X-Debbugs-CC: debian-s...@lists.debian.org I recently discovered a bug in the Debian installer on the s390/s390x architecture. The bug occurs when a small disk is used. As an illustration, I had four DASDs in my installation environment, all of them device type 3390, each with a single partition occupying the entire disk, as follows: Device size in file mount Number cylinders system point 63FC 3338ext3 / 63FD 75ext2 /boot 63FE 500ext3 /home 63FF 1457swap swap mke2fs for the 63FD device (/dev/dasdb1 in this case) fails because the block size assumed by default was 1024. This is normally fine for i386 and amd64 architectures, since the physical disk block size is normally 512. The file system block size must be an integral multiple of the physical disk block size. And 1024 is a multiple of 512. But on the s390/s390x platform, dasdfmt defaults to a block size of 4096, regardless of the size of the disk. Thus, in the s390/s390x environment, the only acceptable block size (-b option) for mke2fs is 4096. Thus, mke2fs fails, which causes the subsequent mount command to fail, which causes the partition disks step of the installer to fail, which causes the entire installation to fail. The definition of a small disk is one which results in a default block size chosen by mke2fs which is lower than 4096. I'm not sure where that boundary is. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1167780681.1958873.1372640119359.javamail.r...@md01.wow.synacor.com
Symbolic links to kernel image files and initial RAM file system image files
It's hard to believe that it's been over a year since we discussed this topic. (See http://lists.debian.org/debian-kernel/2010/06/msg01049.html.) Time flies when you're having fun, I guess. ;-) Anyway, back when the boot loader hook script policy was being formulated, shortly before the Squeeze freeze, I brought up the subject of symbolic links to kernel image files and initial RAM file system image files, their maintenance, and their use by boot loader configuration files. This subject is not really addressed in the current hook script policy for boot loaders. Nevertheless, traditional boot loaders, such as lilo and zipl, particularly the way their configuration files are set up by the Debian installer, do use these symbolic links. The last time I checked, the do_symlinks = yes setting in /etc/kernel-img.conf was still honored by the maintainer scripts for official stock Debian kernel image packages; therefore, as long as the user runs only official Debian stock kernel image packages he can keep current by setting do_symlinks = yes in /etc/kernel-img.conf (along with companion options such as link_in_boot and relative_links). However, the last time I checked, do_symlinks = yes in /etc/kernel-img.conf is not honored by the maintainer scripts that are packaged with a kernel image package created by current versions of make-kpkg or make deb-pkg. Consequently, for custom kernel image packages at least, we have a chink in the armor for boot loaders to get out of sync with installed kernel images. Boot loader hook scripts are not currently required to maintain symbolic links, and none of the boot loader hook scripts that I have looked at do so. But neither do the hook scripts provided by these traditional boot loaders edit the configuration file (similar to the update-grub command of grub version 1) to reference the kernel image files and their initial RAM file system image files directly, so that symbolic links are not needed. Thus we have the situation where the boot loader is implicitly assuming that the symbolic links are going to be maintained somehow, someway, and, for custom kernels, no official part of the Debian system is maintaining them. For my own use on my own systems, I have written hook scripts which maintain the symbolic links; and if anyone wants them, they are available for download on my web site. But obviously they are not part of the official Debian system. While we still have plenty of time before the Wheezy freeze, I would like to discuss what, if anything, should be done about this situation. I see several alternatives: o Require boot loader hook scripts to either edit their configuration files or maintain the symbolic links o Provide hook scripts in some other package (base-files? initramfs-tools?) that maintain symbolic links o Eliminate symbolic links entirely and require boot loader hook scripts to edit their configuration files o Bury our heads in the sand and ignore the problem (Obviously I don't care for that last one or I wouldn't have started this thread!) The second option would seem to be the quickest solution, but the quickest solution is not always the best solution. Perhaps there are other alternatives that I haven't thought of. What are your thoughts? P.S. For this initial post I have CC-ed debian-boot and debian-devel, as there may be interested parties on that list that are not subscribed to debian-kernel, but it is my intention that the discussion take place on debian-kernel. So please excuse this initial cross-post. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1702198171.779349.139811090.javamail.r...@md01.wow.synacor.com
Bug#621080: Improving the s390 boot process
in this bug report are fixed, the kernel method is the only method that is fully functional. Notes: (1) The manual_add_modules dasd_diag_mod line in /etc/initramfs-tools/hooks/sysconfig-hardware is what causes the dasd_diag_mod kernel module to be included in the initial RAM file system, since I use MODULES=dep in /etc/initramfs-tools/conf.d/driver-policy. This is preferable to listing it in /etc/initramfs-tools/modules because listing it in /etc/initramfs-tools/modules also causes initramfs-tools to attempt to load it when it comes to the point of loading essential drivers. It may be too late by then. The only way to make sure that dasd_diag_mod gets loaded at the proper time is to use the two softdep lines in /etc/modprobe.d/dasd.conf, as shown above. (2) Note that /lib/udev/rules.d/85-sysconfig-hardware.rules was included in the initial RAM file system, but /lib/udev/rules.d/65-sysconfig-hardware-net.rules was not. I did not deem it necessary to fully configure network devices prior to the initial read-only mount of the permanent root file system. Network devices, such as an OSA, will have their configuration finished after the permanent root file system is initially mounted read-only. (3) In an attempt to reduce the size of the initial RAM file system, I attempted to remove all the bashisms from the scripts belonging to sysconfig-hardware; so it would be able to run under ash. This would allow me to avoid including /bin/bash in the initial RAM file system. Most of the bashisms could be easily eliminated, but arrays were a problem. For example, my OSA configuration file, /etc/sysconfig/hardware/config-ccw-0.0.0300, contains the following: CCWGROUP_CHANS=(0.0.0300 0.0.0301 0.0.0302) This is an array assignment statement, which gets sourced into /etc/sysconfig/scripts/hardware/hwup-ccw-group during execution. bash supports arrays, but ash does not. In the end I decided that it was more trouble than it was worth and left them all as bash scripts. Thus, /bin/bash had to be included in the initial RAM file system. Initial RAM file system size is not really a problem in s390. For one thing, s390 has a lot fewer device driver modules to deal with than, say, the i386 architecture. Also, s390 is not subject to a 16M memory restriction, as LILO is on the i386 architecture for some machines with a very old BIOS. zipl can access up to 2G of RAM. (4) Note that in my example the vmhalt=LOGOFF and vmpoff=LOGOFF kernel boot parameters are used. For a Linux system running in a virtual machine under z/VM, this causes the CP LOGOFF command to be issued during shutdown when a halt or power-off signal is received. But this only works if the vmcp kernel module is loaded. I list vmcp in /etc/modules to accomplish this. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1555455293.56289.1302089676441.javamail.r...@md01.wow.synacor.com
Re: installer logo change
On Fri, 04 Feb 2011 13:04:18 -0500 (EST), Christian PERRIER wrote: - the usually accepted symbol of communism is a hammer crossed with a whatever it's called in English It's called a sickle. The traditional symbol of communism is the hammer and sickle, which represents the solidarity of factory workers (the hammer) and farm workers (the sickle). If the OP is talking about the space fun theme, I think he's off base. I've been using it since it came out, and I never once thought of communism. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1434229825.597290.1296872436981.javamail.r...@md01.wow.synacor.com
Re: Request for enhancement [Re: Question about /etc/fstab in Squeeze]
On Sun, 19 Dec 2010 11:44:35 -0500 (EST), Rick Thomas wrote: On Dec 19, 2010, at 8:09 AM, Stephen Powell wrote: Caution: reformatting a swap partition with mkswap will change the uuid unless the existing one is explicitly re-specified during formatting. Which raises a question that has been on my mind for a while... The Debian Installer insists on reformatting any swap partitions it finds, even though that partition, specified by UUID, is probably in use in the /etc/fstab for some other instantiation of Linux -- thus breaking the other Linux, leaving it without a usable swap partition. Would it be possible to either: 1) have the option (default) of *not* reformatting a swap partition or 2) if reformatting is necessary or desired, have the option (default) of preserving the UUID. or 3) using LABEL= instead of UUID= in fstab for swap partitions, if it turns out to be easier to preserve a LABEL than a UUID. From what I've heard, the Ubuntu installer has the same problem, and it can ruin a functioning Debian system too. Of course, that's not something the Debian installer team can do anything about. That's outside of their jurisdiction. But many Ubuntu people, both users and developers, are known to monitor Debian's lists. Let's hope that some of the right people are listening. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/545834701.1198861.1292884630008.javamail.r...@md01.wow.synacor.com
Re: About linux-kernel-di-i386.
On Thu, 16 Sep 2010 02:58:24 -0400 (EDT), Magicloud Magiclouds wrote: Hi, sorry to bother you guys. I am learning to make a custom DI following http://wiki.debian.org/DebianInstaller/Modify/CustomKernel. So I have to make linux-kernel-di myself. Well, it is not quite clear in the document, I just got the source and `kernel-wedge build-arch i386`. It gave error message as following. May I know what to do? Do I have to find the drivers like wavelan or I could remove them. Thanks. # error msg kernel-wedge install-files install -D -m 644 /boot/vmlinuz-2.6.35.4 debian/kernel-image-2.6.35.4-i386-di/boot/vmlinuz install -D -m 644 /boot/System.map-2.6.35.4 debian/kernel-image-2.6.35.4-i386-di/boot/System.map kernel-wedge copy-modules 2.6.35.4 i386 2.6.35.4 missing module zlib_deflate missing module orinoco_pci missing module netwave_cs missing module wavelan_cs command exited with status 1 make: *** [binary-arch] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 Exactly what are you trying to accomplish? In other words, what real-world problem are you trying to solve? I have been using Debian for ten years, and I have never yet had to create a custom version of the Debian installer. I'm not saying it can't be done. What I'm saying is, Are you sure it needs to be done? What, ultimately, are you trying to do? And why do you think you need a custom version of the Debian installer to do it? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1452690791.25682.1284646288902.javamail.r...@md01.wow.synacor.com
Bug#445148: closed by Christian Perrier bubu...@debian.org (Closing oldbug report against debian-installer #445148)
On Mon, 13 Sep 2010 12:13:01 -0400 (EDT), Robert Nix wrote: I just tried the current download, and can't even get past formatting the DASD. I get a window with the following: ┌──┤ [!!] Partition disks ├──┐ │ ERROR!!! │ │ VTOC: seeking on device failed -- vtoc_write_label │ │ Could not write VTOC labels. │ ││ │ Go Back Continue │ ││ └┘ The virtual machine has write access to the disk, so that's not the problem, and I've tried just about every combination of formatting and not formatting, labeling and not labeling the disks before and during the install that I can think of. Obviously, this works somewhere, or it wouldn't have been released in the first place. And I don't think we have a very unique system here, so it should be a fairly standard install. We run about 50 RedHat images, and several SuSE images, so it's not like we're novices at this Any ideas that might help, and won't take three more years to come up with? Excuse me for butting in here gentlemen. This is not my bug report, and I am not a member of the Debian Installer team, but I do run the s390 port of Debian GNU/Linux in a virtual machine under z/VM; so perhaps I can be of some service here. Which version of the Debian installer did you try to run? Please be as specific as possible about the URL where you downloaded it from, etc. The last time I tried to run the production Squeeze installer for s390, it wouldn't even boot. (In fairness, that was several months ago.) I tried the latest daily build installer and it worked; so I stuck to it. The daily build installation images were at one time hosted by an external site. But all of a sudden, the server went down and never came back up. After being down for a month, Frans Pop, the leading Debian Installer person for s390, started doing the daily builds himself. That was fine for a while. But he died recently, leaving very big shoes to fill. When he died, his Debian work space disappeared with him, and with it the daily build installation images. We need to get those back. Anyway, if you will point me to the installation images that you used, I will give it a go here and see if I can reproduce your problem. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1469216320.79928.1284404128463.javamail.r...@md01.wow.synacor.com
Bug#596760: Could not write VTOC labels
On Mon, 13 Sep 2010 16:27:56 -0400 (EDT), Robert Nix wrote: Image version: http://ftp.nl.debian.org/debian/dists/lenny/main/installer-s390/current/images/generic/ The Lenny installer is a bit long in the tooth. Have you tried the Squeeze alpha1 installer? It *should* be able to install Lenny, if that is what you want to do. For example: http://ftp.nl.debian.org/debian/dists/testing/main/installer-s390/current/images/generic/ If that doesn't work, there are some newer images that you can try. For example (from a CMS Ready; prompt): ftp carroll.aset.psu.edu anonymous m...@mydomain cd /pub/linux/distributions/debian cd dists/sid/main/installer-s390/current/images/generic passive ascii get debian.exec binary get initrd.debian INITRD.DEBIAN get kernel.debian KERNEL.DEBIAN get parmfile.debian PARMFILE.DEBIAN close quit PIPE PARMFILE DEBIAN A|FBLOCK 80 00| PARMFILE DEBIAN1 A F ERASE PARMFILE DEBIAN A RENAME PARMFILE DEBIAN1 A = DEBIAN = PIPE INITRD DEBIAN A|FBLOCK 80 00| INITRD DEBIAN1 A F ERASE INITRD DEBIAN A RENAME INITRD DEBIAN1 A = DEBIAN = PIPE KERNEL DEBIAN A|FBLOCK 80 00| KERNEL DEBIAN1 A F ERASE KERNEL DEBIAN A RENAME KERNEL DEBIAN1 A = DEBIAN = DEBIAN Machine: IBM Z9 2094 2IFL z/VM Version 5 Release 3.0, service level 0702 (64-bit) Generated at 10/31/07 09:12:13 CDT Your release of z/VM is getting a bit long in the tooth too! ;-) And service level 0702 is more than three years out of date. ;-) Have you checked for PTFs that may need to be applied? Virtual machine definition follows: ... MDISK 0391 3390 31283 125 VG0125 MR MDISK 0392 3390 17701 10016 VP0133 MR MDISK 0393 3390 1 10016 VP0136 MR Are you sure that's right? What kind of DASD do you have? I normally use 3390-3 volumes, but even a 3390-9 stops at 10017 cylinders. You're going past 31000 cylinders. Can you use the CMS FORMAT command on these minidisks successfully? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1650090882.84595.1284413902502.javamail.r...@md01.wow.synacor.com
Bug#519254: Debian Lenny/s390 - unable to boot with a dedicated /boot partition
I just noticed this bug report today. I am not the package maintainer, I am another user. I have noticed this bug too, but I never bothered to file a bug report. So since someone else did, I have subscribed to this bug report. I believe that this is a legitimate bug. However, until such time as it is fixed, I offer you a circumvention. Apparently, the installer attempts to mount the devices in increasing device number/partition order. Thus, in your example, it attempts to mount the partitions in the order: (3012,1), (3012,2), (3026,1), (3027,1). In your example, it attempts to mount /boot before /, which is not possible. The algorithm needs to be changed to mount the devices in the order that the file system requires. To put it simply, mount / first, then mount all remaining mount points containing a single slash (/boot, /home, etc.), then all remaining mount points containing two slashes, etc., until all partitions are mounted. Swap spaces are not part of the file system and can be mounted independently. Given the algorithm used by the installer today, you can use a separate /boot partition, but its device number/partition must be higher than the device number/partition of the / device. For example, if (3012,1) was / and (3026,1) was /boot, it would have worked. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1177444331.15029.1284146464303.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
the default value is yes, they should issue the warning message unless do_bootloader is *explicitly* set to no. 6. The installer must not define do_bootloader, postinst_hook or postrm_hook in /etc/kernel-img.conf. Doesn't this conflict with point 4 (a)? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1266213194.8135.1277738218774.javamail.r...@md01.wow.synacor.com
Re: [DRAFT] Policy for Linux kernel, initramfs, boot loader update process
On Mon, 28 Jun 2010 12:45:10 -0400 (EDT), maximilian attems wrote:
On Mon, 28 Jun 2010 03:02:35 +0100 Ben Hutchings wrote:
The arguments given to all kernel hook scripts are the kernel ABI
version (the string that uname -r reports) and the absolute path to the
kernel image.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
Currently, hook scripts invoked by a stock kernel maintainer script
or a maintainer script from a kernel image package created by make-kpkg
pass these exact same arguments.
no.
From a Squeeze system running a custom kernel created by make-kpkg:
-
debian3:~# dpkg-reconfigure linux-image-2.6.32-custom5b-s390x
Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-custom5b-s390x
/boot/vmlinuz-2.6.32-custom5b-s390x
^ ^
+-- 1st argument
+-- 2nd argument
-
From a Squeeze system running a stock kernel image:
-
r...@testdebian:~# dpkg-reconfigure linux-image-2.6.32-3-686
Running depmod.
Running update-initramfs: Generating /boot/initrd.img-2.6.32-3-686
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/S30initramfs 2.6.32-3-686
/boot/vmlinuz-2.6.32-3-686
^^
|+-- 2nd
argument
+-- 1st argument
-
Q.E.D.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
But a maintainer script for a kernel
image package created by make deb-pkg passes only the first argument.
no.
The actual text of /etc/kernel/postinst.d/initramfs-tools:
-
#!/bin/sh
version=$1
bootopt=
# passing the kernel version is required
[ -z ${version} ] exit 0
# kernel-package passes an extra arg
if [ -n $2 ]; then
if [ -n ${KERNEL_PACKAGE_VERSION} ]; then
bootdir=$(dirname $2)
bootopt=-b ${bootdir}
else
# official Debian linux-images take care themself
exit 0
fi
fi
# avoid running multiple times
if [ -n $DEB_MAINT_PARAMS ]; then
eval set -- $DEB_MAINT_PARAMS
if [ -z $1 ] || [ $1 != configure ]; then
exit 0
fi
fi
# we're good - create initramfs. update runs do_bootloader
update-initramfs -c -t -k ${version} ${bootopt}
-
I admit that I have never personally used make deb-pkg, but
clearly the source code speaks for itself. This hook script is
expecting only one argument when invoked by make deb-pkg.
Q.E.D.
On Mon, Jun 28, 2010 at 11:16:58AM -0400, Stephen Powell wrote:
Existing hook scripts rely on that difference to determine whether or
not to take action. For example, the initramfs hook script provided by
the initramfs-tools package tests the number of arguments and exits
without doing anything if more than one argument is supplied. In other
words, this hook script is designed to create the initial RAM file system
for a kernel image created by make deb-pkg, and only for a kernel
image created by make deb-pkg. It does nothing otherwise. Are you
proposing to change this behavior?
please get your facts right before spamming the world.
OK, you're partly right on this one. Execution tracing shows that it
does nothing when invoked by a stock kernel maintainer script but
does create an initial RAM file system when invoked by a maintainer
script from a kernel image package created by make-kpkg. (By the way,
since this script is running under debconf, output from update-initramfs
should be redirected to standard error via 2.) I don't remember the
kernel-package logic being present in this script the last time I looked
at it.
(1) As far as I am able to determine, my original statements are correct,
with the exception of the correction made in the above paragraph.
If you can prove me wrong, please do so.
(2) This was not spam. Spam is unsolicited advertising.
This was a response to an RFC, to which I was explicitly
included as an adressee.
(3) All the addressees of my e-mail were legitimate stake-holders
in this process. This is not the world.
--
.''`. Stephen Powell
: :' :
`. `'`
`-
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1137353821.16101.1277752206454.javamail.r...@md01.wow.synacor.com
new lilo package maintainer? (was lilo removal in squeeze or please test grub2)
On Mon, 07 Jun 2010 03:22:46 -0400 (EDT), sean finney wrote: On Mon, Jun 07, 2010 at 01:44:05AM +0400, William Pitcock wrote: Have fun. When you have a release that actually has merit, it can be reconsidered for inclusion in Debian. In the meantime, the original plan continues. actually, i don't think you have any say about what software can and can not be in debian, that is the sole privilege of ftp-master. your options are (a) to claim you still want to maintain the package and continue to do so, or (b) ask for its removal by ftp-master. given your comments here i think if you were to claim (a) there would be a decent case for someone to take to the tech-ctte. ftp-master, if they're aware of this argument, may just say why not orphan it instead?. but regardless, if someone else is interested they can just follow that removal with a new upload using their name as Maintainer, and then again it's up to ftp-master to accept or deny it. given that there may be an active upstream and maintainer, and the software is otherwise DFSG-compatible, i don't see why they would deny such a new upload. of course, it would be a lot nicer if you could just hand over the reins of the current package to those who have been asking for them, to avoid some un-needed overhead... sean Perhaps I can offer a solution here. Since William obviously doesn't wish to maintain this package any longer, I am willing to take over his responsibilities as a Debian package maintainer for lilo under two conditions: (1) The kernel team fixes bug number 505609, and (2) Debian ceases its attempts to remove lilo from the distribution. What do you say, William? Do you have any objections? Does anyone else have any objections? If so, speak now, or forever hold your peace. Keep in mind that I have never been a Debian package maintainer before. This will be my first package. Please be patient with me as I learn the ropes, so to speak. As for whether or not lilo continues to be offered as an alternate boot loader by the Debian installer, that is entirely up to them. I would think that the path of least resistance would be to maintain the status quo, but if they want to remove lilo from the Debian installer menu that's their call, as far as I am concerned. I just don't want to see lilo removed from the distribution. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1196418916.5745.1275918400688.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze / new lilo upstream
On Sun, 06 Jun 2010 09:39:59 -0400 (EDT), Joachim Wiedorn wrote: I see that more people than thought still want to have or need LiLO. Now I have decided to start and reanimate the upstream development. Everyone is invited to join in this development. I'm working on LiLO version 23. Shortly with more informations ... Fondest regards, Joachim Wiedorn That's great news, Joachim! If it weren't for my complete ignorance of x86 assembly language, I might have been tempted to try it myself. But perhaps I may be able to help out in some way. We lilo users are very grateful to you for your willingness to take over. By the way, did anyone ever find out what happened to John Coffman? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1978551454.33.1275845120737.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze / new lilo upstream
On: Sun, 06 Jun 2010 17:44:05 -0400 (EDT), William Pitcock wrote: Joachim Wiedorn ad_deb...@joonet.de wrote: I see that more people than thought still want to have or need LiLO. Now I have decided to start and reanimate the upstream development. Everyone is invited to join in this development. I'm working on LiLO version 23. Shortly with more informations ... Have fun. When you have a release that actually has merit, it can be reconsidered for inclusion in Debian. What is your definition of merit, William? And why does the current release not have it? In the meantime, the original plan continues. The original plan was based on false assumptions. Why would you continue with a plan based on false assumptions? We now have a release of lilo with (a) an active upstream maintainer, and (b) no release critical bugs. If you simply don't want to be a Debian package maintainer for lilo anymore, why not ask for volunteers to take over for you? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1545549194.342558.1275871054568.javamail.r...@md01.wow.synacor.com
[SOLVED] Unbootable after kernel upgrade: Lilo can't load kernel
This is not a lilo bug. The problem is that lilo's map installer did not get run during the kernel upgrade process. The fact that the user was able to boot his old de-installed kernel is proof of this. The /boot/map file still pointed to the blocks in the file system which formerly contained the old kernel and its initial RAM file system image. And since, fortunately, those blocks had not yet been reused, the data was still there. Modules which were loaded from the initial RAM file system image loaded OK. But once the switch was made from the initial RAM file system to the permanent root file system, further module loads could not be done, since the modules had been erased. When the user manually ran lilo's map installer at the command line, the problem disappeared. The real question is, Why didn't the map installer get run during the kernel upgrade? There is not sufficient data in the bug log to determine the answer to that question, but I have observed that do_bootloader = yes in /etc/kernel-img.conf no longer causes lilo to be run when a new kernel is installed. I believe that this change in behavior was caused by changes to the kernel maintainer scripts made around the time of the switch to grub version 1 as the default boot loader. do_bootloader = yes in /etc/kernel-img.conf still causes zipl to be run on the s390 port, a port that neither version of grub supports. do_bootloader = yes should still be specified in /etc/kernel-img.conf, however, so that update-initramfs -u will cause lilo's map installer to be run when an initial RAM file system is updated (but not when it is initially created). So is this a bug in the kernel maintainer scripts? Or is it a feature? I don't know. I'll leave that up to the kernel maintainers to decide. A full discussion of how to make sure that lilo's map installer gets run during the installation of a new kernel, taking into account all types of kernels (official stock Debian kernels, custom kernels created by make-kpkg, custom kernels created by make deb-pkg, etc., is beyond the scope of this bug log. Interested readers may wish to look at my web page on kernel building, particularly step 10, for further information. http://www.wowway.com/~zlinuxman/Kernel.htm The instructions for customizing the Lenny environment will work in Squeeze or Sid also, provided that you use only official stock Debian kernels. If you use custom kernels in Squeeze or later, you *must* use hook scripts to ensure that any post-installation activities, such as the creation of an initial RAM file system, updating symlinks, or running a boot loader, take place. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2000712474.159302.1275230137351.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Sat, 29 May 2010 14:40:41 -0400 (EDT), Andreas Barth wrote: Stephen Powell wrote: On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: After some discussion about lilo on #debian-devel in IRC, it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. We're speaking about #505609 I assume? I hope not. Strictly speaking, 505609 is not a lilo bug. The key is that he was still able to boot his old kernel that had been de-installed. That's a sure sign that lilo's map installer did not get run during the kernel upgrade process. It used to be that if do_bootloader = yes was specified in /etc/kernel-img.conf that installing a new kernel would cause lilo to be run. That is no longer the case. update-initramfs -u ... will cause lilo to be run if this option is set; but update-initramfs -c ... (or mkinitramfs ...) which is what is run during installation of a new kernel, will not. I have created my own hook script to fix that problem on my system. Strangely, though, do_bootloader = yes in /etc/kernel-img.conf still causes zipl to be run during kernel installation on the s390 platform. Something must have changed in the kernel maintainer script or in update-initramfs that causes the lilo map installer to not be run anymore under conditions that used to cause it to be run. Look carefully at the console log. There is no output from the map installer until he manually runs lilo. He apparently thinks that running lilo from the command line simply lists the installed kernels. No. Running lilo from the command line is what fixed the problem. If there's a bug here, it's somewhere else in the kernel installation process, not in lilo itself. If this so-called bug in lilo is what prompted the decision to drop lilo, then the decision was based on bad data. lilo, at least in this case, is working as designed. The problem is that the lilo map installer did not get run during the kernel installation process. I've helped a number of people on debian-user with problems like this, and in every case so far running lilo at the command line fixed the problem. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/267435255.153128.1275165812236.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 13:12:27 -0400 (EDT), Stephen Powell wrote: Boyd Stephen Smith Jr. wrote: No software is entirely without cost ... volunteers work on whatever they like ... your specific requirements may differ from their goals ... volunteers are rarely concerned with market share ... All excellent points, Boyd. Fortunately in this case, extlinux appears to be a viable solution. I'll soon know ... Unfortunately, logical backups of a Linux machine using the extlinux boot loader do not work with our backup/restore software. The master boot record and partition boot sector are restored correctly, but /boot/extlinux/extlinux.sys will probably not be restored to the exact same sectors from which it was backed up, and the restore software has no special logic to remedy that situation. Therefore, after restore, the machine will not boot. It *does* recognize lilo and has special logic to patch lilo after the restore so that the machine will boot. The problem can be circumvented by taking an image backup instead of a logical backup, but that gets into special backup requirements. Until we get newer backup software I must either use lilo or ask for special backup procedures for my Linux servers. I choose the former. Logical (file by file) backups have many advantages, one of which is to avoid giving the Windows advocates an excuse to oppose further deployment of Linux servers. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1739612780.129666.1275057918173.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Wed, 26 May 2010 00:23:04 -0400 (EDT), Daniel Baumann wrote: On 05/26/2010 03:36 AM, Stephen Powell wrote: ... That works for now; but if a package upgrade for extlinux is ever downloaded, I'm afraid that new versions of the hook scripts will be copied into these directories which are marked executable, and my hand-made configuration file will get wiped out. ... as of current git, you can now use EXTLINUX_UPDATE=false in /etc/default/extlinux to prevent having update-extlinux do anything. That's good to know, thanks. I'm looking forward to that feature migrating into squeeze. Second, it is important that any script run as a hook script not produce any output at all to standard output. I found that out the hard way when I was writing my own hook scripts for use with lilo. That's because they run under debconf, which has redirected standard output for its own purposes. Thus, anything written to standard output is (1) never seen by the user and (2) has a good chance of messing up debconf, which is examining the output. The invocation of update-extlinux should have a redirection on it to redirect output to standard error. For example, update-extlinux 2 none of the hooks is doing this (initramfs-tools, grub, etc), might needs further convincing. It is a little-known requirement, and often you can get away with it, but not always. I'm going from memory here, but I believe that debconf redirects standard output, then calls the maintainer script for the kernel, which calls the run-parts utility, which then calls the hook script. If the standard output produced by the hook script matches something that debconf is looking for it can mess things up. Sometimes the failure will occur for one type of call, such as a purge, but not for another type of call, such as a configure or a remove. Manoj Srivastava, author and Debian package maintainer of the kernel-package package, mentions it in the man page for kernel-img.conf, and I have personally been burned by it with one of my own hook scripts that I wrote for use with lilo. The hook script failed with a non-zero return code, which caused the kernel installation process to fail. I could not figure out for the life of me what was wrong. The script ran fine when invoked stand-alone, but not as a hook script. Redirecting lilo output to standard error solved the problem. It ran perfectly after that. But even if the stuff written to standard output does not mess up debconf, the user still won't see it. The safe (and informative) thing to do is for all hook scripts to write all output to standard error. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/375009335.66290.1274880285294.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
Ferenc Wagner wrote: Stephen Powell zlinux...@wowway.com writes: Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record and outside of a partition ... You may want to try extlinux, it works much like LILO in this respect. Well, I tried extlinux last night, and I am hopeful that this is going to be a solution, at least for me. extlinux seems to combine the best parts of grub-pc and lilo. Like grub-pc, extlinux understands the file system, and can read the configuration file, kernel, and the initial RAM file system image from the file system without needing a list of specific blocks to read. Thus, the boot loader does not need to be re-run every time a kernel is installed or updated or an initial RAM file system image is installed or updated. The number of file systems it supports is limited, but that's OK. A separate /boot partition of the file system type supported by the boot loader is acceptable. But like lilo it stays out of unallocated (and therefore not backed up) sectors. The boot block of extlinux is installed in the boot sector of a partition, and the second stage loader occupies a file within the partition. It does not use the master boot record. It relies on a master boot record program to chain load it from the partition boot sector. (I use the mbr package for that.) It *does* support the specification of an initial text video mode (vga option), though this is not specifically documented. Speaking of documentation, that seems to be its main weakness. Documentation is sketchy and spread out over a number of different files. I would have had a hard time configuring it if it weren't for correct guesses based on my knowledge of how lilo is configured, which newer users won't have. It installs hook scripts that I don't want (and that have bugs). But after manual configuration and tweaking, it works just fine. Now, if it passes the backup / low-level-format / restore test, I'll be good to go. Stay tuned ... -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1078928757.35141.1274793733671.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 07:08:20 -0400 (EDT), Mihamina Rakotomandimby wrote: William Pitcock neno...@dereferenced.org wrote: This bug *can* be fixed, but not without a significant rewrite of the way that lilo's stage2 loader code works. Given that there is no active upstream and that the Debian lilo package carries many patches for bug fixes that are alleviated by standardizing on grub2, this seems like the best option for Debian. Agreed: dead (and buggy) softwares must be out of the distribution. Whatever happens. If LILO regains upstream coders, its return to the distribution is quite easy. By that standard, grub-pc should be removed from the distribution. It may have upstream support, but based on other posts I've seen, it effectively has no maintainer. Which is worse, a package with effectively no upstream support or a package with effectively no maintainer? And grub-pc is buggier than lilo. I understand the need to remove packages with no upstream support. But asking users to test a package with umpteen known release-critical bugs, most of which have apparently been fixed upstream, but have not been fixed in Debian because there is no maintainer to download a new upstream version, is not a reasonable request in my humble opinion. Get a maintainer for it, fix the known bugs, and *then* ask the users to test it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1927842586.35924.1274795074336.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote: Stephen Powell wrote: (3) The need for special backup requirements will be used by the opponents of Linux at my place of employment to oppose further deployments of Linux, ... What about the carrot approach? Find an even better backup method, compatible with Grub 2 and appealing to your management for its efficiency. You're missing the point. The main selling point to management is that Linux is free. If they have to buy new backup software in order to accommodate Linux' backup requirements, that will kill it on the spot. Whatever boot loader I use must not require new backup software or impose special backup requirements. And its not just money. As a rule, people like what they know. The backup people are Windows people, and they'd love an excuse to complain to management about the backup requirements of my Linux servers. grub-legacy and grub-pc are non-starters for me for that reason. Until now, only lilo, as far as I knew, met all my requirements. It now appears that extlinux may also work. I'll soon know. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/351821928.39974.1274802154546.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 11:51:11 -0400 (EDT), Mark mamar...@gmail.com On Tue, May 25, 2010 at 8:42 AM, Stephen Powell zlinux...@wowway.comwrote: On Mon, 24 May 2010 17:29:54 -0400 (EDT), Peter Easthope wrote: Stephen Powell wrote: (3) The need for special backup requirements will be used by the opponents of Linux at my place of employment to oppose further deployments of Linux, ... What about the carrot approach? Find an even better backup method, compatible with Grub 2 and appealing to your management for its efficiency. You're missing the point. The main selling point to management is that Linux is free. ... Clonezilla is free, and when using the saveparts option to save an image of one partition and not the full hard drive, it includes the MBR and associated data. You can then drop that partition image onto a new/blank disk, that does not have anything in the MBR, and once Clonezilla restores the image to the new partition, will put the MBR in place and the machine boots on its own the next time, with no extra work (I just did this last week with a new hard drive). This has been my experience with using Clonezilla and Lenny, at least. So it may help in your case. Perhaps so. But it's not what the backup people know. They're very comfortable with the backup software that they know and love for backing up their Windows servers, which was purchased with Windows servers in mind. Do you think they're going to redo their whole backup architecture just for a few Linux servers? If I want to play in their sandbox, I have to play by their rules. That's the political reality. At our shop, Linux has a small beachhead on a vast continent controlled by Windows. Over time, the role of Linux may expand to the point where Linux is actually thought about and planned for when decisions are made. But that day is not today. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/479605722.42620.1274806845480.javamail.r...@md01.wow.synacor.com
Re: Re (2): lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 12:03:17 -0400 (EDT), Boyd Stephen Smith Jr. wrote: Stephen Powell wrote: You're missing the point. The main selling point to management is that Linux is free. No software is entirely without cost. Free Software is no exception. There are usually no up-front licening fees, sure. However, volunteers work on whatever they like, and if no one volunteers to maintain and support your software you may have to pay for that. Even with volunteers providing maintenance and support, your specific requirements may differ from their goals and that will require effort to resolve. ... Also, volunteers are rarely concerned with market share, losing your management as users is not necessarily a concern to them. If it is a concern for you, you may have to put forward some additional effort to address your management's issues. All excellent points, Boyd. Fortunately in this case, extlinux appears to be a viable solution. I'll soon know. The guy I need to see about setting a test server to test the backup and restore scenario has been off work with a sick child for the past couple of days, but when he gets back I'll try to prove that it is 100% compatible with our backup software. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1557806589.43087.1274807547943.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Tue, 25 May 2010 11:10:38 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell wrote: ... I installed the mbr package ... The extlinux package itself also contains an mbr.bin, which you can use (it's strong point is probably EBIOS support). So it does. Well, I've now installed extlinux' version of mbr.bin to the master boot record and purged the mbr package. extlinux' built-in version of a master boot record boot loader works great. Speaking of documentation, that seems to be its main weakness. Documentation is sketchy and spread out over a number of different files. /usr/share/doc/extlinux.txt.gz references syslinux.txt, which is fairly comprehensive according to my standards, at least as far as the core is concerned. What did you miss? Some modules may be less well documented. Yes, I found those two files. Reference documentation for each specific boot loader option is there, but what is lacking is tutorial-type stuff. For example, there is a global options section at the beginning that applies to all bootable images, and there are options which are specific to each boot image. I guessed at that mainly based on how /etc/lilo.conf works, but I'm not sure it was directly stated anywhere. It may be hinted at in the description of some individual configuration option but not explained up front. Also, there's no example configuration file. There are little pieces of configuration files but no complete typical configuration file. A picture is worth a thousand words. It installs hook scripts that I don't want (and that have bugs). I hope we can fix them soon (they are Debian specific additions). Remember, I'm used to using lilo. And based on analogies with lilo, I built a /boot/extlinux/extlinux.conf file that looks like this: - DEFAULT Linux APPEND root=/dev/sda2 ro vga=779 TIMEOUT 50 PROMPT 1 LABEL Linux KERNEL ../vmlinuz INITRD ../initrd.img LABEL LinuxOLD KERNEL ../vmlinuz.old INITRD ../initrd.img.old - The kernel and initial RAM disk images are specified via the traditional symlinks. As long as the symlinks are maintained properly, my config file never needs updating, just like lilo's. Consequently, I really don't want the extlinux hook scripts to execute at all when I install or remove a kernel. I solved that temporarily by issuing chmod -x /etc/kernel/postinst.d/extlinux chmod -x /etc/kernel/postrm.d/extlinux That works for now; but if a package upgrade for extlinux is ever downloaded, I'm afraid that new versions of the hook scripts will be copied into these directories which are marked executable, and my hand-made configuration file will get wiped out. I would suggest testing the existence of some flag file. If the flag file exists, then invoking update-extlinux should be bypassed. Thus, if the user doesn't want his hand-made /boot/extlinux/extlinux.conf file to be tampered with, he can create that flag file via touch and the hook script will not run update-extlinux. Strictly speaking, this is an enhancement request. Second, it is important that any script run as a hook script not produce any output at all to standard output. I found that out the hard way when I was writing my own hook scripts for use with lilo. That's because they run under debconf, which has redirected standard output for its own purposes. Thus, anything written to standard output is (1) never seen by the user and (2) has a good chance of messing up debconf, which is examining the output. The invocation of update-extlinux should have a redirection on it to redirect output to standard error. For example, update-extlinux 2 This is a bona-fide bug. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/630546796.56099.1274837814099.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 05:36:32 -0400 (EDT), Ferenc Wagner wrote: Kurt Roeckx k...@roeckx.be wrote: On Sun, May 23, 2010 at 01:11:48PM +0200, Cyril Brulebois wrote: William Pitcock neno...@dereferenced.org (22/05/2010): This means that users should *test grub2 extensively* before Squeeze is released so that any issues can be resolved now. There should also be some folks fixing the discovered issues. grub2 currently seems to be having 18 RC bugs, plus a whole bunch of merged bugs, while lilo only has 1 RC bug. I chatted about this with the grub upstream a couple of days ago. According to Vladimir, most of those bugs are already fixed, but there's nobody around to do a new upload. Both grub maintainers (Felix Zielke and Robert Millan) unexpectedly disappeared some time ago. What about Jordi Mallach and Colin Watson? The package page for grub-pc http://packages.debian.org/squeeze/grub-pc lists them as maintainers too. Have they disappeared as well? Or are they no longer maintainers for this package? In which case their names should be removed from the web page. Somehow I feel a dip in motivation. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1054400013.5379.1274709588267.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell zlinux...@wowway.com writes: Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record [...] This breaks the design of the backup software that my employer uses. This backup software backs up the master boot record and all partitions; but since the extra sectors used by grub-legacy and grub-pc are outside the master boot record and are not part of any partition, they don't get backed up. Consequently, if we have a hard drive failure and restore from a backup, we have an unbootable machine. Lilo uses only the master boot record. A lilo-booted machine can be backed up and restored with our existing backup software just fine. You may want to try extlinux, it works much like LILO in this respect. It lacks a convenient configuration system, but that of grub-legacy would be easy to adapt, and I actually plan to work on this. Thanks for the tip. That may be an option. I looked at the documentation online, and there does not appear to be an option equivalent to lilo's vga option, though, which I use a lot, especially since svgatextmode has already been pulled from squeeze. As of right now, if lilo was pulled from the distribution, I think I'd be inclined to build my own lilo package from source before switching to any other bootloader. To the best of my knowledge, it is the *only* bootloader which supports setting an initial text video mode *and* does not use any sectors outside the master boot record and outside of a partition. If I'm wrong about that, someone please correct me. As for a convenient configuration system, editing a plain text file is plenty good enough for me. Your time is yours to use as you see fit; but if you have the requisite skills to become the equivalent of lilo upstream, I think there's a lot of people who would rather that you do that, myself included. I'd do it myself if I had the necessary skills and knowledge. But I don't. Thanks again for the tip. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1012155825.7010.1274712448896.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 13:01:30 -0400 (EDT), Edward Allcutt wrote: On Mon, 24 May 2010, Stephen Powell wrote: To the best of my knowledge, lilo is the *only* bootloader which supports setting an initial text video mode *and* does not use any sectors outside the master boot record and outside of a partition. If I'm wrong about that, someone please correct me. grub2 supports loading its core.img from a dedicated partition instead of embedding it in the first cylinder. This does require switching to the GPT partitioning scheme which may or may not be acceptable to you. No, the backup software assumes the traditional MS-DOS hard disk partitioning scheme. One can get around this by requiring an image backup, but that has three substantial drawbacks: (1) The entire disk, including free space and extended partition free space, must be backed up. This takes a lot more time. (2) A restore can only be done to a disk of the exact same size as the one backed up. Often, a larger disk must be used because the model that failed is no longer available on the market. (3) The need for special backup requirements will be used by the opponents of Linux at my place of employment to oppose further deployments of Linux, which I wish to avoid at all costs. But thanks for the info anyway. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1081731293.13454.1274723918397.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Mon, 24 May 2010 13:38:55 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell zlinux...@wowway.com writes: On Mon, 24 May 2010 05:29:56 -0400 (EDT), Ferenc Wagner wrote: Stephen Powell zlinux...@wowway.com writes: Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record [...] You may want to try extlinux, it works much like LILO in this respect. Thanks for the tip. That may be an option. I looked at the documentation online, and there does not appear to be an option equivalent to lilo's vga option, though, which I use a lot, especially since svgatextmode has already been pulled from squeeze. I'm not sure what you're after, I haven't used LILO for ages. But typing vmlinuz-2.6.32 vga=0xf07 at the pxelinux boot prompt gives me a 80x60 console. The other variants use the same code. Interesting. At one point, the kernel itself had de-supported the vga boot option, relying on the boot loader to set the video mode before transferring control to the kernel. And now you're saying it's back. Hmm. According to Documentation/svga.txt in the kernel source tree: This small document describes the Video Mode Selection feature which allows the use of various special video modes supported by the video BIOS. Due to usage of the BIOS, the selection is limited to boot time (before the kernel decompression starts) and works only on 80X86 machines. Note the wording before the kernel decompression starts. That to me implies done by the bootloader, because the bootloader decompresses the kernel (if it is compressed) before transferring control to it, does it not? The vga option is a separate option in lilo. You can't include it in the append variable without lilo generating an error. You've got my curiosity up now. I'll have to try this. I do have a spare computer with which to test. I'm going to have to try installing Squeeze using extlinux as the boot loader. (No doubt I'll have to change bootloaders after installation, as the Debian Installer won't offer that option.) Then I'll see if I can pass it the vga option and have it work. And if that works, then I'll try the backup, nuke, and restore scenario. And if that works, then I may have a viable alternative to lilo. I'll let you know how it goes. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/158609809.14709.1274725819037.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Sat, 22 May 2010 23:39:52 -0400 (EDT), William Pitcock wrote: After some discussion about lilo on #debian-devel in IRC, it has pretty much been determined that kernel sizes have crossed the line past where lilo can reliably determine the payload size. This bug *can* be fixed, but not without a significant rewrite of the way that lilo's stage2 loader code works. Given that there is no active upstream and that the Debian lilo package carries many patches for bug fixes that are alleviated by standardizing on grub2, this seems like the best option for Debian. This means that users should *test grub2 extensively* before Squeeze is released so that any issues can be resolved now. As for removal, the following things need to be done: (1) The release notes need to be updated to reflect that lilo is no longer a bootloader option; (2) The debian-installer team needs to remove the lilo-installer udeb; (3) The ftpmasters need to remove lilo from unstable (which will be done using the appropriate bug filing once the above steps are made); (4) Users need to test grub2 now. First of all, forgive me for cross-posting, which is generally a no-no. But if you can cross-post, I can cross-reply. Second, unless you reply to debian-user, to which I am subscribed, please CC me. I am not subscribed to any of the other lists. I am not a Debian package maintainer or a Debian developer. I am just an ordinary system administrator. So I'm sure that my opinion will not count for much. But I am opposed to the removal of lilo. Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record (cylinder 0, head 0, sector 1). In other words they use cylinder 0, head 0, sector 2 and possibly subsequent sectors on cylinder 0 head 0. This breaks the design of the backup software that my employer uses. This backup software backs up the master boot record and all partitions; but since the extra sectors used by grub-legacy and grub-pc are outside the master boot record and are not part of any partition, they don't get backed up. Consequently, if we have a hard drive failure and restore from a backup, we have an unbootable machine. Lilo uses only the master boot record. A lilo-booted machine can be backed up and restored with our existing backup software just fine. Given these requirements, I wouldn't use grub-pc even if it were bug free and well documented. (But neither is the case!) As for the claims that kernels are too big now, I find that hard to believe, especially now that we have the large-memory option available. The standard stock Debian kernel image file that I use for Squeeze, vmlinuz-2.6.32-3-686, is currently 2234080 bytes. Are you trying to tell me that there's no room for a 2M kernel below the start of the EBDA? I am able to load *both* the kernel *and* the initial RAM filesystem below the EBDA (i.e. the large-memory option is not used) if I use MODULES=dep instead of MODULES=most in the initial RAM filesystem under Lenny. I'll bet I can do it with Squeeze too. I realize that lilo doesn't work for everyone, and I'm not suggesting that it be the default bootloader; but to get rid of it entirely is unacceptable. As far as I know, it's the only bootloader that meets all of my requirements, and I will not voluntarily give it up. No doubt you will tell me that I am welcome to maintain it myself. Unfortunately, I do not have the requisite skills to do so. All I can do is to appeal in the name of reason that it not be dropped. Also, please excuse my ignorance, but what exactly is this payload size to which you refer? Is that the same thing as the size of the kernel? Or is it something else? -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/698259750.358730.1274641482395.javamail.r...@md01.wow.synacor.com
Re: lilo removal in squeeze (or, please test grub2)
On Sun, 23 May 2010 16:11:30 -0400 (EDT), William Pitcock wrote: Stephen Powell zlinux...@wowway.com wrote: (blah blah blah blah) Nobody cares if you are opposed to it. Unless you are offering to become lilo upstream, it's going away. William I do understand why a Debian package maintainer does not wish to become upstream. And I hope that someone who is both willing and able to do so steps up to the plate. But withdrawing it from the distribution seems like overkill to me, especially since you want to withdraw it from Squeeze and not Squeeze+1. Lilo, as it exists today, works just fine for my purposes. And apparently it works just fine for a lot of other people too. The Lord bless you, William. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1170680188.363342.1274662130640.javamail.r...@md01.wow.synacor.com
Bug#447755: wishlist bug for parted enhancement opened - 578097
The bug report for the parted enhancement request is 578097. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1212829976.93964.1271514784303.javamail.r...@md01.wow.synacor.com
Bug#447755: Support for CMS formatted disks in parted
Well, it took me a *long* time. And I had to have help from a real C programmer. Someone who knew what they were doing (i.e. someone proficient in C) could have easily done it in an afternoon, I'm sure. But I have managed to add support for CMS formatted disks to parted. This will go a long way, maybe all the way, to adding support for CMS formatted disks to the Debian installer. It only works on CKD DASD, and then only when using the ECKD driver (not the DIAG driver). But switching to the DIAG driver after installation for CMS formatted disks on CKD DASD is no problem. I don't have any FBA DASD to test with; so I didn't bother even trying to add support for CMS minidisks on FBA DASD. After some more testing and code cleanup, I will open a bug report against parted with severity wishlist for adding support for CMS minidisks. Patch files will be included. As an added bonus, it will include a bug fix for correctly calculating the starting sector for an ldl formatted disk if the block size is other than 4096. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/589265991.57405.1271381734077.javamail.r...@md01.wow.synacor.com
Bug#569589: Request for additional kernel modules in D-I for s390
On Mon, 22 Feb 2010 09:02:46 -0500 (EST), Frans Pop wrote: On Friday 12 February 2010, Stephen Powell wrote: dasd_fba_mod is essential to support FBA DASD. This module is already included in dasd-modules. Well, shut my mouth! I could have sworn that I tried a modprobe dasd_fba_mod and it failed. But I just tried it again today and it worked! Who knows what fool thing I did last time. But you're right, the module is there. I stand corrected. dasd_diag_mod is necessary when using the DIAG driver, which can be used with either CKD DASD or FBA DASD. I've added this in a new udeb dasd-extra-modules. This udeb will *NOT* be loaded by default, but can be selected as an optional component in expert mode or when installing with priority=medium. Possibly it could be included by default, but have chosen this solution as I have no way to check that and don't want to risk affecting regular installs by maybe making devices visible that are not actually supported. That's fine. I've added the vmcp module to core-modules as you suggested. Thanks. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/706960503.14166671266853332614.javamail.r...@md01.wow.synacor.com
Bug#569589: Request for additional kernel modules in D-I for s390
Package: linux-kernel-di-s390-2.6 Version: 0.46 Severity: wishlist I am requesting that three additional kernel modules be added to the s390 version of the Debian Installer: vmcp, dasd_fba_mod, and dasd_diag_mod. I am assuming that vmcp belongs in core-modules-* and the other two belong in dasd-modules-*; but it is up to you how you want to package it. When used as a pure installer to install on CKD DASD, these modules are not needed. However, when used in a rescue-like mode to perform system maintenance, such as copying data to CMS-format disks, these modules are very useful. When running in a virtual machine under z/VM, vmcp allows the root user to issue commands to the CP component of z/VM, the hypervisor which manages the configuration of the virtual machine that Linux is running in. For example, the LINK or DETACH commands can be issued to dynamically add disks to or remove disks from the environment. vmcp is not essential. The alternative is to issue CP commands via #CP on the 3215 virtual console. But vmcp is a great convenience as it allows CP commands to be issued from, for example, a remote SSH client session. dasd_fba_mod is essential to support FBA DASD. The only disk format supported by the Linux kernel for use on FBA DASD is the CMS disk format, and parted doesn't support the CMS disk format. Therefore, the installer cannot install to FBA DASD. But data can be copied to FBA DASD after installation to CKD DASD. However, when attempting to use the installer in a rescue-like mode for this purpose, FBA DASD cannot be used, since there is no dasd_fba_mod kernel module. dasd_diag_mod is necessary when using the DIAG driver, which can be used with either CKD DASD or FBA DASD. With CKD DASD, support for the DIAG driver can be enabled after the fact. But according to Device Drivers, Features, and Commands, Development Stream (Kernel 2.6.32), SC33-8411-04, Chapter 3, DASD Device Driver, under the heading Enabling DIAG calls to access DASDs, the DIAG driver must be in use from the beginning when it is used with FBA DASD. I quote: Note: When switching between enabled and disabled DIAG calls on FBA-type DASD, first re-initialize the DASD, for example, with CMS format or by overwriting any previous content. Switching without initialization might cause data-integrity problems. If the goal is to use the DIAG driver to access data on an FBA DASD, then the DIAG driver must be used from the beginning when making a file system or swap space. Thus, when used in a rescue-like mode to perform this type of system maintenance, kernel module dasd_diag_mod must be available. I run the generic version of the installer, IPLed from the virtual card reader in a virtual machine under z/VM by running the DEBIAN EXEC script under the CMS operating system. The way I use the installer to do this type of maintenance is to run the installer in expert mode (debconf/priority=low), run all the steps of the installation up through and including the display of the existing partitions on the existing DASD, exit this menu without making any partition changes or assigning mount points, (Go Back) and drop into a shell. At that point, modprobe commands on vmcp, dasd_fba_mod, and dasd_diag_mod all fail. I do not run in true rescue mode (i.e. the rescue/enable=true boot parameter is not set) because I do not want the installer to attempt to mount my normal root partition as /. I want to copy that partition and chroot to the copy later. Once I am finished with my maintenance activities, I type exit to return to the installer menu, then I select Abort the installation to shut down. An example procedure for copying data to CMS-format disks can be found at http://www.wowway.com/~zlinuxman/diag250.htm. The specific example here uses a separate server, but the procedure can be adapted to use the installer in a rescue-like mode, provided these three kernel modules are available. At present, they are not. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569209: installation-reports -- Successful install of Squeeze in a virtual machine under z/VM 5.4.0, s390 port
Package: installation-reports Just completed a successful install of Squeeze using the daily build development version of the Debian installer, s390 port. Real hardware is an IBM z890 (2086). Processor is configured in LPAR mode. The LPAR uses a dedicated IFL (Integrated Facility for Linux) processor. The LPAR is running z/VM 5.4.0. The installation was run in a virtual machine under z/VM. The network device was a (virtual) OSA in QDIO mode, layer 3 mode. There was no support for CMS minidisks, but then again I was not expecting any. My only comment at this point is that the installer is currently packaged to use a 2.6.30 kernel. You might want to think about upgrading to the 2.6.32 kernel at some point, since that is the current version used by Squeeze. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447755: s390 installer doesn't support CMS minidisks; tries to mount partitions in wrong order
I just tried a new Lenny install from scratch on the s390 architecture, with one of the disks pre-formatted in ldl format. (Of course I told the Debian installer not to format it.) When I got to the partition disks step, the implicit partition present on that disk was recognized and I was able to assign a mount point to it and complete the install. This makes me optimistic that read-only support for CMS-formatted disks (reserved and non-reserved) in parted may be all that is needed to support CMS-formatted disks in the Debian installer. The installer itself may not need to be changed. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debian Installer images for s390 architecture
I am cross-posting this on both debian-s390 and debian-boot, since I'm not really sure which list it belongs on. Those of you who are subscribed to both lists, please excuse the duplicate e-mails. The daily build development Debian installer images for the s390 architecture are on a server called lophos.multibuild.org. The URL is http://lophos.multibuild.org/d-i/images/daily/ to be specific. As far as I can tell, this server is down and has been for a couple of weeks at least. Does this mean that Debian has decided to drop the s390 port? I have been waiting to do an install of Squeeze for s390 for a couple of weeks now, and I am dead in the water. I can't even get started. Have the daily build images for s390 been migrated to another server? If so, please update web page http://www.debian.org/devel/debian-installer/ to point to the correct server. If not, then please re-activate the server. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: install -- netboot vs netinst vs businesscard Debian installer CDs
On 2010-01-03 at 10:30:34, Paul E Condon wrote: I haven't been following this thread, but your statement caught my eye. This thread started on debian-user with the original title of Install. A new user asked for help in finding the right images to download to boot the Debian installer from a floppy disk. I replied that Etch was the last Debian release which supported booting the installation system from floppy disks. I said that if his computer BIOS didn't support booting from a CD, one solution would be to install Etch by booting from floppies and then upgrade to Lenny. I then recommended that if his system did support booting from CDs, he should use the CD image dists/lenny/main/installer-i386/current/images/netboot/mini.iso That sparked two other lines of discussion. The first one was whether this image was a netboot or a netinst image, and what was the difference between the two. The second topic was which installer should be used to install Squeeze. At this point, my best guess is that this is a netboot image, which is, strictly speaking, an oxymoron when it is used in this way (i.e. burned to a real CD-R and booted directly), since by definition you are not booting from the network if you are booting from a CD. Nevertheless, it is my favorite installation image since it is the smallest image (about 8M for the i386 architecture), is available from the most locations (every Debian mirror), downloads quickly, burns quickly, and is the least succeptible to bugs (since as much code as possible is downloaded from the internet, where bug fixes can accumulate after the image is burned). This boot image contains just enough code to boot the machine and configure the network. Everything else, including most of the installer code itself, is downloaded from the internet. As for installing Squeeze, I pointed out that the Lenny installer, though it will let you install Squeeze with it, should not be used to install Squeeze, and I pointed out that the production Squeeze installer is actually the Lenny installer. I recommended the daily build images available from the development pages for Debian installer to install Squeeze. Someone else pointed out that the Sid installer is apparently newer than the production Lenny installer and that he had used the Sid version of the above mini.iso image (for the power-pc architecture) to install Squeeze, and encountered no difficulty. Someone said that the daily/weekly build images don't work, and I replied that they have been having build problems the last few weeks and referred him to the debian-cd list for a discussion of the build problems. I can't speak for others, but I'm not really trying to figure out what went wrong at this point. I'm just waiting for the daily/weekly build people to get their act together and start building daily/weekly images that work and are accessable again. And that's where we sit at this point. At this moment, it looks like the Sid version of the mini.iso image dists/sid/main/installer-i386/20091215/images/netboot/mini.iso is the best bet to try a Squeeze install from scratch, since the daily/weekly builds appear to be broken at the moment. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447755: Minidisk support
On 2009-12-25 at 03:11:18 -0500, Frans Pop wrote: I've just taken a look at the source for parted (Debian unstable version), and the problem seems fairly obvious. In libparted/labels/dasd.c there's a function dasd_read() which very clearly only supports LDL and CDL formatted dasds. So someone will need to implement CMS support in parted before Debian Installer can be made to support CMS formatted mini disks. I'm cloning this BR to parted so that its maintainers can take a look at that, but probably someone from the s390 community will need to provide a patch to the upstream developers. Hmm. OK, well if that's necessary. But I think if upstream looks at the previous two updates to this bug report by me, that should give them enough information to add read-only support for this disk format. I don't need read-write support (create, destroy, resize, move and copy). I'm content to leave those functions to CMS. All I need is for it to recognize the (single) partition and report on it statistically, so that Debian installer can assign it a mount point, create a file system on it, create a swap space on it, or copy data to it. I will be glad to answer any questions they may have. If they have questions that I can't answer, then maybe they will need to recruit someone from the Linux for s390 community as well. But that may not be necessary. I am also assuming that you no longer need me to run the test install that you described earlier. If you still need or want me to run it, please let me know. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447755: Minidisk support (was: Installation Question)
On 2009-12-24 at 12:32:18 -0500, Frans Pop wrote: The output of the following command would be useful as well: # parted /dev/device print bash: parted: command not found Of course, I wasn't running D-I at the time, I was running the installed system. Do I have to run D-I? Or is there a package that I can install (which one) on the installed system that will give you the same information? Does it make a difference whether the device is currently being driven by dasd_diag_mod or dasd_eckd_mod? -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447755: Minidisk support (was: Installation Question)
On 2009-12-24 at 10:56:59 -0500, Frans Pop wrote: Please send the replies for these questions to the BR instead of the list! Replying to the bug report, per your request. On 2009-12-24 at 10:56:59 -0500, Frans Pop wrote: 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. I'll certainly try! On 2009-12-24 at 10:56:59 -0500, Frans Pop wrote: If you could provide me with access to a system that has these disks mounted that might work as well. I personally wouldn't mind doing that, but management will not permit that. On 2009-12-24 at 10:56:59 -0500, Frans Pop wrote: To start with: - What device name does such a partition have? - How could it be distinguished from a partitionable dasd? The definitive documentation for this is in Device Drivers, Features, and Commands, which is available on the Internet. I'm not sure which version of that document corresponds to the level of code that Debian is using, but to answer these questions just about any version will do. Here is one link that you can use, if you don't already have a link to go on: http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/l26cdd04.pdf Devices supported by the dasd drivers all have a major node number of 94. Four minor numbers are reserved for each dasd device, though not all of them are necessarily assigned. The first dasd device recognized will have a device name of /dev/dasda and will have a minor number of 0. Thus, (94,0) is the (major,minor) pair assigned to the *device itself*. A DASD device may have up to three partitions, which take up the next three minor numbers. So if the first dasd device recognized has its maximum number of three partitions, (94,1), (94,2), and (94,3) would be the major and minor numbers of the first, second, and third partitions, respectively, on that device. The corresponding device names are /dev/dasda1, /dev/dasda2, and /dev/dasda3. The second dasd device recognized has a (major,minor) pair of (94,4) for the device itself, and up to three partitions, numbered (94,5), (94,6), and (94,7). The corresponding device names are /dev/dasdb (device itself), /dev/dasdb1 (first partition), /dev/dasdb2 (second partition) and /dev/dasdb3 (third partition). Note that the second device recognized has a (major,minor) pair of (94,4) in all cases. It does not matter how many partitions the first device actually has. It may be zero partitions. No matter. The second device still starts at (94,4). The first 26 devices take up /dev/dasda through /dev/dasdz. After that, it does to two letters: /dev/dasdaa, /dev/dasdab, /dev/dasdac, ... /dev/dasdzz. Then it goes to three letters: /dev/dasdaaa ... then finally to four: /dev/dasd ... /dev/dasdnwtl. This is a total of 262144 devices supported (devices, not partitions). The correspondence between Linux device names and s390 device numbers is tricky. I believe the dasd parameter passed to the dasd_mod kernel module is processed left-to-right, if it exists, and Linux device names and s390 device numbers are associated from there first. After that, I believe it scans the list of subchannels, in subchannel id order, picks out the dasd devices, and assigns linux device names in that order. But subchannel id order and device number order are generally not the same. In other words, just because s390 device number 0200 corresponds to /dev/dasda doesn't necessarily mean that s390 device number 0201 will correspond to /dev/dasdb. It could be anything. In modern versions of the linux kernel, you don't need to issue mknod commands to define these devices: udev does it for you. udev also creates symbolic links to make it easy to refer to a device by s390 device number. For example, if s390 device number 0200 corresponds to /dev/dasda, and it has one partition, udev will create the following symbolic links: cd /dev/disk/by-path ln -s ../../dasda ccw-0.0.0200 ln -s ../../dasda1 ccw-0.0.0200-part1 Thus, /dev/disk/by-path/ccw-0.0.0200 is a symbolic link to /dev/dasda and /dev/disk/by-path/ccw-0.0.0200-part1 is a symbolic link to /dev/dasda1. udev only creates device nodes and symbolic links for devices and partitions that actually exist. When the kernel brings a device online, it tries to read the first few blocks to determine the format. If the read is unsuccessful, or if it does not recognize the format, udev only creates a device name. If it recognizes one of the four supported formats: cdl, ldl, CMS non-reserved, or CMS reserved, then it also creates one or more partition names. cdl is the only format that can have more than one partition. The other three formats, by definition, only have one partition. In the case of CMS reserved, the partition is created explicitly by the CMS RESERVE command. In the case of ldl and CMS non-reserved, the partition is implicit. Note that, while you don't have the facilities to create CMS non-reserved or CMS reserved disks, you *can*
Bug#447755: Minidisk support (was: Installation Question)
On 2009-12-24 at 14:34:26 -0500, Frans Pop wrote: I would really like to know *exactly* what devices exist in Debian Installer when you get to the partman stage. The /var/log/partman log file as it is at the point after partman has initialized itself would also be useful. I guess you'll have to set up a small scratch system you can play with and run repeated installations on while we're working on this. Do you want me to use the production (Lenny) installer? Or do you want me to use the daily build from Squeeze to do the installs? The output of the following command would be useful as well: # parted /dev/device print After installing parted (Version 1.8.8.git.2008.03.24-11.1, remember this is a production Lenny system) I now get: odocdeb1:~# parted /dev/dasdb print Error: /dev/dasdb: unrecognised disk label For a CMS-format disk on an ECKD device, the first two physical blocks are IPL records. The third physical block (cylinder 0, head 0, record 3) is the CMS disk label, whose exact format I can supply if you need it. (On an FBA DASD, the second block is the disk label. That's physical block 1, counting from 0.) The first four bytes of the label are CMS1 in EBCDIC, which is X'C3D4E2F1' The next six bytes are the volume serial number in EBCDIC. For example, if the volser is DEB200, that would be X'C4C5C2F2F0F0'. The other fields I can get for you if you need it. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#447755: CMS minidisk label format
Just for grins, I thought I'd give you the full mapping of the CMS volume label. This is in s390 assembler language format: ADTIDENT DSCL4LABEL IDENTIFIER (CMS1) ADTIDDSCL6VOLUME IDENTIFIER (VOLSER) ADTVER DSCL2VERSION LEVEL ADTDBSIZ DSF DISK BLOCK SIZE ADTDOP DSF DISK ORIGIN POINTER ADTCYL DSF NUM OF FORMATTED CYL ON DISK ADTMCYL DSF MAX NUM FORMATTED CYL ON DISK ADTNUM DSF Number of formatted blocks ADTUSED DSF Number of blocks used ADTFSTSZ DSF Size of FST ADTNFST DSF Number of FSTs per block ADTDCRED DSCL6Disk creation date (yymmddhhmmss) ADTFLGL DSX Label flag byte ADTCNTRY EQU X'01' Century for disk creation date * (0=19, 1=20), corresponds to * ADTDCRED. DSCL1RESERVED ADTOFFST DSF DISK OFFSET WHEN RESERVED ADTAMNB DSF ALLOC MAP BLOCK WITH NEXT HOLE ADTAMND DSF DISP INTO HBLK DATA OF NEXT HOLE ADTAMUP DSF DISP INTO USER PART OF ALLOC MAP ADTOFCNT DSF RESERVED ADTSFNAM DSCL8RESERVED That's 80 bytes. The rest of the block is not used. The most interesting field to Linux is ADTOFFST, which is a 32-bit big-endian unsigned binary number that is zero if the disk is non-reserved and non-zero if the disk is reserved. If the disk is non-reserved, Linux assumes that the single implicit partition starts at the block following the volume label, which for a CKD DASD is the fourth physical block (block 3 counting from zero), and ends at the end of the disk. If the disk is reserved, ADTOFFST is the starting block number (counting from zero) of the single explicit partition created by the CMS RESERVE command. The partition ends at the end of the disk. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558424: console-setup does not honor video mode set by boot loader
Package: console-setup Version: 1.49 See Debian bug report 558414 against console-tools for more information. The init script for console-setup, /etc/init.d/console-setup, when invoked during boot-up, does not respect the video mode selected by the boot loader or the font selected by console-tools. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)
I have just been informed by the current maintainer of zipl that CMS minidisks are now supported by zipl as a /boot partition, provided that the dasd_diag driver is not used for the /boot partition. This is a minor technical correction to previous information stated in the problem log. It does nothing to change the basic problem, which is that the Debian installer supports only cdl minidisks and has no support for ldl or CMS minidisks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)
All the above is complete Greek too me because I don't have any context. And it sounds like you already did the hard part: you managed to get it working. That means you are the expert now. Tell us *in detail* what is missing and what manual steps were required to get it supported. Then *maybe* someone will step up and do the actual integration. Here is my DASD configuration. All devices are 3390 ECKD minidisks in a virtual machine under z/VM: vdev format and intended usage --- 0200 CMS FORMATted and RESERVEd minidisk - to be mounted as / 0201 cdl minidisk - to be mounted as /boot 0202 CMS FORMATted and RESERVEd minidisk - to be mounted as /home 0203 CMS FORMATted and RESERVEd minidisk - to be used as a swap disk 0200, 0202, and 0203 were FORMATted and RESERVEd in advance under the CMS operating system with a block size of 4096 bytes. 0201 was not formatted. I got along just fine until the step Partition Disks. During the previous step, Configure DASD, I selected the four devices listed above, but I told it NOT to format 0200, 0202, and 0203, lest the CMS formatting be destroyed. I DID tell it to format 0201; so it ran dasdfmt on that device. When I got to the Partition Disks screen, here is what I saw: -- ┌┤ [!!] Partition disks ├─┐ │ │ │ This is an overview of your currently configured partitions and mount │ │ points. Select a partition to modify its settings (file system, mount │ │ point, etc.), a free space to create partitions, or a device to │ │ initialize its partition table. │ │ │ │Help on partitioning │ │ │ │DASD 0.0.0200 (ECKD) - 1.5 GB s390/zSeries DASD │ │DASD 0.0.0201 (ECKD) - 55.3 MB s390/zSeries DASD │ │ 55.2 MB FREE SPACE│ │DASD 0.0.0202 (ECKD) - 368.6 MB s390/zSeries DASD│ │DASD 0.0.0203 (ECKD) - 368.6 MB s390/zSeries DASD│ │ │ │Undo changes to partitions │ │Finish partitioning and write changes to disk│ │ │ │ Go Back │ │ │ └─┘ Tab moves between items; Space selects; Enter activates buttons -- As you can see, the installer recognized the free space on 0201; so the installer can create a cdl partition on this minidisk with fdasd. But the implicit partitions associated with the CMS minidisks are not recognized. Therefore the installer cannot create a file system on them or assign a mount point. Now, how did I circumvent this? Well, there's more than one way to skin a cat. One way is to install to regular cdl minidisks, then copy the data manually to CMS minidisks once the install is finished. It works, but it requires almost twice as much disk space, takes a lot of time to copy the data, and is error prone. I have recently worked out a better way, as documented below: Run the installer in expert mode. After you have invoked the Partition disks step and seen the above screen, tab to Go Back and press Enter. (Do not skip this step! Some important utilities are downloaded when you select Partition disks that you are going to need, even though the step does not complete.) When you get back to the installer main menu, select Execute a shell and press Enter. At the shell prompt, type the following command: cat /proc/dasd/devices This gives you the association between DASD device addresses and Linux device nodes. In the following discussion, I will assume that 0200 corresponds to dasda, 0201 corresponds to dasdb, 0202 corresponds to dasdc, and 0203 corresponds to dasdd. Now issue the following commands: mke2fs -j -b 4096 -L TLS200 /dev/dasda1 fdasd -a -l TLS201 /dev/dasdb mke2fs -j -b 4096 -L TLS201 /dev/dasdb1 mke2fs -j -b 4096 -L TLS202 /dev/dasdc1 mkswap /dev/dasdd1 mkdir /target mount -t ext3 /dev/dasda1 /target mkdir /target/boot mount -t ext3 /dev/dasdb1 /target/boot mkdir /target/home mount -t ext3 /dev/dasdc1 /target/home swapon /dev/dasdd1 exit and resume the install. Skip the Partition disks step and select Install the base system as the next step. The installer will complain that this step
Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)
I need to correct an error in my previous e-mail. In my previous e-mail, I said that the dasd_diag_mod driver could only be used with CMS minidisks. As it turns out, that is not true. The dasd_diag_mod driver can also be used with minidisks formatted with the Linux disk layout (ldl). Such a format is created by using the -d ldl switch of dasdfmt. And such a disk can also be used as the /boot partition. By switching my 201 disk to an ldl-format disk, I was able to use the dasd_diag_mod driver for ALL the minidisks. Thus, /etc/modprobe.d/dasd now looks like this: options dasd_mod dasd=0.0.0200-0.0.0203(diag) Like CMS minidisks, ldl disks contain one implicit partition and do not need to be partitioned separately with the fdasd utility. Just for grins I tried using a CMS minidisk as the /boot partition. When I ran zipl to write out the boot loader code, it gave me an unsupported disk type error message, as I expected. In summary: 1. The DASD driver for Linux for System z supports three disk formats: CMS, ldl, and cdl. 2. The CMS format has two sub-formats: non-reserved and reserved. 3. The /boot partition cannot be CMS format. (If the /boot directory is included in the / partition, then the / partition cannot be CMS format.) 4. The ECKD driver supports all three formats: CMS, ldl, and cdl. 5. The DIAG driver supports two formats: CMS and ldl. 6. The FBA driver supports only CMS format. 7. CMS-format disks can only be created by the CMS operating system running as a guest under z/VM. Linux can USE CMS-format disks, but it cannot CREATE them. 8. The DIAG driver can only be used if Linux is running as a guest under z/VM. 9. The Debian installer supports only the cdl format. Therein lies the problem. An interesting question is how to IPL the boot loader if all one has is FBA DASD. Perhaps zipl can be IPLed from a CMS minidisk if the CMS minidisk is on FBA DASD, but not if it is on ECKD DASD. I suspect that that is the case, but I don't have any FBA DASD with which to test my theory. Anyway, I wanted to correct the factual error in my prior e-mail. If there's anything else you want to know, or if there's anything I can do to help, please ask. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)
To be honest: that is not very likely. Especially not in this case. Suppose we push them all upstream and only one upstream actually picks it up and we implement that. That would still leave us nowhere... I see what you mean. It's double or nothing. Without mke2fs support for respecting the RECOMP area (and mkreiserfs, and all other supported file systems), support for IPLing zipl from a CMS minidisk is a moot point. zipl will never see a RECOMP area because mke2fs (or whatever) wiped it out when the file system was created. I'm afraid that partman is _very_ Debian specific and you're basically talking to the upstream (the team behind debian-boot mailing list). OK. Well, support for recognizing the implicit partition of a CMS minidisk is independent of respecting a RECOMP area. Those are two separate issues. The former is a deficiency in the installer. The latter is an enhancement request. As it stands today, the Debian installer cannot install Debian GNU/Linux to CMS minidisks, period. As far as GNU/Linux itself is concerned, the only part of the filesystem which cannot be on a CMS minidisk is the /boot directory. All other parts of the filesystem and all swap partitions can be on CMS minidisks. But the Debian installer cannot currently handle them. I currently have a Debian GNU/Linux system running in a virtual machine under z/VM that uses CMS minidisks. But I had to install to cdl disks and then use the installer as a rescue floppy to copy the data to CMS minidisks. Another problem is that the dasd_mod driver does not automatically bring CMS minidisks on-line. I had to create a file called dasd in /etc/modprobe.d to supply options to dasd_mod to bring these minidisks online at IPL time. (And then I had to run update-initramfs and zipl.) It worked. But figuring out what to do and how to do it was not trivial. And of course, there is nothing in the install manual about this. I would hardly call this a user-friendly install. Further complicating matters was my desire to use the dasd_diag_mod module to do the I/O, which did not exist in the stock kernel for etch. I had to download the kernel source package and create a custom kernel in order to use dasd_diag_mod. (And then I had to update /etc/modprobe.d/dasd again to tell dasd_mod to use dasd_diag_mod for all the CMS minidisks, and then I had to run update-initramfs and zipl again.) Fortunately, it appears that the 2.6.24 stock kernel for lenny now includes this module. :-) It is possible to get it working. But when it comes to CMS minidisks, Debian for s390 is definitely a hacker's distro only. For what it's worth, the S390 Linux community is a vibrant one. Great. Question is how to translate that into active involvement in the Debian s390 port. Ah, yes. That is the question. I think there would be more involvement (from the development and support perspective) in the Debian s390 port if there were more System z shops using the Debian s390 port. Similarly, there would be more System z shops using the Debian s390 port if it were better supported. As you yourself have admitted, support for this port is pretty thin. In many ways this is a Which came first, the chicken or the egg? scenario. But if it is so difficult to install in an optimal way for a z/VM guest, that is a barrier to wider use. This is going to be a rather long reply. Sorry. But you asked. Let's look at this from IBM's perspective. IBM spent a fortune in the 1990s trying to promote their i386 operating system -- OS/2 -- and lost. They not only lost the desktop (and server) war, they also lost a lot of money. IBM likes Linux because they don't have to spend much money on development and support costs. They don't own it or control it. But then again, neither does Microsoft. :-) On the mainframe platform, they make money with Linux primarily by (a) selling more mainframe hardware to support Linux and (b) by selling software licenses for proprietary software that runs on Linux, such as DB2. They want the Linux community to support their hardware. But they want to keep their support costs down. The more Linux distributions they have to support, the higher their support costs. So they pick a couple of distros to support and ignore the rest. Significantly, they picked two distros that both use rpm-format packages. Here's an example. As I said earlier, I am a z/VM systems programmer at an IBM mainframe shop. I'm getting ready to install z/VM 5.3. One of the enhancements to z/VM 5.3 is that TCP/IP now supports SSL/TLS for its FTP client and FTP server. (I'm talking here about the FTP client and FTP server that run under the CMS operating system.) For some reason, they decided to implement the SSL encryption and decryption in a separate service machine which runs Linux. (I suppose it was cheaper than porting the entire SSL support infrastructure to CMS.) That's an
Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)
Package: partman-base Version: 105 This bug applies only to the s390 and s390x architectures. The single partition implicitly created on a z/VM minidisk by the CMS FORMAT command (and optionally, the CMS RESERVE command) is not recognized by partman. mke2fs, mkswap, etc. recognize such a partition and are able to use it. But partman does not. I don't expect partman to be able to do anything with such a partition (such as create, move, resize, etc.) other than to recognize that it is there, delete it (if requested), optionally format it with mke2fs, mkswap, etc., if needed or requested, and to assign mount points to the partition (technically, to the file system on the partition, whether pre-existing or just created). Note: partman should warn, if requested to delete such a partition, that if the partition is deleted it cannot be recreated again except by the CMS FORMAT command (and optionally, the CMS RESERVE command). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only)
Thanks for your reply, Frans. As for the enhancement requests for e2fsprogs and s390-tools to respect and support the RECOMP option of CMS minidisks, those are not distribution specific. I would hope that they could be bumped upstream. In theory, partman is not distribution-specific either, and, in theory, could also be bumped upstream. However, if other distributions do not use partman in their installers or post-install packages, there may be little interest in the enhancement. As for me, I am a z/VM Systems Programmer, I do have an interest, I do have some time, and I do have access to z/VM and mainframe hardware. And I would be glad to assist you in testing. What I don't have is expertise in C. I can barely spell C. My background is as a mainframe applications programmer and systems programmer, with IBM S390 assembler language programming skills, FORTRAN programming skills, and PL/I programming skills. But C is another story. So I can't code anything, probably, but I can serve as a resource for mainframe and z/VM information and I can probably help you test some things. Perhaps between the two of us we can work something out. For what it's worth, the S390 Linux community is a vibrant one. But most mainframe shops seem to run either Suse or Red Hat. I'm playing around with Debian on S390 because that's what I run at home and that's what I know best. I'm going to be attending a class next week taught by IBM on how to install Linux on System z, and I'm sure that they will talk pretty much exclusively about Suse and Red Hat, both of which are commercial distributions and both of which are IBM partners. I've attended Linux for S390 install classes before, but it's been about five years and it's time for an update. In the process of taking the class, I'm going to be privately trying to determine if there is any strategic advantage to those distros other than a support contract. Let me know if there's anything I can do. --- On Mon, 6/16/08, Frans Pop [EMAIL PROTECTED] wrote: From: Frans Pop [EMAIL PROTECTED] Subject: Re: Bug#486549: The single partition present on a CMS minidisk is not supported (s390/s390x only) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Date: Monday, June 16, 2008, 3:39 PM tag 486549 help severity 486549 wishlist thanks On Monday 16 June 2008, Stephen Powell wrote: The single partition implicitly created on a z/VM minidisk by the CMS FORMAT command (and optionally, the CMS RESERVE command) is not recognized by partman. Your request is no doubt completely valid, as is the one to extend zipl (#486526). However, you should be aware that the main challenge for the Debian s390 port is the current total lack of involvement from the s390-using community. Effectively this probably means that unless you or someone else can motivate people who have an interest, the skills and access to hardware needed to implement the needed changes, it is very unlikely that any progress will be made. Therefore I'm tagging this bug report 'help'. The Debian Installer team will of course be more than happy to help those people to get started and find their way in the D-I components and build system. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481514: Poor mouse configuration with debian-installer
Package: installation-reports Boot method: CD-ROM Image version: etch 4.0r1 Date: May 3, 2008 Machine: Dell Inspiron 4400 Processor: Intel Pentium 4 Memory: 512M Partitions: 4 (1 Windows NTFS, 1 Linux swap, 1 root (/), 1 home (/home)) Output of lspci -nn and lspci -vnn: N/A Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [ ] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: I took the default for priority (i.e. no boot parameters) and in tasksel I selected only standard system and desktop environment. The mouse was a PS/2-style mouse, was detected, and was installed for use in the X Window System. But the X server was configured to drive the mouse directly rather than through the gpm daemon. In my opinion, gpm should have been installed automatically and the X server should have been configured to use /dev/gpmdata as the mouse device. This would allow the mouse to be used both in X and in regular virtual consoles. This provides maximum flexibility. In my opinion, the user has everything to gain and nothing to lose by using gpm instead of direct control of the mouse by the X server. Even if the user does not ever use the mouse in a virtual console, using gpm provides more flexibility in the X server. For example, when using gpm, one can unplug the mouse and plug in a different one without restarting the X server. Simply restart the gpm daemon. All the X aplications keep running without missing a beat. gpm should be installed by default when the user requests a desktop environment, and the X server should be configured to use gpm. Indeed, one could even make a case that gpm should be installed by default even when the user requests only a standard system, if a mouse is detected. gpm should also be on CD number 1, particularly if it is going to be installed by default. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451981: Link rot in etch s390 installation guide
package: installation-guide Debian GNU/Linux Installation Guide (etch, S/390 architecture, English) Chapter 3, Before Installing Debian GNU/Linux Section 3.3, Information You Will Need Topic 3.3.1, Documentation Subtopic 3.3.1.3 S/390 Hardware References URL: http://www.debian.org/releases/stable/s390/ch03s03.html.en First of all, reference is made to kernel 2.4 instead of kernel 2.6. Installation instructions and device drivers (DASD, XPRAM, Console, tape, z90 crypto, chandev, network) for Linux on S/390 using kernel 2.4. Since etch uses a 2.6.18 kernel, the above reference to kernel 2.4 should be changed to a reference to kernel 2.6. Second, the first bullet point is entitled, Device Drivers and Installation Commands. The name of the document has been changed. It is now called, Device Drivers, Features, and Commands. This name change should be reflected in the bullet point. Thirdly, this bullet point is also a hypertext link, with an associated URL name of http://oss.software.ibm.com/developerworks/linux390/docu/l390dd08.pdf. This URL does not exist; and if one clicks on the link one is redirected to http://www.ibm.com/developerworks/opensource/, which is a web page on the general topic of IBM open source software, but is not the desired document. I have been able to find the correct document at the following URL: http://download.boulder.ibm.com/ibmdl/pub/software/dw/linux390/docu/l26cdd02.pdf. Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447755: s390 installer doesn't support CMS minidisks; tries to mount partitions in wrong order
Package: installation-reports Boot method: VM reader Image version: /dists/etch/main/installer-s390/20070308etch1/images/generic/* Date: 2007-10-19 Machine: ESA/390-mode virtual machine under z/VM 5.2.0 Processor: 2086 (z/890) IFL (real processor) Memory: 512M (virtual machine memory) Partitions: ADDR DEVT CYLS MOUNT COMMENTS - 0200 3390 2000 / CMS FORMAT/RESERVE 0201 3390 75 /boot Linux cdl 0202 3390 500 /home CMS FORMAT/RESERVE 0203 3390 543 swap CMS FORMAT/RESERVE Output of lspci -nn and lspci -vnn: N/A Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [N/A] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: The s390 Debian installer, running in a virtual machine under z/VM, cannot handle minidisks which have been pre-formatted by the CMS FORMAT command, whether they have been processed by the CMS RESERVE command or not. The installer detects the minidisks and will bring them online if they are selected. The installer also allows the low-level formatting of these disks (dasdfmt) to be skipped. However, the installer does not recognize the implicit single partition which is already present on these minidisks. Therefore, there is no way to tell the installer to high-level format (mke2fs) these partitions, nor to assign a mount point to these partitions. I eventually got the system configured the way I wanted it, but I had to do the installation to Linux cdl minidisks and then manually copy everything (except the /boot partition) to CMS-formatted minidisks. The requirement to do this turns Debian into a hacker's distro again and defeats the purpose of the nice installer. Support for CMS-formatted minidisks is important because they are the only format of minidisk which works with the dasd_diag driver, which I wanted to use. (Incidentally, the default kernel image does not include the dasd_diag_mod module, which it should. I had to download the kernel source code and configure and build my own kernel to get the dasd_diag_mod module that I needed.) Another problem with the installer is that it tries to mount the partitions in the order listed on the screen instead of in the order required by the file system. For example, if one wants device 200, partition 1, to be the /boot partition and device 201, partition 1, to be the / partition, this will fail. It should try to mount / first, then /boot. Instead, it tries to mount /boot first, which fails because / is not yet mounted. Follow the tree structure, not increasing device numbers! __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
