Re: Dropping the amd64-generic flavour
* Frederik Schueler: -generic is odd and too long. I am considering to change the naming scheme completely, and call the flavours 2.6.x-y-amd64 and 2.6.x-y-em64t respectively. Newer GCCs produce AMD64 code which is supposed to be closed to optimal to what GCC can produce on EM64T. Does it still make sense to distinguish between them? Or has it got something to do with the way the kernel sets up its data structures? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Boot failure with kernel 2.6.15 on G4
This message is generally a sign that something else went wrong. Magnus, the best way on this would be to file a bug report against initramfs-tools about this second problem, and if possible provide the whole log. Benjamin, BTW, there seems to be some issue about pmac_zilog and the normal serial controller, that if both are builtin the kernel, then the PC serial controller will take priority over pmac_zilog, and this second one will not work. Any hint on how to workaround that ? None currently. It's an old issue. The new serial core cannot deal with 2 drivers wanting to share the same major device. The only solution would be to allocate a new major for pmac_zilog (or steal one that is only used by a non-ppc arch, doesn't sparc has a separate major for zilog ? we could re-use that ) Ben. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375077: initrd needs its own, static, nsswitch.conf
reassign udev stop initramfs build by update-initramfs don't include an /etc/nsswitch.conf INIT: version 2.86 booting Starting the hotplug events dispatcher: udevd udevd[374]: nss_ldap: could not connect to any LDAP server as (null) - Can't contact LDAP server also once INIT is called we have finished our job, this is no longer early userspace, but usual init startups. so passing this hot potato to udev. i've already seen reports about this big trouble - http://www.jimmy.co.at/weblog/?p=70 regards -- maks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: reassign 375077 to udev
Processing commands for [EMAIL PROTECTED]: reassign 375077 udev Bug#375077: udevd: nss_ldap: failed to bind to LDAP server - boot fails Bug reassigned from package `initramfs-tools' to `udev'. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 364301
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.20 tags 364301 pending Bug#364301: initramfs-tools: Please show what is being done on upgrades There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 374378
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.20 tags 374378 pending Bug#374378: initramfs-tools: Fails to initialize LVM if pvmove was ran without completing There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375194: linux-image-2.6.17-1-powerpc: Unable to boot on G3 (Gossamer)
Package: linux-image-2.6.17-1-powerpc Version: 2.6.17-1 Severity: important I have troubles with booting the new kernel. The last messages are: pmac_zilog: Error registering serial device, disabling pmac_zilog. pmac_zilog: Did another serial driver already claim the minors? fd0: SWIM3 floppy controller And it stays so forever. I'm using BootX v1.2.2 with ramdisk size 8192 (increasing it doesn't help). I have issues with the older kernels as well, that's why I'm stuck with 2.6.8. Is there anything I could do in order to help you tracing this problem? -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: powerpc (ppc) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.8-powerpc Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Versions of packages linux-image-2.6.17-1-powerpc depends on: ii initramfs-tools [linux-initra 0.64 tools for generating an initramfs ii mkvmlinuz 22 create a kernel to boot a PowerPC ii module-init-tools 3.2.2-3tools for managing Linux kernel mo linux-image-2.6.17-1-powerpc recommends no packages. -- debconf information: linux-image-2.6.17-1-powerpc/postinst/kimage-is-a-directory: linux-image-2.6.17-1-powerpc/preinst/elilo-initrd-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/preinst/overwriting-modules-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/postinst/depmod-error-initrd-2.6.17-1-powerpc: false linux-image-2.6.17-1-powerpc/preinst/failed-to-move-modules-2.6.17-1-powerpc: linux-image-2.6.17-1-powerpc/postinst/old-system-map-link-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/postinst/depmod-error-2.6.17-1-powerpc: false linux-image-2.6.17-1-powerpc/postinst/bootloader-test-error-2.6.17-1-powerpc: linux-image-2.6.17-1-powerpc/prerm/would-invalidate-boot-loader-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/preinst/lilo-initrd-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/postinst/create-kimage-link-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/preinst/abort-overwrite-2.6.17-1-powerpc: linux-image-2.6.17-1-powerpc/postinst/old-dir-initrd-link-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/preinst/already-running-this-2.6.17-1-powerpc: linux-image-2.6.17-1-powerpc/postinst/old-initrd-link-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/preinst/abort-install-2.6.17-1-powerpc: linux-image-2.6.17-1-powerpc/prerm/removing-running-kernel-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/preinst/bootloader-initrd-2.6.17-1-powerpc: true linux-image-2.6.17-1-powerpc/preinst/initrd-2.6.17-1-powerpc: linux-image-2.6.17-1-powerpc/preinst/lilo-has-ramdisk: linux-image-2.6.17-1-powerpc/postinst/bootloader-error-2.6.17-1-powerpc: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#375194: linux-image-2.6.17-1-powerpc: Unable to boot on G3 (Gossamer)
On Saturday 24 June 2006 12:53, Yavor Doganov wrote: pmac_zilog: Error registering serial device, disabling pmac_zilog. pmac_zilog: Did another serial driver already claim the minors? fd0: SWIM3 floppy controller From other messages to the d-kernel list today: Sven Luther: Benjamin, BTW, there seems to be some issue about pmac_zilog and the normal serial controller, that if both are builtin the kernel, then the PC serial controller will take priority over pmac_zilog, and this second one will not work. Benjamin Herrenschmidt: None currently. It's an old issue. The new serial core cannot deal with 2 drivers wanting to share the same major device. The only solution would be to allocate a new major for pmac_zilog (or steal one that is only used by a non-ppc arch, doesn't sparc has a separate major for zilog ? we could re-use that ) pgpoJhNzUuzWB.pgp Description: PGP signature
Re: Boot failure with kernel 2.6.15 on G4
On Sat, Jun 24, 2006 at 04:33:59PM +1000, Benjamin Herrenschmidt wrote: This message is generally a sign that something else went wrong. Magnus, the best way on this would be to file a bug report against initramfs-tools about this second problem, and if possible provide the whole log. Benjamin, BTW, there seems to be some issue about pmac_zilog and the normal serial controller, that if both are builtin the kernel, then the PC serial controller will take priority over pmac_zilog, and this second one will not work. Any hint on how to workaround that ? None currently. It's an old issue. The new serial core cannot deal with 2 drivers wanting to share the same major device. The only solution would be to allocate a new major for pmac_zilog (or steal one that is only used by a non-ppc arch, doesn't sparc has a separate major for zilog ? we could re-use that ) Getting the pc-serial driver to not-load on apple hardware as we used to do doesn't help here, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
sparc compiler update
Hi folks I requested the rejection of the sparc build of linux-2.6 2.6.17-1 to allow sparc to raise the compiler to gcc-4.1 without abi bump. Jurij, please do that. Bastian -- You! What PLANET is this! -- McCoy, The City on the Edge of Forever, stardate 3134.0 signature.asc Description: Digital signature
Solution for module problem
Hi folks I got another request to at least partially fix the modules mess. D-I needs at least one of them for there kernel builds. The current situation should be clear. - It needs manual uploads for each source which builds binary modules. As the maintainer is not the kernel team, this may need some time. - Clutters the archive with many packages. Sven Luther proposed to integrate this packages into the kernel team but don't propose a fix for the other problems. So I propose another solution which will fix both the problems. - One source package (linux-modules-extra-2.6). - Produces currently _one_ binary package per kernel flavour. Advantages: - This solution replaces human intervention to upload a lot of packages with time on the buildds, which can be considered as cheaper. - Much less binary packages needed. - It can scale to a scheme where we want to maintain more than one version before release. Disadvantages: - It needs more communication between the maintainers of the source packages and the kernel team. An error in one of them will make the build of the whole package fail. I got support for that solution from two maintainers of such modules, Max Vozeler (loop-aes-modules) and Kilian Krause in favour of the pkg-voip team (zaptel-modules). A defined the following requirements for inclusion in this package: - They need to provide proper Makefiles (make -C /lib/modules/$(uname -r)/build M=$(pwd) have to work). - Responsive maintainers. - License GPL or compatible. - In main. I asked Max to compile a list of possible modules for this package according to this premises. You can see the current state here[1]. Bastian [1] http://nusquama.org/~max/debian/modules/ -- Our missions are peaceful -- not for conquest. When we do battle, it is only because we have no choice. -- Kirk, The Squire of Gothos, stardate 2124.5 signature.asc Description: Digital signature
Re: Dropping the amd64-generic flavour
On Sat, Jun 24, 2006 at 08:20:56AM +0200, Florian Weimer wrote: * Frederik Schueler: -generic is odd and too long. I am considering to change the naming scheme completely, and call the flavours 2.6.x-y-amd64 and 2.6.x-y-em64t respectively. Newer GCCs produce AMD64 code which is supposed to be closed to optimal to what GCC can produce on EM64T. Does it still make sense to distinguish between them? Or has it got something to do with the way the kernel sets up its data structures? The officially recommended way to build a distro kernel is to build the generic one. It's as fast as the specific ones because it uses some binary patching during bootup. The only thing you save with the specific options is a tiny little bit of space. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ---end quoted text--- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solution for module problem
On Saturday 24 June 2006 19:53, Bastian Blank wrote: Disadvantages: Another potential disadvantage could be that one binary forces all users that need/want only one (related set) of those modules to install all of them. I guess that how much of a problem this is depends on what modules will be included in the binary and to what extend they will be autoloaded (by udev for example). pgpUeDFpP1Jbw.pgp Description: PGP signature
Processed: retitle 333543 to linux-image-2.6.13-1-686: Unresolved symbols related to uhci_hcd
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.8.14 retitle 333543 linux-image-2.6.13-1-686: Unresolved symbols related to uhci_hcd Bug#333543: linux-image-1.6.13-1-686: Unresolved symbols related to uhci_hcd Changed Bug title. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solution for module problem
On Sat, Jun 24, 2006 at 07:53:44PM +0200, Bastian Blank wrote: Hi folks I got another request to at least partially fix the modules mess. D-I needs at least one of them for there kernel builds. The current situation should be clear. - It needs manual uploads for each source which builds binary modules. As the maintainer is not the kernel team, this may need some time. - Clutters the archive with many packages. Sven Luther proposed to integrate this packages into the kernel team but don't propose a fix for the other problems. Well, i would have voted for one package per module, but hey, let's get moving on this. So I propose another solution which will fix both the problems. - One source package (linux-modules-extra-2.6). - Produces currently _one_ binary package per kernel flavour. I propose that we add this package in the svn repo, and start adding those modules whose maintainers are interested, and when we have a core, we announce that this will be the only supported modules in etch. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solution for module problem
On Sat, Jun 24, 2006 at 08:21:53PM +0200, Frans Pop wrote: On Saturday 24 June 2006 19:53, Bastian Blank wrote: Disadvantages: Another potential disadvantage could be that one binary forces all users that need/want only one (related set) of those modules to install all of them. I guess that how much of a problem this is depends on what modules will be included in the binary and to what extend they will be autoloaded (by udev for example). This could be solved by providing separate binary packages in the future, but for now it is not really needed. It is better to go forward, than to discuss the best solution and not do anything in the end. For your information, i also favour the generation of one binary module .deb (and .udeb if needed) per module. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solution for module problem
* Frans Pop [Sat, 24 Jun 2006 20:21:53 +0200]: On Saturday 24 June 2006 19:53, Bastian Blank wrote: Disadvantages: Another potential disadvantage could be that one binary forces all users that need/want only one (related set) of those modules to install all of them. I guess that how much of a problem this is depends on what modules will be included in the binary and to what extend they will be autoloaded (by udev for example). What about a binary package for each module source (e.g., loop-aes-modules), which would contain the .ko files for each image flavour? I know it feels unnatural at first, but it would still reduce the number of packages, does not cause the behavior pointed out by Frans, and will be less space-whore in users' system. Think of it as similar to `dpkg -L libssl0.9.8 | grep libcrypto` (four copies of the library are provided on i386). Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Joaquín Sabina - Benditos malditos (al pil al pil) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solution for module problem
On Sat, Jun 24, 2006 at 08:21:53PM +0200, Frans Pop wrote:
On Saturday 24 June 2006 19:53, Bastian Blank wrote:
Disadvantages:
Another potential disadvantage could be that one binary forces all users
that need/want only one (related set) of those modules to install all of
them.
Another related issue just occured to me: Many of those modules
have dependencies on supporting user-space tools. Can / do we want
to have linux-modules-extra-$KVERS depend on them all?
cheers,
Max
--
drbdDepends: drbd8-utils
linux-wlan-ng Depends: linux-wlan-ng (= ${lwnvers})
loop-aesDepends: loop-aes-utils (= 2.12p-1)
ndiswrapper Depends: ndiswrapper-utils-1.8
pwc Depends: module-init-tools
zaptel Depends: zaptel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solution for module problem
On Saturday 24 June 2006 20:36, Sven Luther wrote: For your information, i also favour the generation of one binary module .deb (and .udeb if needed) per module. Hmm. Going that far was not actually what I had in mind. Some kind of logical grouping could be a future option though. pgpNGpBEtvlcr.pgp Description: PGP signature
Re: Solution for module problem
On Sat, Jun 24, 2006 at 08:21:53PM +0200, Frans Pop wrote: On Saturday 24 June 2006 19:53, Bastian Blank wrote: Disadvantages: Another potential disadvantage could be that one binary forces all users that need/want only one (related set) of those modules to install all of them. Yes. And without building one package per module, this is not possible at all. I guess that how much of a problem this is depends on what modules will be included in the binary and to what extend they will be autoloaded (by udev for example). The most of them should provide proper device tables. Also the current list includes some mutual exclusive sets of modules. So it needs to build more than one binary package. Bastian -- Another dream that failed. There's nothing sadder. -- Kirk, This side of Paradise, stardate 3417.3 signature.asc Description: Digital signature
Re: Solution for module problem
On Sat, Jun 24, 2006 at 08:42:40PM +0200, Max Vozeler wrote: Another related issue just occured to me: Many of those modules have dependencies on supporting user-space tools. Can / do we want to have linux-modules-extra-$KVERS depend on them all? Many of the modules builtin the kernel have such dependencies as wel.. Bastian -- There's coffee in that nebula! -- Capt. Kathryn Janeway, Star Trek: Voyager, The Cloud signature.asc Description: Digital signature
Re: Solution for module problem
On Sat, Jun 24, 2006 at 07:53:44PM +0200, Bastian Blank wrote: - Produces currently _one_ binary package per kernel flavour. Okay, only one package is too problematic. As far these other posibilities which give different output to now have been shown: - Only one package per module like loop-aes-2.6.17-1 which contains the modules for each flavour. This will clutter /lib/modules a little bit more and I already see the bugreports raising. - Functional groups. The problem is, I currently see only one group: Block devices and filesystems. Bastian -- The man on tops walks a lonely street; the chain of command is often a noose. signature.asc Description: Digital signature
Re: Solution for module problem
On Sat, Jun 24, 2006 at 10:09:59PM +0200, Bastian Blank wrote: As far these other posibilities which give different output to now have been shown: - Only one package per module like loop-aes-2.6.17-1 which contains the modules for each flavour. This will clutter /lib/modules a little bit more and I already see the bugreports raising. - Functional groups. The problem is, I currently see only one group: Block devices and filesystems. Maybe add a hardware support category? A third possibility: - One package per module and flavour (as it is now). This means the number of binary packages will not decrease, but all binary packages can be updated and processed in NEW in one go (per arch). Not sure if this makes work any easier for ftpmasters. I understand this is what Sven proposed, too. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Solution for module problem
On Sat, Jun 24, 2006 at 10:41:57PM +0200, Max Vozeler wrote: Maybe add a hardware support category? This produces the problem described by fjp. A third possibility: - One package per module and flavour (as it is now). This means the number of binary packages will not decrease, but all binary packages can be updated and processed in NEW in one go (per arch). Not sure if this makes work any easier for ftpmasters. Yes, it will make it easier. Bastian -- You canna change the laws of physics, Captain; I've got to have thirty minutes! signature.asc Description: Digital signature
Bug#375283: linux-2.6.16: descriptions for linux-modules packages missing important information
Package: linux-2.6.16 Version: 2.6.16-15 Severity: normal Descriptions for binary packages linux-modules-2.6.16-2-xen-686, linux-modules-2.6.16-2-xen-k7 and linux-modules-2.6.16-2-xen-vserver-686 are missing important information. There is obviously something wrong since linux-modules-2.6.16-2-xen-vserver-686 and linux-modules-2.6.16-2-xen-686 have identical descriptions. Also, I don't have a clue about the rationale for these packages, but in general, the descriptions do not give a clue what is the difference between the modules included in, for example, linux-modules-2.6.16-2-xen-686, and those in, in this example, linux-image-2.6.16-2-686. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
initramfs-tools_0.65_i386.changes ACCEPTED
Accepted: initramfs-tools_0.65.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.65.dsc initramfs-tools_0.65.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.65.tar.gz initramfs-tools_0.65_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.65_all.deb Announcing to debian-devel-changes@lists.debian.org Closing bugs: 364301 369617 374378 374891 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#374378: marked as done (initramfs-tools: Fails to initialize LVM if pvmove was ran without completing)
Your message dated Sat, 24 Jun 2006 16:02:16 -0700 with message-id [EMAIL PROTECTED] and subject line Bug#374378: fixed in initramfs-tools 0.65 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: initramfs-tools Version: 0.60 Severity: critical Justification: breaks the whole system If pvmove was ran on the system and did not complete (eg due to a crash, power failure, etc), LVM2 requires the mirror dm target to activate the VG By default the initrd only contains dm-mod and dm-snapshot kernel modules. Thus making a system with root on LVM unbootable under the above condition. This problem should whould probably be fixed by adding dm-mirror module to the default initrd configuration, and making the scripts load it before initializing LVM. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-k7 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages initramfs-tools depends on: ii busybox 1:1.1.3-1 Tiny utilities for small and embed ii cpio 2.6-13 GNU cpio -- a program to manage ar ii klibc-utils 1.3.35-1 small statically-linked utilities ii module-init-tools 3.2.2-3tools for managing Linux kernel mo ii udev 0.093-1/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information ---End Message--- ---BeginMessage--- Source: initramfs-tools Source-Version: 0.65 We believe that the bug you reported is fixed in the latest version of initramfs-tools, which is due to be installed in the Debian FTP archive: initramfs-tools_0.65.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.65.dsc initramfs-tools_0.65.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.65.tar.gz initramfs-tools_0.65_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.65_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. maximilian attems [EMAIL PROTECTED] (supplier of updated initramfs-tools package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 24 Jun 2006 13:27:49 +0200 Source: initramfs-tools Binary: initramfs-tools Architecture: source all Version: 0.65 Distribution: unstable Urgency: low Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: maximilian attems [EMAIL PROTECTED] Description: initramfs-tools - tools for generating an initramfs Closes: 364301 369617 374378 374891 Changes: initramfs-tools (0.65) unstable; urgency=low . * scripts/local-top/lvm: Activate root and resume volume group. The initialization got refractored in an function. (closes: #374891) Thanks for the patch to David Härdeman [EMAIL PROTECTED]. . * scripts/local-top/lvm: Be careful to activate volume group on lilo boot too. Although in that case we don't know the precise volume group, we activate them all. Matches behaviour of previous hook. . * hooks/lvm: Add dm-mirror, allows to boot from an unfinished pvmove. (closes: #374378) . * mkinitramfs: Remove old kernel-package supported long param. kernel-package uses since 10.036 mkinitramfs-kpkg. . * update-initramfs: Show by default which initramfs gets generated. (closes: #364301) . * Resync with 0.40ubuntu32: - Make prereqs conditional on the script/hook actually existing. From now on, this means that 'PREREQ=udev' means run udev first, iff it happens to be installed. Having the files exist on the filesystem if you have a HARD dependency should be enforced with package dependencies. (closes: #369617) - Make update-initramfs -u try to find the running kernel *after* it attempts to search the symbolic link list and its own sha1 list. Using this as a fallback, rather than the default, should solve most upgrade issues, where people found their initramfs was
Bug#369617: marked as done (failure to resolve prereq results in erroneous cyclic dependency warning)
Your message dated Sat, 24 Jun 2006 16:02:16 -0700 with message-id [EMAIL PROTECTED] and subject line Bug#369617: fixed in initramfs-tools 0.65 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: initramfs-tools Version: 0.60 Severity: minor local-top/lvm depends on md. I am renaming the script to mdadm, but I forgot to change that file. As a result, the boot crashes and warns me of a cyclic dependency when in fact, it just cannot run the lvm dependency. Maybe the error message could be adapted? Cheers, -- System Information: Debian Release: testing/unstable APT prefers stable APT policy: (700, 'stable'), (600, 'testing'), (98, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-1-686 Locale: LANG=en_GB, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages initramfs-tools depends on: ii busybox 1:1.1.2-1 Tiny utilities for small and embed ii cpio 2.6-11 GNU cpio -- a program to manage ar ii klibc-utils 1.3.19-2 small statically-linked utilities ii module-init-tools 3.2.2-2tools for managing Linux kernel mo ii udev 0.091-2/dev/ and hotplug management daemo initramfs-tools recommends no packages. -- no debconf information -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft [EMAIL PROTECTED] : :' :proud Debian developer and author: http://debiansystem.info `. `'` `- Debian - when you have better things to do than fixing a system signature.asc Description: Digital signature (GPG/PGP) ---End Message--- ---BeginMessage--- Source: initramfs-tools Source-Version: 0.65 We believe that the bug you reported is fixed in the latest version of initramfs-tools, which is due to be installed in the Debian FTP archive: initramfs-tools_0.65.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.65.dsc initramfs-tools_0.65.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.65.tar.gz initramfs-tools_0.65_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.65_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. maximilian attems [EMAIL PROTECTED] (supplier of updated initramfs-tools package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 24 Jun 2006 13:27:49 +0200 Source: initramfs-tools Binary: initramfs-tools Architecture: source all Version: 0.65 Distribution: unstable Urgency: low Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: maximilian attems [EMAIL PROTECTED] Description: initramfs-tools - tools for generating an initramfs Closes: 364301 369617 374378 374891 Changes: initramfs-tools (0.65) unstable; urgency=low . * scripts/local-top/lvm: Activate root and resume volume group. The initialization got refractored in an function. (closes: #374891) Thanks for the patch to David Härdeman [EMAIL PROTECTED]. . * scripts/local-top/lvm: Be careful to activate volume group on lilo boot too. Although in that case we don't know the precise volume group, we activate them all. Matches behaviour of previous hook. . * hooks/lvm: Add dm-mirror, allows to boot from an unfinished pvmove. (closes: #374378) . * mkinitramfs: Remove old kernel-package supported long param. kernel-package uses since 10.036 mkinitramfs-kpkg. . * update-initramfs: Show by default which initramfs gets generated. (closes: #364301) . * Resync with 0.40ubuntu32: - Make prereqs conditional on the script/hook actually existing. From now on, this means that 'PREREQ=udev' means run udev first, iff it happens to be installed. Having the files exist on the filesystem if you have a HARD dependency should be enforced with package dependencies. (closes: #369617) - Make update-initramfs -u try to find the running kernel *after* it attempts to search the symbolic link list and its own sha1 list. Using this as a
Bug#364301: marked as done (initramfs-tools: Please show what is being done on upgrades)
Your message dated Sat, 24 Jun 2006 16:02:16 -0700 with message-id [EMAIL PROTECTED] and subject line Bug#364301: fixed in initramfs-tools 0.65 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) ---BeginMessage--- Package: initramfs-tools Version: 0.60 Something I find extremely annoying at the moment is that initramfs-tools is silent when it generates an initrd during upgrade of, for example, udev. What I get on e.g. my sparc is: Setting up udev (0.090-1) ... Installing new version of config file /etc/udev/permissions.rules ... and then it just sits there for 2 minutes or so. Two minutes to install a new version of a config file? No, of course not, a new initrd is being generated, but initramfs-tools just does not tell us so... I also think it is important to be more verbose about it because that would let users know _which_ initrd (or initrds) have been regenerated. If the user has other kernels on the system besides the running one, he may want to regenerate those too. At the moment though, he doesn't get a clue about what is and (maybe even more importantly) what isn't being done. pgpRgRXZ5156b.pgp Description: PGP signature ---End Message--- ---BeginMessage--- Source: initramfs-tools Source-Version: 0.65 We believe that the bug you reported is fixed in the latest version of initramfs-tools, which is due to be installed in the Debian FTP archive: initramfs-tools_0.65.dsc to pool/main/i/initramfs-tools/initramfs-tools_0.65.dsc initramfs-tools_0.65.tar.gz to pool/main/i/initramfs-tools/initramfs-tools_0.65.tar.gz initramfs-tools_0.65_all.deb to pool/main/i/initramfs-tools/initramfs-tools_0.65_all.deb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. maximilian attems [EMAIL PROTECTED] (supplier of updated initramfs-tools package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Sat, 24 Jun 2006 13:27:49 +0200 Source: initramfs-tools Binary: initramfs-tools Architecture: source all Version: 0.65 Distribution: unstable Urgency: low Maintainer: Debian kernel team debian-kernel@lists.debian.org Changed-By: maximilian attems [EMAIL PROTECTED] Description: initramfs-tools - tools for generating an initramfs Closes: 364301 369617 374378 374891 Changes: initramfs-tools (0.65) unstable; urgency=low . * scripts/local-top/lvm: Activate root and resume volume group. The initialization got refractored in an function. (closes: #374891) Thanks for the patch to David Härdeman [EMAIL PROTECTED]. . * scripts/local-top/lvm: Be careful to activate volume group on lilo boot too. Although in that case we don't know the precise volume group, we activate them all. Matches behaviour of previous hook. . * hooks/lvm: Add dm-mirror, allows to boot from an unfinished pvmove. (closes: #374378) . * mkinitramfs: Remove old kernel-package supported long param. kernel-package uses since 10.036 mkinitramfs-kpkg. . * update-initramfs: Show by default which initramfs gets generated. (closes: #364301) . * Resync with 0.40ubuntu32: - Make prereqs conditional on the script/hook actually existing. From now on, this means that 'PREREQ=udev' means run udev first, iff it happens to be installed. Having the files exist on the filesystem if you have a HARD dependency should be enforced with package dependencies. (closes: #369617) - Make update-initramfs -u try to find the running kernel *after* it attempts to search the symbolic link list and its own sha1 list. Using this as a fallback, rather than the default, should solve most upgrade issues, where people found their initramfs was half-baked. - Abstract out the kernel minversion checking stuff into the function library, so we can reuse it to check minversion requirements for hook scripts as well (such as udev, which requires = 2.6.15 in dapper) - Bump the kernel minversion to 2.6.15 on hppa and ia64, since they used initrd-tools with their 2.6.12 kernels in breezy, not initramfs-tools. - If
Processing of initramfs-tools_0.65_i386.changes
initramfs-tools_0.65_i386.changes uploaded successfully to localhost along with the files: initramfs-tools_0.65.dsc initramfs-tools_0.65.tar.gz initramfs-tools_0.65_all.deb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: merging 355580 361674
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.20 merge 355580 361674 Bug#355580: initramfs-tools: fails to load required modules, boot fails Bug#361674: please do not use mdrun at all Merged 355580 361674. End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 337663
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.20 tags 337663 - wontfix Bug#337663: initramfs-tools does not load correct keymap Tags were: wontfix Tags removed: wontfix End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: tagging 355580
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.20 tags 355580 - moreinfo Bug#355580: initramfs-tools: fails to load required modules, boot fails Tags were: moreinfo patch Tags removed: moreinfo End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: closing 340508
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.20 close 340508 Bug#340508: unclean initramfs generation on s390 'close' is deprecated; see http://www.debian.org/Bugs/Developer#closing. Bug closed, send any further explanations to Ivan S. Warren [EMAIL PROTECTED] End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
