Re: [PATCH] installer: add a malta image
Aurelien Jarno wrote: [snip] Index: build/config/mipsel.cfg === --- build/config/mipsel.cfg (révision 50970) +++ build/config/mipsel.cfg (copie de travail) @@ -1,4 +1,4 @@ -SUBARCH_SUPPORTED = cobalt sb1-bcm91250a sb1a-bcm91480b qemu +SUBARCH_SUPPORTED = cobalt sb1-bcm91250a sb1a-bcm91480b qemu malta MKLIBS = mklibs-copy Index: build/config/mips.cfg === --- build/config/mips.cfg (révision 50970) +++ build/config/mips.cfg (copie de travail) @@ -1,4 +1,4 @@ -SUBARCH_SUPPORTED = r4k-ip22 r5k-ip32 sb1-bcm91250a sb1a-bcm91480b miniiso qemu +SUBARCH_SUPPORTED = r4k-ip22 r5k-ip32 sb1-bcm91250a sb1a-bcm91480b miniiso qemu malta Not 4kc-malta as subarch name? Thiemo
Re: [PATCH] linux-{kernel,modules}-di-mips{,el}: add support for MIPS Malta
Aurelien Jarno wrote: On Sun, Jan 20, 2008 at 08:10:07PM +0100, Frans Pop wrote: On Sunday 20 January 2008, Aurelien Jarno wrote: +++ kernel/linux-kernel-di-mips-2.6/modules/4kc-malta/fb-modules (révision 0) @@ -0,0 +1,25 @@ +aty128fb +atyfb +radeonfb +cfbcopyarea +cfbfillrect +cfbimgblt +cyber2000fb +kyrofb +macmodes +g450_pll +matroxfb_DAC1064 +matroxfb_Ti3026 +matroxfb_accel +matroxfb_base +matroxfb_crtc2 +matroxfb_g450 +matroxfb_misc +neofb +nvidiafb +pm2fb +savagefb +sisfb +sstfb +tdfxfb +tridentfb Are those really all needed and are they actually used during installation? I have actually copied this file from the sb1a-bcm91480b flavour (with minor modifications). This board is similar to the Malta one by the fact it supports PCI cards. Those modules are not needed for the QEMU emulation, but I don't really know if they are useful or not for the real board. The Malta firmware (YAMON) doesn't support graphic consoles. IOW, a serial line is at least needed to start the installer. Once the kernel is started, it could use the framebuffer console if a PCI card is present, altough this is not the typical mode of operation. So, yes, the modules could be used, but using them during installation doesn't add much value. Thiemo
Re: [PATCH] libdebian-installer: add support for MIPS Malta
Otavio Salvador wrote:
Aurelien Jarno [EMAIL PROTECTED] writes:
Otavio Salvador a écrit :
Aurelien Jarno [EMAIL PROTECTED] writes:
+static struct cpu system_malta_cpu[] = {
system_mips_malta_cpu would be clearer, IMO.
Well other names from the same file (which BTW has mips in its name)
don't contain mips, that's why I did the same. But that can be changed.
Personally I think it would be easier for someone reading the code if
we put it there (and also fixes the missing ones). What others think
about it?
I don't believe using redundant namespaces will help understanding.
In worst case it adds more confusion about mips/mipsel. That's why
I wrote the original code that way.
Thiemo
Re: Debian Installer Status Update - August 31th 2007
Martin Michlmayr wrote: * Otavio Salvador [EMAIL PROTECTED] [2007-08-31 14:06]: * mips and mipsel builds are still broken. I built daily images on mipsel today and they built just fine. Maybe Thiemo can enable his images again. Done for mipsel, on my mips build machine make fails with tree walk failed. I suspect it comes down to a kernel problem (it is an old non-debian one), I try a kernel upgrade. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Updating kernel udebs to 2.6.20
Frans Pop wrote: [snip] For mips(el): In input-modules for bcm* kernels, usbmouse is currently included. AFAIK that module should not be needed and that module could be removed. I don't see why, the 91250 has USB on board. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416119: installation-guide-i386: use qemu to test you'll reboot correctly (limited use)
supaplex wrote: Package: installation-guide-i386 Severity: wishlist FWIW, I used qemu to test my remote install of debian will boot correctly. There are some outstanding issues with this line of thought. However, for those that want to persue this, it can be a comfort to have a high degree of confidence the system will survive the next reboot. (if it's 100s-1000s of miles/km away, you're hosed if it dies!) This is an invalid assumption, as qemu emulates a different set of devices than modern hardware typically has. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Etch netinstaller has no eth0 in qemu
Uwe Dippel wrote: Subject says it: debian-testing-i386-netinst.iso (20070303) does not 'see' the eth0 offered by qemu. I have checked with dmesg | grep eth0, it is empty. It is no qemu problem, since in all other images I use: KNOPPIX, DSL, ... eth0, comes up properly. On the .iso as well as on the ensuing 'hard disk' installs, on both the Knoppix-Debian as well as DSL image. My qemu is of version 0.8.2. Except here. So for me, the chance to test Etch netinstaller on qemu is out, alas. Is this problem limited to the qemu default NIC (IIRC a rtl8029), or does it occur also with oter NICs, e.g. -net nic,model=rtl8139 ? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405468: tasksel: Please include wdm in xfce task
Joey Hess wrote: Holger Wansing wrote: wdm should be included in that task to have graphical login screen available. That installs only 3 packages (libungif4g, libwraster3 and wdm) and needs only 1630kB additional memory on disk. Is there some reason why you're suggesting wdm be used, instead of xdm? It is a bit friendlier to use than xdm but still reasonably lightweight. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian on SGI Altix IA-64
Christian Perrier wrote: If anybody is interested, you can find the CD and a text describing what we did to make it work at: http://rad.bioinfo.ulaval.ca/hardware/altixia64/ I tried to read the document quickly, but it's not really easy to dig out which changes would be needed. It seems that you added some modules. Are these modules DFSG-compliant? If they aren't, I'm afraid that it will be hard to have them on the official Debian CD. If they are.I'm afraid it is very late now to add them to the Debian stock kernel. At least the IOC4 is already a module of the Debian ia64 kernels. I figure it isn't known to kernel-wedge as a valid boot device, so it's absent in d-i. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deactivated languages
Jens Seidel wrote: [snip] PS: Frans, in your last mail to this issue (many months ago) you just wrote that you do not want to reply to me until I calm down. This is not necessary. I'm really able to participate in serious discussions but the problem is there there was *never* such an (public) discussion and never good reasons for this decision. IIRC this discussion happed in 2004, before Frans took over from Joey. The consensus back then was that a partial translation is worst because it leads people not fluent in English to invest their time just to fall over a obstacle later. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395262: Arch: all package FTBFS due to test needing network access - RC?
Sven Luther wrote: On Wed, Nov 01, 2006 at 11:53:32PM -0600, Peter Samuelson wrote: Robert Collins [EMAIL PROTECTED] writes: I can also note why bazaar wont build as root: its test suite includes a test for the ability to handle read only directories correctly. As root, anything is writable, so this test fails. [Goswin von Brederlow] That test should add a test for root and skip it. If that is the only reason not to build as root then that should be no excuse (post etch). Your unspoken premise is that there is a _reason_ to support building packages as root. Why? I think it is better just to tell people not to do that. Do some arch not have trouble with fakeroot, and need sudo to work ? This means you need to be able to build packages as real root, no ? Or was this fixed lately ? I think mips/mipsel, and some other arch where concerned. For mips/mipsel this was fixed before sarge. The autobuilder continue to use sudo, and catch some bugs that way. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Kernel boot parameter on mips (SGI)
Jens Seidel wrote: Hi, http://www.us.debian.org/releases/etch/mips/ch05s01.html.en contains: quote 5.1.2.1. SGI TFTP Booting On SGI machines you can append boot parameters to the bootp(): command in the command monitor. Following the bootp(): command you can give the path and name of the file to boot if you did not give an explicit name via your bootp/dhcp server. Example: bootp():/boot/tftpboot.img Further kernel parameters can be passed via append: bootp(): append=root=/dev/sda1 /quote I tested an install on a SGI Octane using the kernel linux-image-2.6-r10k-ip30 (2.6.12-3) from experimental. I failed to mount the root filesystem (I tried really everything, such as an NFS root (fails probably because of kernel network settings), a copy of a boostraped system on /dev/sdb directly in my IRIX system) but noticed that bootp(): append=arg1 arg2 is interpreted as kernel command line append=arg1 arg2 by the kernel. So it is necessary to omit append= and the quotes. Comments? Maybe it's only my system which doesn't support append? The append syntax is specific to arcboot/tip22/tip32 images. The raw ELF kernel uses the simpler syntax you discovered. At the moment arcboot doesn't support Octane and Origin machines. There is, however, arcload, which is not packaged in Debian but used for the Gentoo live CD. Next step I will try is to cross compile a newer kernel from http://www.linux-mips.org. My first attempt failed because linux-2.6.18.1.tar.gz seems not to support IP30 anymore. I will try different versions or directly from git ... A patchset is available at ftp://ftp.linux-mips.org/pub/linux/mips/people/skylark/ Or is there a simple way to provide an initrd? All Mips build I checked contain only a kernel image ... I'm afraid the simplest way is currently installing via NFS root, or compiling in a initramfs. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Preparing linux-2.6 2.6.18-1
Nathanael Nerode wrote: Steve Langasek wrote: If it is the consensus of the project that sourceless firmware doesn't belong in main, this is a conscious regression in DFSG-compliance relative to sarge. I don't think that's acceptable. We obviously do have the means to remove this particular subset of non-free firmware from main (technically imperfect though it may be), and of the firmware that was removed for sarge the only one that was important enough to get me glared at personally was qla2xxx -- so what are these other already-removed firmwares that are so important to have re-added now? (I did ask for a list, which no one has provided yet; I can't find the pruning script in the kernel team's svn repo, or I would look it up myself.) Here you go, Steve. drivers/media/video/dabfirmware.h drivers/net/acenic_firmware.h drivers/net/dgrs_firmware.c drivers/net/tokenring/smctr_firmware.h drivers/usb/misc/emi62_fw_m.h drivers/usb/misc/emi62_fw_s.h The above are all undistributable: smctr_firmware.h under a use-only license, the others because they are GPL without source or have no license at all. drivers/usb/serial/keyspan_mpr_fw.h drivers/usb/serial/keyspan_usa18x_fw.h drivers/usb/serial/keyspan_usa19_fw.h drivers/usb/serial/keyspan_usa19qi_fw.h drivers/usb/serial/keyspan_usa19qw_fw.h drivers/usb/serial/keyspan_usa19w_fw.h drivers/usb/serial/keyspan_usa28_fw.h drivers/usb/serial/keyspan_usa28xa_fw.h drivers/usb/serial/keyspan_usa28xb_fw.h drivers/usb/serial/keyspan_usa28x_fw.h drivers/usb/serial/keyspan_usa49w_fw.h drivers/usb/serial/keyspan_usa49wlc_fw.h These are all under a unique and annoying license: redistributable as part of a Linux or other Open Source operating system kernel Additional regressions relative to sarge: * tg3 was readded with the upstream firmware at some point after the release of sarge, despite the existing firmware loading patches, and is already in the 2.6.17 packages * The bnx2 driver was introduced upstream with sourceless, but distributable, firmware. * e100 and starfire acquired sourceless, undistributable firmware upstream between the sarge release and now (God only knows why) * New drivers were introduced upstream between the sarge release and now with the following sourceless, undistributable firmware: - drivers/net/cassini.h - drivers/scsi/ql1040_fw.h You might want to have a closer look at some of those, I know the qla1040/qla1280 is already supported in 2.4 and always had firmware. (It also needs to download firmware for most devices.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mipsel install failure in gxemul-ated decstation
Michel Lespinasse wrote: Hi Martin, On Mon, Aug 28, 2006 at 05:10:06AM -0700, Michel Lespinasse wrote: Also just as a sanity check I did confirm today that the installation on decstation works fine if I use the sarge 31r2 image instead. So gxemul does seem to be useable enough if you have the right image. I figured out what that issue was. Turned out the kernel I was using actually had an embedded initrd in it with the sarge installer on it. So I thought I was running the etch installer that came with the CD image, but I was actually running the sarge installer from the initrd that had been embedded with my kernel, and that installer got confused when it actually mounted the etch CDROM and tried to start installing packages from there. In other words, it was all my fault. Now I'm trying to figure out how to convince gxemul to start a debian kernel with the debian initrd... I wonder why this is a problem, the DECstation installer images already contain the initrd. If gxemul is good enough at emulating a DECstation harddisk/cdrom you can boot from the mini.iso installer image. If the emulator supports netboot, then the boot.img should work. The separate kernel and initrd binaries are only needed to build bigger CD images. The delo package contains the 'delo' and 't-rex' commands to create bootable images. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mipsel install failure in gxemul-ated decstation
Michel Lespinasse wrote: [snip] What happens is that t-rex builds an ecoff image, I suppose this is what the firmware on a real decstation would boot. However gxemul does not have any firmware, it only knows how to load an ELF file and get it started. Well supposedly it should also be able to load a binary file such as the initrd image, but for some reason I've been unable to figure out the glue to make that work. So what I need is the debian kernel + initrd image in a single ELF file. Maybe you can convert the initrd into a cpio archive and append it at the kernel image. I heard this is supposed to work, I haven't tried it myself. The way to go apparently is to build a kernel with the mips config option CONFIG_EMBEDDED_RAMDISK so that the initrd image is embedded with the kernel image. I'll try that tomorrow and see what happens. Incidently this is also how I got confused as I did not know my kernel image had such an embedded initrd image (with the sarge installer... grumpf :) CONFIG_EMBEDDED_RAMDISK is obsolete and was removed a while ago from upstream kernels. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: mipsel install failure in gxemul-ated decstation
David Goodenough wrote: On Wednesday 30 August 2006 13:15, Thiemo Seufer wrote: Michel Lespinasse wrote: [snip] What happens is that t-rex builds an ecoff image, I suppose this is what the firmware on a real decstation would boot. However gxemul does not have any firmware, it only knows how to load an ELF file and get it started. Well supposedly it should also be able to load a binary file such as the initrd image, but for some reason I've been unable to figure out the glue to make that work. So what I need is the debian kernel + initrd image in a single ELF file. Maybe you can convert the initrd into a cpio archive and append it at the kernel image. I heard this is supposed to work, I haven't tried it myself. It works, BUT you must build this as part of the kernel build (in recent kernels only). If you try to append it later then, due to what I think is a bug in objcopy, it fails. I meant something like cat initramfs.cpio kernel.img. I fail to see where objdump comes into play there. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382983: d-i beta3 on SGI Indigo2 (IP22)
Julien BLACHE wrote: Thiemo Seufer [EMAIL PROTECTED] wrote: Hi, Note: the installation manual lacks the instructions needed to boot from the CD (boot -f scsi(X)cdrom(Y)partition(8)/r4k-ip22 in the PROM) This should work semi-automatically via the install system entry in the firmware menu. That's what I thought when I first tried it ... it failed to boot :) Well, it _should_ try to boot from scsi(X)cdrom(Y)partition(8)/sashARCS, which _should_ be provided in the CD's volume header as an alias to r4k-ip22. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382983: d-i beta3 on SGI Indigo2 (IP22)
Julien BLACHE wrote: [snip] Note: the installation manual lacks the instructions needed to boot from the CD (boot -f scsi(X)cdrom(Y)partition(8)/r4k-ip22 in the PROM) This should work semi-automatically via the install system entry in the firmware menu. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382983: d-i beta3 on SGI Indigo2 (IP22)
Julien BLACHE wrote: Christian Perrier [EMAIL PROTECTED] wrote: Indeed, the code in localechooser that decides to display one or another set of languages is pretty incomplete. It decides this based on assumptions about the display but these are probably incomplete: The console in this case should be a standard Linux console on framebuffer, but I guess that it's not /that/ standard after all. Maybe Thiemo can tell us more about that ? It is not at all a standard framebuffer. The hardware allows no direct memory access but provides userspace-driven DMA capability instead. The X server uses the userland DMA for a while now, but the kernel uses a special newport console which is rather inefficient. The console groks at least latin1, btw. Could it be that the console lacks UTF8 support ? That's possible, I don't know the newport code by heart. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382983: d-i beta3 on SGI Indigo2 (IP22)
Julien BLACHE wrote: Thiemo Seufer [EMAIL PROTECTED] wrote: Hi, Well, it _should_ try to boot from scsi(X)cdrom(Y)partition(8)/sashARCS, which _should_ be provided in the CD's volume header as an alias to r4k-ip22. From the PROM: ls scsi(0)cdrom(3)partition(8) scsi(0)cdrom(3)partition(8): r4k-ip22 From a running system: % sudo dvhtool -d /dev/sr0 --print-volume-directory - directory entries - Entry #0, name r4k-ip22, start 7480, bytes 9414656 % Which would indicate a problem with the CD build script, I guess ? Yes. IIRC it worked correctly for sarge. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382368: please enable sysrq keys
Martin Michlmayr wrote: * martin f krafft [EMAIL PROTECTED] [2006-08-10 16:06]: This is obviously to aid development but should not add to the kernel size or affect the user: please enable the use of the sysrq key during d-i. 2.6.17 has this enabled so this'll automatically be done once d-i switches to 2.6.17. Weren't there some local security issues, like allowing to kill a password-protected screensaver via magic sysrq? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: Upcoming Release of Debian GNU/Linux 4.0
Jason Self wrote: [snip] Please see http://lists.debian.org/debian-powerpc/2006/07/msg00188.html And, as Brian Durant pointed out, this isn't just about the iMac G5 but also the Power Mac G5 (PowerMac 9.1) as well. In fact, Debian chokes on most of Apple's newer PowerPC machines. I and many others had been looking to Etch as a solution, but it won't provide one with 2.6.17 and I'm not looking forward to the potential of waiting through the lifetime of another stable release before gaining support. It's important, IMHO, that 2.6.17 _not_ be selected as the default kernel but rather 2.6.18 (or later) for the reasons discussed on debian-powerpc... even if that means delaying the release of Etch. Backporting the necessary changes is certainly an option. I would think this is up to the powerpc Porters to handle. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#378984: fstab default /proc entry nosuid
maximilian attems wrote: Package: partman-target Version: 44 Severity: normal Tags: patch please apply belows patch, to add the /proc line to fstab with nosuid. rationale: setuid and setgid bits have nothing lost in /proc, nice workaround for kernel /proc vulnerability, see suggested at the lwn.net article: http://lwn.net/SubscriberLink/191954/dfb24a687f9b032e/ Index: finish.d/create_fstab_header === --- finish.d/create_fstab_header (revision 39223) +++ finish.d/create_fstab_header (working copy) @@ -9,4 +9,4 @@ printf %-15s %-15s %-7s %-15s %-7s %s\n '# file system' 'mount point' 'type' 'options' 'dump' 'pass' /target/etc/fstab -printf %-15s %-15s %-7s %-15s %-7s %s\n proc /proc proc defaults 0 0 /target/etc/fstab +printf %-15s %-15s %-7s %-15s %-7s %s\n proc /proc proc defaults,nosuid 0 0 /target/etc/fstab Might even become defaults,nodev,noexec,nosuid for that matter. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i on ancient hardware
Frans Pop wrote: On Sunday 09 July 2006 05:08, Adam Borowski wrote: 3. [G-I]: On lowmem, it would be better to flat-out refuse to run the graphical installer; a blank screen is an ugly way to die. The graphical installer already automatically falls back to text mode if there is not sufficient memory to run it. The problem you are seeing is that the kernel + initrd are too big to load into memory, so that process dies. This is not something that can be detected or avoided AFAIK. Well, the kernel (or the bootloader?) could check that and panic. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ATTENTION: d-i build machines need upgrae to glibc = 2.3.6-11
Geert Stappers wrote: On Tue, May 30, 2006 at 09:16:52PM -0400, Joey Hess wrote: [ upgrade to glibc = 2.3.6-11 ASAP ] (This issue might not affect a couple of architectures like ia64 and hppa that I think already had libc linked to libgcc before. Also, the new glibc hasn't autobuilt on a couple of arches (yet..)) Sparc is one of the 'not autobuilt yet' architectures. Will the next daily build fail due a dependency on libc6 = 2.3.6-11 ? How to monitor the availabillaty of the new libc6 ? The advice might be a bit over the top, 2.3.6-13 is supposed to fix that particular bug, which AFAICS means older images will work again once it is built and in the archive. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
Frans Pop wrote: [snip] IMO the question whether 2.4 should be removed now and if so for which architectures is something to be decided between the kernel team and porters. If a porter needs more time to switch to 2.6 for the installer, he should probably come up with a migration plan and timeline. Purely from a d-i release management point of view, it would be nice if the removal of 2.4 could be delayed until just after the next beta release. The release date for that depends on the progress of AMD64 archive migration (it is not yet installable from testing). Switching d-i reqires stable kernels for all subarchitectures, those are now mostly done for mips/mipsel. I hope we complete the move to 2.6 in 3-6 weeks. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman-reiser4
Domenico Andreoli wrote: hi Jack, On Mon, May 01, 2006 at 11:58:04PM -0700, [EMAIL PROTECTED] wrote: I'm interested in installing Debian on a reiser4 root partition Are you aware of any work on a partman-reiser4 udeb? no, sorry. debian linux kernel guys vetoed reiser4 in debian kernel long time ago. i don't even remember when it was, but Martin Michlmayr was already mentioning this on January 2005 [0]. probably this is the right time to ask them for an update on this story. to what is my current view of the reiser4 merge in the vanilla, i don't think it is around the corner. General Debian Kernel Team policy is to not include feature patches, unless they are already in the upstream kernel. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Preparing for update in stable
Andreas Barth wrote: * Frans Pop ([EMAIL PROTECTED]) [060429 12:36]: Or, a totally different idea: Why do we (technically) need to rebuild the installer at all? Could we try to avoid that need in future? The main reason (AIUI) we want to have a new installer with new kernel udebs is that the kernel udebs are directly derived from the kernel images, so if the kernel images disappear from stable, the kernel udebs derived from it should also disappear and be replaced with new kernel udebs derived from the current kernel images. Otherwise Debian would no longer be shipping the full source for the installer. well, if we would keep the old kernel images somewhere, we would still ship the full source. That might be a way to go? The second reason is security. Although the risk of an attack during installation is relatively small, it can't be completely excluded. Hm, AFAICS we have at maximum local root exploits - but who runs the installer is root anyways. So this shouldn't be an issue in this case? FWIW, I agree that source distribution has an (seemingly?) obvious solution, and I don't buy the security argument since it is less important than it was for boot-floppies, where the installer could be installed on the system. The most important reason for a installer kernel update is IMHO to keep the installer useful for modern hardware. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: note on 2.4 is deprecated
Manoj Srivastava wrote: On 13 Apr 2006, Bastian Blank wrote: On Thu, Apr 13, 2006 at 10:28:56AM -0500, Manoj Srivastava wrote: That is stretching it. The third component of a version is hardly a major revision. Why? Component in a version are major.minor.sub. Now, given that Linux 1.0 was ages ago, one could conced that the versioning is Epoch.Major.Minor Upstream declared 2.6 a constant for the time being, so the third component remains the only one to make a version distinction. But claiming that 2.5.16 is majorly different from 2.5.15 when it comews to support is a facile argument that most people are not gonna buy. We already saw that for 2.6.12 - .13. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Desktop task broken on !(i386/powerpc)
Petter Reinholdtsen wrote: [Christian Perrier] We're dealing here with a quite informal population of people wanting to easily install Debian and indeed we're probably having hard times in figuring out exactly what they might expect. Yes. And some of these do not want the congintive strain that options they do not understand will give them. All extra options and flexibility will scare some unskilled users away. I've seen untrained users stopp on the first screen on the woody installer (you know, the large text block explaining that all you need to do to continue is press [ENTER]), and sit down and read it for several minutes trying to understand what it said. For these, all extra options increase their confusion, and make them more insecure during the installation process. For this target audience, a desktop-only install without seeing tasksel seems to be the best option. For these, we should hide as much complexity and flexibility as possible. Which wouldn't work well for more experienced people. The usual answer for this problem is to provide different modes, like standard/user defined/special. Currently we don't, which means Bob User still sees some strange questions, while e.g. somebody who got a static IP address from his network administrator has to type in some strange kernel parameters. I still think it would be better to ask this mode question up-front instead of hiding it away, because it allows to make the rest of an standard installation even simpler as it currently is. We can't do that now because it would dumb down the installer too much for too many people. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge branch build dies with free blocks count == 0
Daniel Dickinson wrote: [snip] Well afir the only change between a build with this message and the build getting further, was adding the pic's so something screwy was going on. Personally I think my problems are a result of trying to use the buildscript before this. I know it's supposed to be fine, but it sounds like it's really not used much, FWIW, I wrote buildscript just as a helper for local d-i testing, and put it in SVN when it evolved enough to be useful for other d-i developers with different architectures. It was never intended to be useful for production builds of d-i. [snip] | You seem to have managed to install a udeb, libdebian-installer4-udeb, | as a deb, using dpkg, onto your debian system. This _will_ break the | build. Don't do that. Hmmm...that is either from buildscript, or because I was getting desperate, I can't recall which. I think I'm just going to have to bite the bullet and reinstall debian to get back to a coherent state. Blah for buildscript IMNSHO. buildscript doesn't install udebs, aside from copying them to localudebs. (At least it didn't the last time I used it.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Desktop task broken on !(i386/powerpc)
Joey Hess wrote: Christian Perrier wrote: Our now famous Bob User will for sure never use the method suggested by Joey for choosing tasks. I think you're being inconsistent in your definition of Bob user. Bob as been someone we don't bother with little details like disk partitioning, but he's expected to know how to choose between kde and gnome? Then he is also unlikely to figure out what the server tasks are good for, or WTF a Desktop is. I would expect somebody who has an idea about these to also be able to select one or both of [ ] Desktop (KDE style, you probably want GNOME as well) [ ] Desktop (GNOME style, you probably want KDE as well) Thiemo signature.asc Description: Digital signature
Re: Sarge branch build dies with free blocks count == 0
Daniel Dickinson wrote: [snip] | FWIW, I wrote buildscript just as a helper for local d-i testing, | and put it in SVN when it evolved enough to be useful for other | d-i developers with different architectures. It was never intended | to be useful for production builds of d-i. Ah, I believe Joey mentioned something along those lines. The unfortunate thing is that I didn't realize that before I started trying to use it. Perhaps a note in the scripts directory on in buildscript itself (I did look at it to figure out the command line), so as to prevent similar mistakes. I added a warning at the top of the script. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#287021: debian-installer: Full build (d-i+udebs) fails using checkout of RC2
severity 287021 wishlist thanks Daniel F. Dickinson wrote: Package: debian-installer Severity: serious Justification: 4 (Autobuilding) Rationale: rc2 is an official release candidate of the debian-installer, therefore checking out rc2 should successfully autobuild d-i rc2, including required udebs (since d-i without appropriate udebs is useless). This isn't the case. FWIW, I disagree. Only the separate udebs/packages have to be autobuildable. from d-i-rc2 ./scripts/buildscript This is only a convenience script for developers. It puts the generated udebs in installer/build/localudebs/, where they should _not_ go for a production build. The production build should fetch the udebs from an apt-gettable repository. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sarge and sarge in the manual
Colin Watson wrote: [snip] Better branding support would be nice in the manual in general; at the moment my Ubuntu diff is distressingly enormous due to the frequency with which Debian is mentioned by name without the use of an entity. The only appropriate entity right now is debian;, which expands to Debian GNU/Linux; I'm guessing that would get pretty unwieldy if used throughout the text. It might even be wrong for Hurd/*BSD/etc. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: specifiying a preseed url by dhcp
Joey Hess wrote: We could pick an option in the 128-254 range and use it, but we might be violating rfc2939 by doing so, since it requires that these MUST NOT be defined for use by any publicly distributed DHCP server, client or relay agent implementations. FWIW, FAI uses some of those options, e.g. option option-170 instserv:/usr/local/share/fai; # FAI_LOCATION option option-171 sysinfo;# FAI_ACTION option option-172 verbose createvt sshd; # FAI_FLAGS Thiemo signature.asc Description: Digital signature
Bug#283456: installation-reports
Christian Perrier wrote: tags 283456 moreinfo thanks Comments/Problems: Was it really that difficult to include kernel/driver/scsi/initio.ko ? :( Well, given the highest level of information you provide, I'm afraid noone can do anything. It seems that your hard disk wasn't detected but as we have no idea of the interface your system has, finding a solution may be quite hard. The 2.6 Debian kernel doesn't build initio.ko (I don't know why), so it isn't available in the installer. 2.4 builds the initio module. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#283050: IP22 MIPS Linux Install Failure
Martin Michlmayr wrote: * Philippe Vachon [EMAIL PROTECTED] [2004-11-26 00:02]: 1. The version of fdisk that comes with Debian Installer REALLY sucks... namely because I had to figure out on paper my partition table, rather We'll move to something else after sarge. 2. After installing the base system, and writing with ARCS to the PROM the values I was told to by d-i after the installation of the base system was complete, the system failed completely to boot -- it would load the ARCS kernel loader, which then proceeded to tell me it couldn't find the Kernel. This suggests some typo in the firmware variables. The following is needed: SystemPartition=scsi(0)disk(scsi-id)rdisk(0)partition(8) - Test: Typing ls in the firmware lists arcboot OSLoadPartition=scsi(0)disk(scsi-id)rdisk(0)partition(partition-number - 1) OSLoader=arcboot - Test: Typing boot in the firmware tries the boot _without_ showing an error message about unrecognized file system Caveat: ARCS partition numbering is zero-based, so ???partition(1) is /dev/sd?2 OSLoadFilename=Linux - Test: This should load the kernel. Caveat: The arcboot label is case-sensitive. E.g. linux as label will fail. Can you put a kernel on your TFTP server and then boot into the Debian system? Can you then investigate and see whether the kernel is really there. i.e. look into /boot and also take a look at /etc/arcboot.conf Booting the install image with: bootp(): append=single root=/dev/sd?? should work also. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Fabio Massimo Di Nitto wrote: [snip] | You can do this in ubuntu only because you have only 2-3 arches to | worry about, The model can be adapted. I am not pushing a patch to force our solution, but to give back the code that has been done and tested. It is up to the 2 teams to decide what to do with it. Clearly applying it to 11 arch is technically possible, it of course require more coordinations between people, and that is something nobody can give you with a patch ;) It also requires a mostly common upstream for all architectures. Historically, this assumption broke down, and was the reason to introduce separate kernel-source/kernel-tree .debs. Kernel 2.6 has improved the situation, but not enough to go back to a single source package. | and are thus not limited by the number of packages the packaging | tools can handle, right ? Nope.. the list of binaries that are generated per each arch is still relatively small. This suggests those udebs can't be cross-built easily. linux-kernel-di can (at least it is supposed to support this), which pushed the limit of the packaging tools. This in turn triggered the split in several linux-kernel-di-arch packages. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Andres Salomon wrote: [snip] b) Get archs autobuilt, so that they don't lag behind. They may not boot, but they'll at least compile. Given the way that kernel development upstream is happening, the development process will look something like this: 1) release k-s 2.6.10-1, upload i386 images, 2) autobuilders for all other archs attempt to build arch-specific images, 3) many fail; the kernel is therefore kept out of etch, 4) k-s 2.6.10-3 is uploaded (after -2 fixes some build failures as well), 5) autobuilders successfully build for all archs, 6) testers report bugs for archs that don't work; obviously, an arch-specific RC bug will keep a kernel out of etch, 7) after developers fix arch-specific bugs, k-s 2.6.10-4 is uploaded and autobuilt, 8) k-s 2.6.10, now that it builds and runs on all (used) archs, flows into etch. Of course, there's a good chance there may be some arch breakage on a rarely used arch, and the package gets into etch w/ the breakage; however, I'd rather see that than the arch sticking w/ a kernel version that's a year old, has known security holes, but boots. This Hooray, it compiles! approach is unlikly to ever produce an useful kenrel for architectures not maintained in mainline. 3) Simplify packaging. Dump the kernel-tree-X crap, etc. The cons of this are that one will no longer be allowed to build against an older, known-working k-s. Which means those architectures will still need a source package they can build-depend on, generated from the -image source. This is a minimal workload reduction for the kernel team but an increase for the security team. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: creating kernel udebs from kernel-source
Andres Salomon wrote: [snip] This Hooray, it compiles! approach is unlikly to ever produce an useful kenrel for architectures not maintained in mainline. I fail to see why not. How is it we can keep patches in arch-specific k-i packages, but keeping them in k-s won't work? As already mentioned on IRC, I misunderstood some parts of your mail an thought the idea was to abolish the kernel-source Package as well. You mentioned the fact that mips upstream is essentially a fork of Linus' tree; I suspect this is the case simply because they wait so long before resynchs, The situation improved significantly for 2.6, however, there's still need to mips-specific patches not in mainline. and when they do attempt to synch, they send large patches that Linus rejects. Rather: They send large patches and Linus accepts. :-) If we're going to be maintaining and dealing w/ these patches anyway, why not just feed split out changes to Linus? The easy ones are probably already sent, the hard ones have usually a reason why they shouldn't go upstream as is. The stuff in the middle needs some polishing like updates to more modern kernel interfaces. Of course, I don't oppose to send patches to kernel.org from k-s, but I think it is more efficient to do this between linux-mips.org and kernel.org. It makes everyone's life easier; for the next kernel revision, the patch has been merged; mips upstream has less of a diff between Linus' tree and theirs; and Linus and co. aren't being bombarded w/ 2 meg patches. 2 MB is the overall diff size, sending it as a single patch would clearly be insane. :-) As I mentioned above, that's just a goal to work towards. It may work, it may not. However, a bunch of k-i packages consist mostly of debian packaging and config files. There's no reason to have those as separate. For some architectures it clearly makes sense to drop those packages. I just want to keep them for architectures where they are more useful. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.4.27-6 source and i386 images available for testing
Horms wrote: On Sat, Nov 27, 2004 at 01:33:53AM +0100, Norbert Tretkowski wrote: * Horms wrote: If interested parties could take a look before I upload them I would be grateful. Build fails on alpha, patch attached. Thanks, though that fix doesn't seem very clean to me. Huh? I can't think of a less clean patch here. Do you have a build log handy? I'd like to take a closer look. The spinlock below just wants the usual flags variable. No magic at all. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280372: installs IP22 binary on IP32
Frans Pop wrote: On Tuesday 09 November 2004 00:34, Martin Michlmayr wrote: +# mount proc since arcboot needs it to decide between IP22 and IP32 +mount -t proc none /target/proc || true Wouldn't it be cleaner to test first if /target/proc was already mounted (with 'mount | grep -q on /target/proc')? This shouldn't happen, AFAICS. apt-install arcboot chroot /target /usr/sbin/arcboot $bootdev +umount /target/proc || true This way you will umount /target/proc even if it was mounted before this postinst was called. The final version of this patch assumes /target/proc to be unmounted, and does proper error checking if this assumption turn out to be wrong. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation and initrd (Re: arcboot and filesystems)
Martin Michlmayr wrote: * Joey Hess [EMAIL PROTECTED] [2004-10-13 21:08]: tbm: If either of the above have been done, or you feel only one is enough, feel free to close either or both bugs. I'm not sure how well arcboot-installer can check for root filesystem type since mips doesn't use partman. I don't think it has been documented yet. We can actually make this a more generic item: architectures should define whether they use initrd or not. Then we could add a paragraph to all non-initrd arches saying that your root/boot has to be ext2/3. Well, the filesystems offered by partconf on mips/*-ip22 are ext2 and ext3, which is what arcboot supports, so this problem affects (WRT mips) only the SWARM. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Documentation and initrd (Re: arcboot and filesystems)
Thiemo Seufer wrote: Martin Michlmayr wrote: * Joey Hess [EMAIL PROTECTED] [2004-10-13 21:08]: tbm: If either of the above have been done, or you feel only one is enough, feel free to close either or both bugs. I'm not sure how well arcboot-installer can check for root filesystem type since mips doesn't use partman. I don't think it has been documented yet. We can actually make this a more generic item: architectures should define whether they use initrd or not. Then we could add a paragraph to all non-initrd arches saying that your root/boot has to be ext2/3. Well, the filesystems offered by partconf on mips/*-ip22 are ext2 and ext3, which is what arcboot supports, so this problem affects (WRT mips) only the SWARM. Ah, but that's only true for lowmem installs, the normal installation does provide a choice for more filesystems. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: r23178 - in trunk/packages/rootskel: debian src/lib/debian-installer.d
Joey Hess wrote: Bastian Blank wrote: On Sun, Oct 17, 2004 at 12:28:56AM -0600, Kenshi Muto wrote: New Revision: 23178 Modified: trunk/packages/rootskel/debian/changelog trunk/packages/rootskel/src/lib/debian-installer.d/S40term-linux Log: Enable UTF-8 on serial console. (closes: #263137) This is nonsense, the escape-codes are linux only. This has a potential to block or break the initrd builds which I need to redo very soon to fix powerpc floppy sizes. Can we get a quick decision on whether to keep or drop this change please. At least the old real terminals are usually limited to latin1. Thiemo signature.asc Description: Digital signature
Re: __MIPSEL__ instead of __mipsel__
Martin Schulze wrote: FYI When writing code you want to have executed only on the Debian mipsel architecture, please make sure to use the __MIPSEL__ macro/define and not __mipsel__. The latter doesn't exist. There is __mips__ available as well, but it's the CPU architecture and is shared among big and little entian MIPS processors. You can try out the following on vaughan to find out which macros are pre-defined with GCC. Feel free to compare the output with the one you get on casals. ln -s /dev/null test.c gcc -E -dM test.c gcc -E -dM -xc /dev/null | less Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: __MIPSEL__ instead of __mipsel__
Petter Reinholdtsen wrote: [Martin Schulze] ln -s /dev/null test.c gcc -E -dM test.c or just 'echo | gcc -E -dM -' IIRC this doesn't work reliably for all gcc versions, because the guess about the compiler language for unknown file extensions changed over time. Luckily the language can be specified explicitly with -xlang. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why netboot CD needs to wget debian-installer?
Tapio Lehtonen wrote: I think installer wants files from remote mirror that are already in CD-drive. IIRC it tries to update to the latest version. I booted from pre-RC2 floppies, boot, root, and cd-drivers. Then installer found SCSI CD-drive and pre-RC2 netboot cd image there. Then I told it to use my own partial mirror, created with command debmirror /opt/mirror/debian --nosource --passive \ --host=ftp.fi.debian.org --dist=sarge --arch=i386 \ --section=main,contrib,non-free --progress and served with HTTP server. But installer fails to use it, claiming file not found. It probably fell in the trap of missing stable/testing/unstable symlinks on that mirror. Thiemo signature.asc Description: Digital signature
Bug#274649: Doesn't set up serial console
Wouter Verhelst wrote: Package: base-config Severity: important Hi, Base-config should set up a getty on a serial console if the install was done on a serial console. Prebaseconfig is supposed to do this. This is easy; make sure a line like T0:23:respawn:/sbin/getty -L ttyS0 9600 vt102 is added to /etc/inittab if we're working on a serial console. Such a line is already present as an example in /etc/inittab; it's just that it should be uncommented. The configured speed isn't actually important as the kernel takes care of that (just have to make sure it isn't faster than the actual terminal's speed); but without this line, a serial-console-only architecture (such as m68k VME, which is where this bit me) will install to a full booting system that cannot be used because there's no way to login. FWIW, the setup done by prebaseconfig.d/90prepare-base-config works fine on a serial console install on SGI ip22. Maybe it breaks there for 2.2 kernels. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kbd-chooser for DECstation machines
Martin Schulze wrote:
[snip]
We could simply declare no preferred keyboard for the mipsel
architecture (beware, there's __mips__ for both mips and mipsel, and
__MIPSEL__ for only mipsel). This would require the dialog to be
displayed, though, for the user to be able to select the keyboard
type. Since it is of medium priority and only high priority dialogs
are displayed, this may not be sufficient.
Changing this for DECstation machines should fixed with the attached patch.
Regards,
Joey
--
This is GNU/Linux Country. On a quiet night, you can hear Windows reboot.
Please always Cc to me when replying to me on the lists.
Content-Description: Change kbd default type on DECstation boxes
--- orig/kbd-chooser-1.02/dec-kbd.c 2004-04-01 23:42:22.0 +0200
+++ kbd-chooser-1.02/dec-kbd.c2004-09-30 21:26:04.0 +0200
@@ -28,5 +28,14 @@ kbd_t *dec_kbd_get (kbd_t *keyboards, co
k-next = keyboards;
keyboards = k;
+#if defined(__mipsel___)
Does this really work? __mipsel__ is not a predefined gcc macro, neither
with two nor with three trailing underscores (__MIPSEL__ would be).
+ // /proc must be mounted by this point
+ // assert (check_dir (/proc) == 1);
+
+ if (check_dir (/proc)) {
+ if ((grep (/proc/cpuinfo,DECstation ) == 0))
This doesn't match DECsystem and a host of other machines detected by
archdetect. It's probably better to (re-)use the archdetect values
like mipsel/r4k-kn04 instead. Archdetect is always available in the
d-i initrd.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PROPOSAL] 2.4.27 as default 2.4 kernel for sarge
Norbert Tretkowski wrote: [snip] I'm going to upload an updated kernel-image-2.4.26-alpha package next weekend, please make sure you're using this one, because it'll be build against kernel-source-2.4.26 2.4.26-6, which fixes some security issues. ... not kernel-image-2.4.27-alpha? There was no final decision if we ship 2.4.27 with sarge. If you now build and upload linux-kernel-di-alpha 0.62 with 2.4.27, you have to build 0.63 that downgrades linux-kernel-di-alpha back to 2.4.26 if we don't use 2.4.27 for sarge. 0.61 can't be used for sarge because it was built with kernel-source-2.4.26 2.4.26-2.1 which has some security problems which were fixed later. AFAICS it would be rather something like 0.61sarge1 for sarge, and it is then independent from the decision about 2.4.27. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: installing sarge on an alphastation
[EMAIL PROTECTED] wrote: hi, i'm on installing debian linux sarge on an alphastation 500/266. The installation itself works fine, but there is a problem regarding the c-compiler. Linking an object file previously compiled results in an error: /usr/bin/ld: unrecognized option --as-needed. This is a known gcc Bug (#264835), not an installer problem. You may want to read http://bugs.debian.org/264835 to find out about the current state of it. Thieom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i devcamp 22th to 26th of September in Oldenburg?
Goswin von Brederlow wrote: [snip] I'm intrested in going but I probably don't qualify for funding since I haven't done any work for ages. I'm just mentioning this for organizational purposes. - Anyone driving from Tuebingen or Stuttgart so we can share a ride? I plan to do so this year again. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i devcamp 22th to 26th of September in Oldenburg?
Frederik Dannemare wrote: [ snip ] That list should be a starting point for planning the trip. Andreas, you need to collect cost estimates from everyone interested in getting their travel covered, and use this to decide who will get their trip funded. [ snip ] Since I'm no DD and haven't done any directly work on the installer, I will absolutely not ask for any funding. I hope to make the event fit into my schedule, and with a little luck I can borrow my parents car, but what about hotels in that area? Does anybody know of any cheap ones that they can recommend? The Oldenburg meeting is organized a bit different to what you may expect. Recommended paraphernalia include a sleeping bag and a coffee mug. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#263205: mips-cdrom
[EMAIL PROTECTED] wrote: [snip] Comments/Problems: When selecting to install from cdrom it says and affirming to have inserted the cdrom I get the error message Installation tools not found. This is most likely a problem with the cdrom. Hm, Debian has no IRIX-style installation tools. What should happen: - the firmware variable OsLoadPartition is set to scsi(0)cdrom(X), with X being the CDROMs SCSI-id. (After that, available bootfiles can be listed with the ls command, those should be r4k-ip22 and r5k-ip22.) - The OsLoader variable points to one of those bootfiles. - The bootfile is executed and starts the installer. The problem is, the firmware expects a bootfile with the name sashARCS for an automatic startup of the installation. You can work around it by typing at the firmware prompt: setenv OsLoadPartition scsi(0)cdrom(X) setenv OsLoader r4k-ip22 boot Could you retry with this method? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#218728: Flexible size settings for autopartkit
Ralf Gesel|ensetter wrote: [snip] Why not define a well defined interface how to define a linear equation or the like on how to define each partition's size? Something like what I proposed at http://bugs.skolelinux.no/show_bug.cgi?id=774 Another way could be to have a minsize and a maxsize for each partition. In case the sum of minsizes increases the disc size, just reduce minsize by the percentage missing. Otherwise, give minsize to all parts, and interpolate between minsize and maxsize ( min + par * ( max - min) , par runs from 0 to 1) until space is used up. Spare space is defined in the same manner by means of a dummy partition that will not be created. I assure you that I will not apply for any patents for this idea :)) There's prior art anyway. :-) FAI has a perl script which follows roughly the same idea. Unfortunately debian-installer has no space left to accomodate a perl interpreter in the initial ramdisk, so the FAI script would need a port to shell or C, whatever the less insane choice is. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#262344: debian-installer: Please add gnutls11 and gcrypt11 packages
Matthias Urlichs wrote: Package: debian-installer Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [2004-07-29] Accepted gnutls11 1.0.16-4 (i386 source) This means that gnutls11 will enter testing in time for the freeze. The base dependencies were (supposed to be) frozen weeks ago. ** Please add libgnutls11 and libgcrypt11 ** ** to the list of packages installed by d-i. ** This list is determined by debootstrap (that is, debootstrap-udeb). Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lowmem problem on mips resurfaces
Nicholas Breen wrote: d-i's failing again on mips (Indy r4k) with 32 MB. Netbooting from a current svn build dies just after the base system components are downloaded, and the 20040729 sarge_d-i CD images start failing during network configuration as the VM begins to kill processes. I just commited a patch to increase the lowmem trigger to 33 MB. The relevant message on vt4 is kernel: __alloc_pages: 0-order allocation failed (gfp=0x1d2/0) I got (via serial console) a endless stream of Killed. messages. Installation with 64 MB still works, with maximum usage at about 34 MB before swap activation. (total available for use 61140 kB, used 30968, free 30172.) Installing sarge with a netboot-install daily image gave an overall usage of 36 MB, that is ~ 33 MB userspace RAM as counted by lowmem. The ip22 machine's RAM granularity is 16 MB (that is, 32 or 48 MB is available), so there's no risk of overflowing the chosen value. The last time I tried a lowmem install, with the 20040708 CD builds, it was successful with ~30 MB maximum usage. With lowmem active I got a similiar result. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Partman/partconf and S/390; is this a wishlist bug for partman?
Adam Thornton wrote: As near as I can tell, S/390 still uses partconf, and it and m68k are the only architectures to do so. mips (dvh/SGI) is the third one. Something I think we should think about--although not for the d-i or sarge releases, probably--is to get S/390 moved over to partman (if I understand correctly that partman's functionality is a superset of partconf's). Partman relies on libparted, which can only handle 512 byte blocks (this is hardcoded). You would have to add enough support for those funny s390 modes to it before a switch to partman can be made. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: patch for hw-detect.sh
Harald Dunkel wrote:
[snip]
@@ -251,13 +253,27 @@
# XXX: This isn't the best way to do this; we should autodetect.
# The order of these modules are important.
get_manual_hw_info() {
+ case $KERNEL_VERSION in
+ 2.4.*)
+ KERNEL_IS_24=yup
+ KERNEL_MICROVERSION=`echo $KERNEL_VERSION | cut -d. -f3`
This will fail for some architectures:
hattusa:~$ uname -r
2.4.26-sb1-swarm-bn
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: umount: /initrd/dev: Invalid argument
Martin Michlmayr wrote: When booting, I get: Freeing unused kernel memory: 6200k freed Setting up filesystem, please wait ... umount: /initrd: Invalid argument The last warning is harmless but might confuse newbies. The current SVN rootskel supresses the warning. [snip] As I see it, this unmount can safely be removed. Does anyone know why it's there? Bug #218602, I think. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: umount: /initrd/dev: Invalid argument
Martin Michlmayr wrote: * Thiemo Seufer [EMAIL PROTECTED] [2004-07-23 18:16]: The last warning is harmless but might confuse newbies. The current SVN rootskel supresses the warning. Does it? I don't see how. The line reads now: umount initrd 2/dev/null || true Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/fstab problem on S/390: which package? Userdevfs?
Adam Thornton wrote: The /etc/fstab written for S/390 assumes old-style, static /dev entries: /dev/dasda1, /dev/dasdb1, and so on. Unfortunately, the installed system does not have those device nodes, but instead has devfs: /dev/dasd/address/part1, etc. AFAICS the installed system shouldn't mount devfs. It also should have static /dev entries, managed by makedev. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: /etc/fstab problem on S/390: which package? Userdevfs?
Adam Thornton wrote: On Fri, 2004-07-23 at 12:23, Thiemo Seufer wrote: AFAICS the installed system shouldn't mount devfs. It also should have static /dev entries, managed by makedev. In that case where in the debian-installer build do I need to put the script to generate the static /dev entries that the parmfile and fstab require? The installer doesn't need to do anything special besides installing makedev, which is Priority: required. The entries in /target/dev should be created by the makedev postinst script. The fact that it *does* mount devfs is probably a bug in the kernel build parameters for S/390, but not a major one if we also have the static /dev entries. Are you sure this doesn't simply hide the static entries by mounting devfs over it? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: umount: /initrd/dev: Invalid argument
Martin Michlmayr wrote: * Thiemo Seufer [EMAIL PROTECTED] [2004-07-23 19:03]: The line reads now: umount initrd 2/dev/null || true Where's this from? The code I look at is in packages/rootskel/src/lib/debian-installer-startup.d/S01mount packages/rootskel/src/sbin/init Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: umount: /initrd/dev: Invalid argument
Martin Michlmayr wrote: * Thiemo Seufer [EMAIL PROTECTED] [2004-07-24 02:56]: The code I look at is in packages/rootskel/src/lib/debian-installer-startup.d/S01mount packages/rootskel/src/sbin/init Well, I still see the error with an image from today. Apparently we talk about two different instances of those umount messages. I've never seen the one you mean (but I haven't looked that hard for it). This one should be there since we stopped to mount devfs via kernel parameters. I think the umount call can be removed. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#260136: grub-installer: fails in postinst (missing get_serial_console)
Steinar H. Gunderson wrote: Package: grub-installer Severity: grave Justification: renders package unusable grub-installer fails to install, with the following message in syslog: Jul 18 20:45:52 main-menu[298]: (process:25772): /var/lib/dpkg/info/grub-installer.postinst: 7: get_serial_console: not found get_serial_console() is a function defined further down in the script, It should be defined before it is used. which appearently can't be run in a subshell in ash like line 7 tries to do: serial=$(get_serial_console) Doing touch /bin/get_serial_console ; chmod +x /bin/get_serial_console makes the package work. AFAICS this papers only over the problem, and fails for serial installs. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ./scripts/buildscript depends on bash
Rafael Ávila de Espíndola wrote: the buildscript uses pushd that isn't available in dash. Perhaps the first line should read #/bin/bash? Done, thanks for the notice. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: is /etc/debian_version trustworthy?
Konstantinos Margaritis wrote: (For those who don't follow the thread about preseeding X debconf values, I need a way to support both woody, sarge and future releases and I need a way to know the current release) Can I count on /etc/debian_version holding specific and well known values? No, it only tells you the release base-files thinks to belong to. Users can mix packages from all releases on their systems (modulo dependencies). (aside from the case a stupid user changes the contents of the file) If not, is there *any* other way to know the debian release version (aside from keeping huge package version maps)? You would have to track the version of the packages you are interested in. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255497: invalid ramdisk size for netboot on i386
Udo Rader wrote: Package: debian-installer Version: tc1 when doing a 2.6 network boot on one of our servers, the kernel loads fine until it tries to access the ramdisk. I then tons of errors like this: -CUT- attempt to access beyond end of device ram0: rw=0, want=16408, limit=16384 -CUT- That's weird, because the uncompressed initrd size is only about 8.5 MB. adding ramdisk_size=16384 on the boot line does not help either, the kernel then panics with Unable to mount root fs on unknown-block(58,4) Well, the error suggests you need _more_ than 16 MB for that specific ramdisk. The tc1 ramdisk however shouldn't need that much. Thiemo signature.asc Description: Digital signature
Re: request change of menu items
Frans Pop wrote: [snip] With the cd-drivers floppy, two other menu items are added: - - Choose language (10) - - Choose country or region (11) - - Detect and mount CD-ROM (14) - - Load drivers from a floppy (12) - - Select a keyboard layout (12) - - Load installer components from CD (14) - - Detect network hardware (15) I don't understand why main-menu puts 'Detect and mount CD-ROM' before 'Load drivers from a floppy' as it breaks the sort by menu-item. It should be in it's normal place just before 'Load installer components from CD'. I guess because you could load further drivers from floppy (e.g. additional firmware ?), but normally you don't need that. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255330: Install report: MVME162
wouter wrote: [snip] Some notes I wrote down as I was performing the installation: * Choosing Dutch as installer language will hang the installer at the point where a hostname has to be chosen (hence the E at network configuration, although it isn't the network configuration udeb at fault). The reason is probably some non-ASCII characters being sent to the console, which modifies terminal setup in ways it shouldn't. As a possible way to resolve this issue, I suggested on IRC to disable langchooser when we're working on a serial console. Both Christian Perrier and Martin Michlmayr seemed to welcome this suggestion. As a short term solution, yes. OTOH, vt102 and above support latin1, so fixing the real bug is generally preferable. * I got a mount: /dev/pts: no such file or directory or similar message before the initial appearance of the main menu. Not sure whether or not it's harmless, but it should be looked into. IIRC 2.2 kernels don't use it, but 2.4/2.6 do. [snip] * Most VME systems, including mine, only have a serial console to work with. As a result, I got these messages all through the base-config: INIT: id 2 respawning too fast: disabled for 5 minutes INIT: id 3 respawning too fast: disabled for 5 minutes Moreover, after base-config was completed (and the full /etc/inittab was installed), I didn't have *anything* anymore; the installed inittab assumes tty1 through tty6 are available. I had to ssh in and change the inittab to be able to log in at the console. Perhaps base-config should configure an inittab that has a getty on a serial port if we're configuring through a serial console. IIRC this is done by prebaseconfig, with help from kbd-config (it works for mips). * baseconfig-udeb didn't work. Rebooting the system and configuring it that way was required. * Configure timezone main-menu option in base-config didn't work. * Configure the keyboard shouldn't be there on a serial console. It should default to No Keyboard. [snip] In short, the support for serial consoles isn't well tested and should be improved a lot. At the moment, some udebs test whether we're working on a serial console and handle it appropriately, but it's all done inconsistently, and the physical test whether we're running on serial consoles is done a few times. Once in rootskel, once in kbd-config, and once in some bootloader-installers to find the correct parameters. We should have a serial-support udeb which runs before lowmem and checks the serial parameters as well. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255169: installation report: SGI Indigo2 (r4k IP22)
Julien BLACHE wrote: [snip] Comments/Problems: I didn't remember that I had to create the partitions from last to first, I'm pretty sure I didn't do that when I installed woody on the machine a year ago. Anyway, I eventually figured out and partitioned the disk. Had to create an SGI disklabel on it, as it comes from a PC. What do you mean with last to first? Disappointment : no XFS support :( The bootloader installation went fine, but, unfortunately, it doesn't handle a separate /boot partition, so the machine couldn't reboot. Well, the firmware has no problem with booting from arbitrary partitions, so a separate /boot makes little sense, and arcboot doesn't support it. This should be documented better. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255169: installation report: SGI Indigo2 (r4k IP22)
Julien BLACHE wrote: [snip] Disappointment : no XFS support :( The bootloader installation went fine, but, unfortunately, it doesn't handle a separate /boot partition, so the machine couldn't reboot. Well, the firmware has no problem with booting from arbitrary partitions, so a separate /boot makes little sense, and arcboot doesn't support it. This should be documented better. d-i should either workaround the problem (as I did), or it shouldn't offer to create a /boot partition that will lead to a non-booting machine :) Rather the latter, I think. /boot makes sense in my case, because I intend to use XFS on this machine, and I think arcboot doesn't handle XFS. If XFS is in a module, you still need a non-XFS /. Moreover I plan to do some tests on the machine, and should it crash, I'd like to keep /boot safe, so it can still boot and recover. Well, I'd suggest a backup + netboot in that case. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255169: installation report: SGI Indigo2 (r4k IP22)
Martin Michlmayr wrote: retitle 255169 needs finish script to check that there's no /boot reassign 255169 arcboot-installer thanks * Thiemo Seufer [EMAIL PROTECTED] [2004-06-19 12:50]: Well, the firmware has no problem with booting from arbitrary partitions, so a separate /boot makes little sense, and arcboot doesn't support it. This should be documented better. In this case, we should add a finish.d script which check that there's no separate /boot. Where? In partconf? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255169: installation report: SGI Indigo2 (r4k IP22)
Martin Michlmayr wrote: * Thiemo Seufer [EMAIL PROTECTED] [2004-06-19 12:50]: Well, the firmware has no problem with booting from arbitrary partitions, so a separate /boot makes little sense, and arcboot doesn't support it. This should be documented better. Does arcboot not support it, or arcboot-installer? AFAIK arcboot expects its config and the kernel to sit on the same partition. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#255169: installation report: SGI Indigo2 (r4k IP22)
Martin Michlmayr wrote: * Thiemo Seufer [EMAIL PROTECTED] [2004-06-19 15:49]: In this case, we should add a finish.d script which check that there's no separate /boot. JFTR, the delo bootloader on mipsel also won't work with separate boot. Where? In partconf? Oh fuck, true... what's the status of switching to partman anyway? Apart from the libparted fix, what needs to be done? Can we just tell people not to use logical partitions? The parted fix is still missing. I had a look if it's easily possible to disable logical partition support in partman for the SGI subarchitectures, but this seems to get messy. I didn't look into it further yet. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Out of sync udebs
Hello All, the following udebs are currently in testing, but out of sync between architectures, and should be resynced for the release candidate: archdetect alpha 0.100; other 0.101 bogl-bterm-udeb i386, powerpc 0.1.18-1; other 0.1.17-1 cdebootstrap-udeb arm, sparc 0.2.3; other 0.2.4 choose-mirror arm, sparc 0.0.44; other 0.0.45 debootstrap-udebarm, sparc 0.2.3; other 0.2.4 di-utils-bootfloppy alpha, arm, sparc 0.54; other 0.56 di-utils-mapdevfs alpha, arm, sparc 0.54; other 0.56 di-utils-shell alpha, arm, sparc 0.54; other 0.56 evms-udeb arm, sparc 2.3.1-1; other 2.3.1-2 fdisk-udeb m68k 0.7.1-5; mips 2.12-5; mipsel 2.12-4; s390 2.11n-4.1; sparc N/A; other 2.12-6 kbd-chooser s390 0.26; other 0.54 lvm2-udeb hppa, mips, mipsel 2.00.15-3; other 2.00.08-4 netcfg s390 0.22; other 0.63 netcfg-dhcp s390 0.22; other 0.63 netcfg-static s390 0.61; other 0.63 partconfs390 0.30; other 0.31 partconf-find-partitions s390 0.30; other 0.31 partconf-mkfstabs390 0.30; other 0.31 There are some more udebs in testing-proposed-updates, I completely ignored those. Of the ones above, some are probably obsolete or useless for some architectures and should be removed. The fdisk-udeb seems to be a special case for m68k (and sparc). My best guess is currently: - fdisk-udeb: Specialcase m68k, sparc. Sync the rest to 2.12-6. - kbd-chooser: Remove for s390, drop s390 from Architecture: if it is still there. - netcfg: Likewise. - netcfg-dhcp: Likewise. - Everything else: Sync with the newest version. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Ideas thrown around for Fully Automated Installations
Christian Perrier wrote: [snip] I started thinking about a very simple package (let's name it automate) which just: -runs very early -loads the floppy module -read a file from the floppy (FAT16 formatted) with simple debconf variables settings (and comments): [snip] -feed debconf with these values (small script to be written) -run the installer I have chosen floppy as support because we can guess (maybe wrongly) that this is the most common thing we have on machines and because it's probably not too much costly having the module on the initrd Automated installs tend to be networked, and with DHCP, AFAICS. So it's probably better to include a file in the initrd which is enough to get the network running, and then fetch a second one via network (via e.g. http). We probably don't even need to include a hardcoded file in the initrd if we can start the installer with a boot parameter automate=http://server/path/to/config; (For PXE, this boot parameter can be defined in the PXE config on the server side, in dependance of the client IP address. That's much simpler than config floppies for a few hundred machines. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udebs - testing
Martin Michlmayr wrote: I asked James to put the following udebs in testing (this will happen with today's dinstall): base-installer 0.084 colo-udeb (new) palo-installer 0.0.4 partman-jfs 2 partman-auto 23 ddetect 0.101 yaboot-installer 0.0.25 linux-kernel-di-mipsel 0.57 (have 2.4.25 _and_ 2.4.26) linux-kernel-di-alpha 0.60 (have 2.4.25 _and_ 2.4.26) I miss linux-kernel-di-mips here. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: symlinks in /boot vs. symlinks in /
Petter Reinholdtsen wrote: [Martin F Krafft] Why does Debian drop symlinks to vmlinuz and initrd.gz into the root directory? The FHS does allow it (after all), but it's butt-ugly, if you ask me. I do not care much about its uglyness, but it can also be a problem when using grub and having /boot/ on a separate partition. Of course update-grub solve that problem, but I agree with you that it would be better to keep the boot info in /boot/. OTOH, the linux kernel uses this scheme for a very log time now. Deviating from it will break make oldconfig dep install modules_install style upgrades from upstream sources. (I guess that's the reason why the FHS specifically allows this scheme.) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: symlinks in /boot vs. symlinks in /
martin f krafft wrote: also sprach Thiemo Seufer [EMAIL PROTECTED] [2004.06.18.2323 +0200]: OTOH, the linux kernel uses this scheme for a very log time now. Deviating from it will break make oldconfig dep install modules_install style upgrades from upstream sources. Uh, if I do 'make bzimage', then the kernel installs into /boot. This would be a major bug, make bzImage shouldn't install anything. The kernel used to go into /root back in the seventies and eighties, and it still does in other OSs like solaris. But it doesn't in Linux, really. Then you have a different Linux than the kernel.org one. I haven't seen it anywhere but in Debian. I remember Slackware and old SuSE, as well as IRIX and Ultrix. Thiemo signature.asc Description: Digital signature
Re: symlinks in /boot vs. symlinks in /
Joshua Kwan wrote:
On Fri, 18 Jun 2004 23:23:00 +0200, Thiemo Seufer wrote:
OTOH, the linux kernel uses this scheme for a very log time now.
Deviating from it will break make oldconfig dep install modules_install
style upgrades from upstream sources.
Wrong. make install is tuned to /boot/{vmlinuz,System.map}, or maybe it
prefers that, anyway.
Both 2.4 and 2.6 have in their Makefile:
#
# INSTALL_PATH specifies where to place the updated kernel and system map
# images. Uncomment if you want to place them anywhere other than root.
#
#export INSTALL_PATH=/boot
which his commented out by default.
Thiemo
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#254935: The way the swap size is calculated seems not correct
Margarita Manterola wrote: [snip] I think it would be nicer if the parameters for swap size could be taken from the memory size, the minimum being the memory size, and the maximum the double of the memory size... Or something like that. This might give weird results for a machine with plenty of RAM but small hard disk. Adding a maximum cutoff at about 3* memory size is probably better. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Big problem with 20040614 sid_d-i i386 netinst image
Bastian Blank wrote: On Tue, Jun 15, 2004 at 01:03:32PM -0400, Joey Hess wrote: It sounds like the new libd-i package resolver works for i386. That's a nice change. The next pending change will break cdrom installs, because debian-cd discards libdebconfclient-udeb and anna can't resolve the virtual dependency without adding extra tracking for that case. For now it just ignore the missing package, but this makes it unreliable to decide if a dependency is realy there. (e.g. partman always checks for the availability of the module) libdebconfclient-udeb is pre-installed in the initrd, so it shouldn't matter what debian-cd does. Thiemo signature.asc Description: Digital signature
Re: Trying to installing an old mac68k
Margarita Manterola wrote: [snip: Mac with 12 MB] It's an OOPS. I have the screenshot on a digital camera. These are the lines I copied from the screen: Data write fault at 0x00AFF000 in Super Data (pc=0x214FC) Bad Kernel BUSERR (...) Process Swapper (pid=1, stackpage=001bf000) (...) This basically says the kernel tried to write somwhere beyond the end of the physical RAM (I guess when expanding the initrd), which triggered the swapper process, which in turn fails because it can only map userspace memory pages. If it's worth, I can post the screenshot. Ok, now, is there a chance that debian-installer might work on this? :) I doubt it. The ramdisk would have to be substantially smaller in order to leave enough RAM for the userland processes. The minimum configuration which was reported to work so far was 16 MB, with removing much stuff in the ramdisk manually while the install was running. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#252930: Installation-Reports: Beta 4 as a VMware Guest
Joey Hess wrote: [snip] Looking at it again, the root cause seems to be that a root login shell does not get the sbin directories in the PATH. The PATH is /usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games. That seems broken to me, shouldn't root have those directories in its path when you log in as root? Anyway, probably a base-config bug, since base-config was recently changed to call sh -l. Apparently /root/.profile is supposed to set the PATH for root to include the sbin directories. I don't know why this isn't happening, but I have seen the same problem on fresh debian installs. I can't reproduce it after install. ~/.profile gets ignored, because $HOME is set to / instead of /root, so it uses only the definitions in /etc/profile. (This also leaves a .bash_history file in /.) Thiemo signature.asc Description: Digital signature
Bug#252930: Installation-Reports: Beta 4 as a VMware Guest
Joey Hess wrote: Thiemo Seufer wrote: ~/.profile gets ignored, because $HOME is set to / instead of /root, so it uses only the definitions in /etc/profile. (This also leaves a .bash_history file in /.) I thought that might be it too, but I cannot reproduce it in a sarge chroot with HOME unset. I think that bash looks at getpwent to find the home directory in this case. For a unset HOME it seems to do that, but we have HOME=/. I can reproduce the bug with that setting. Thiemo signature.asc Description: Digital signature
Re: initrd.list output from build process
Colin Watson wrote: [snip] @@ -572,8 +575,9 @@ # Create the images for dest/. Those are the targets called from config. # # Create a compressed image of the root filesystem by way of genext2fs. -$(INITRD): $(TEMP_INITRD) +$(INITRD): $(TEMP_INITRD) $(TEMP_INITRD_LIST) install -m 644 -D $ $@ + install -m 644 -D $(TEMP_INITRD_LIST) $(INITRD_LIST) ./update-manifest $@ $(MANIFEST-INITRD) You may want to add also ./update-manifest $(INITRD_LIST) $(MANIFEST-INITRD_LIST) $(TEMP_INITRD): $(STAMPS)tree-$(targetstring)-stamp @@ -600,6 +604,8 @@ esac gzip -v9f $(TEMP)/initrd +$(TEMP_INITRD_LIST): $(STAMPS)tree-$(targetstring)-stamp This should depend on $(TEMP_INITRD) for clarity. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: kernel oops decoder
Joey Hess wrote: [snip] Please tell me and the other lurkers here more how to decode kernel oopses in debian-installer. For what I see, is that the package ksymoops is needed at the target system. Well we use the stock debian i386 kernel, so you just get another system with that kernel and run ksymoops on the oops output there. ksymoops has even a -t flag to select the target architecture. You usually do ksymoops -t arch -m /path/to/system.map -v /path/to/vmlinux \ -o /path/to/modules-dir oopsfile oopsfile.decoded for cross-target oops dump decoding. Thiemo signature.asc Description: Digital signature
Re: initrd.list output from build process
Colin Watson wrote: [snip] ./update-manifest $@ $(MANIFEST-INITRD) You may want to add also ./update-manifest $(INITRD_LIST) $(MANIFEST-INITRD_LIST) I was hoping to avoid that, since I thought that would mean I'd have to set MANIFEST-INITRD_LIST in all the .cfg files. You don't have to, an unset MAINFEST-* is simply ignored. Maybe I can just set MANIFEST-INITRD_LIST = contents of initrd in config/common and leave it at that, though. Would be the best solution, I think. Any configuration which wants to give a more specific description can override it with its own value then. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: state of the test candidate
Joey Hess wrote: Thiemo Seufer wrote: - mips Installs on r4k-ip22 with 32 MB fails, it needs 36 MB until swap is available, lowmem assumes 25 MB With SVN as of a few days ago, it needs ~28 MB, I haven't figured out the reason (nearly all of it due to increased memory usage, which was only partially reflected in the ps output). With what from svn, exactly? With the initrd from SVN (as far as the packages are there), installing unstable. tc1 needs about 17 MB Memory before swap can be activated, normal are ~10. or we can make some more (but still very controlled and focused) changes to fix some of the other problems listed above too, which would mean starting over with a tc2. I prefer this option, as it allows to sync the 2.2/2.4 kernel versions to 2.2.25 and 2.4.26 (except apus, ia64, powerpc for 2.4, which have only 2.4.25), which is basically a requirement for release. That is the kind of thing that can easily expose problems, and take about a month to settle down. I used the 2.4.26 Kernel for several test installs, it is in unstable and testing for a while now, and I haven't heard of any problems which could be installer-related. The installer-visible change is that the swarm kernel has its socket module now built in. By which time there will be a new upstream kernel.. For a release, we _have_ to sync the kernel versions, otherwise the security team will collectively get nuts. If we want to settle with an older version than newest upstream for release, we have to make sure the new kernel won't propagate to testing. Thiemo signature.asc Description: Digital signature
Re: languagechooser_1.23_i386.changes ACCEPTED
Christian Perrier wrote: Quoting Christian Perrier ([EMAIL PROTECTED]): Unknown localized field: Description-C.UTF-8 Hmm, it seems that an incorrect languagelist file escaped from my system..:-( This C entry should have been removed, at least temporarily After checking, there is *no* C entry neither in the uploaded package nor in SVN trunk. Was this with the 1.23 version of languagechooser? This was from SVN, so it calls itself 1.24, but it's the same as the released version besides of that. 1.22 works for me. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: languagechooser_1.23_i386.changes ACCEPTED
Christian Perrier wrote: [snip] OKgot it, quite certainly. We need changing ther lowmem package with the following (untested): 9c9 db_set languagechooser/language-name English (USA) --- db_set languagechooser/language-name English 10a11,16 db_set countrychooser/country US db_set debian-installer/locale en_US It works with this change, thanks. :-) Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#253099: killall.sh: Can kill wrong PID
Thomas Hood wrote: [snip] pids=$(ps ax | grep 'udhcpc\|dhclient\|pump' | sed 's/^[ ]*\([0-9]*\).*/\1/') However, (1) this picks up the PID of the grep process itself: $ ps ax | grep 'udhcpc\|dhclient\|pump' 15769 pts/2S+ 0:00 grep udhcpc\|dhclient\|pump (2) I don't see where udhcpc is started. In dhcp.c only dhclient3, dhclient and pump seem to be supported. This may need dhclient3 in the pattern, and a grep -v grep. (3) ps has built in output formatting so sed isn't really needed. Better would be: for CLIENT in dhclient3 dhclient pump ; do pids=$(ps --no-headers -o pid -C $CLIENT) Are you sure busybox ps behaves that way? Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#253099: killall.sh: Can kill wrong PID
Thomas Hood wrote: On Mon, 2004-06-07 at 15:30, Joey Hess wrote: busybox ps does not support any of the options you used, as far as I can tell. This is the d-i initrd. We don't have start-stop-daemon. I think that running the code and playing with it on the actual d-i system may have better results than mere inspection. (The d-i system doesn't have sleep either, FWIW.) I can see that my ignorance of d-i is on display here. :/ So ignore my suggestions for improvement. I guess the original code should be tweaked so that the PID of the grep process is excluded, as Thiemo Seufer suggested. The following line works in busybox, and matches also the blank in front of the process name to make mismatches less likely. ps |grep ' udhcpc\| dhclient\| pump' |grep -v grep |sed 's/[ ]*\([0-9]*\).*/\1/' Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: languagechooser_1.23_i386.changes ACCEPTED
Debian Installer wrote: Accepted: languagechooser_1.23.dsc to pool/main/l/languagechooser/languagechooser_1.23.dsc languagechooser_1.23.tar.gz to pool/main/l/languagechooser/languagechooser_1.23.tar.gz languagechooser_1.23_all.udeb to pool/main/l/languagechooser/languagechooser_1.23_all.udeb Announcing to [EMAIL PROTECTED] Setting bugs to severity fixed: 250376 This fails now at least on mips in lowmem mode with an endless loop telling: Unknown localized field: Description-C.UTF-8 Unknown localized field: Description-C.UTF-8 Unknown localized field: Description-C.UTF-8 Unknown localized field: Description-C.UTF-8 Unknown localized field: Description-C.UTF-8 ... Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: state of the test candidate
Joey Hess wrote: [snip] - mips Installs on r4k-ip22 with 32 MB fails, it needs 36 MB until swap is available, lowmem assumes 25 MB With SVN as of a few days ago, it needs ~28 MB, I haven't figured out the reason (nearly all of it due to increased memory usage, which was only partially reflected in the ps output). [snip] or we can make some more (but still very controlled and focused) changes to fix some of the other problems listed above too, which would mean starting over with a tc2. I prefer this option, as it allows to sync the 2.2/2.4 kernel versions to 2.2.25 and 2.4.26 (except apus, ia64, powerpc for 2.4, which have only 2.4.25), which is basically a requirement for release. Thiemo signature.asc Description: Digital signature
Bug#253069: debian-installer TC1 successful installation on Apple Powerbook G4
James Troup wrote: [snip] I only have very minor comments: (o) I hope the auto-partitioning logic varies between platforms because 10Mb is far too small for /boot on hppa[1] at least and possibly others? partman-auto handles this via (sub-)arch-specific recipes. (o) yaboot asked me what partition to use. It'd be nice if it could have been told that by the auto-partitioning stuff? (o) Wah, someone reversed order of username/user question in base-config. FWIW, I found this irritating as well. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
