Bug#600937: Please disable /etc/kernel postinst hook if the target kernel is non-modular
Package: initramfs-tools
Version: 0.98.4
Severity: minor
Tags: patch
If I try to install a non-modular kernel
/etc/kernel/postinst.d/initramfs-tools tries to build an initrd image
and fails, because no modules are found. Please apply the attached patch
(or a similar one) to disable it for that case.
Thanks,
Guido
From 9f638f2eabb49da543ca153f6649601630c7f478 Mon Sep 17 00:00:00 2001
From: Guido Trotter ultrot...@debian.org
Date: Thu, 21 Oct 2010 16:58:53 +0100
Subject: [PATCH] Don't try build initramfs on non-modular kernel
If the kernel is build without modules support (for example for a
virtual machine) then there's no point in trying to build an initrd
image.
Signed-off-by: Guido Trotter ultrot...@debian.org
---
kernel/postinst.d/initramfs-tools |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/kernel/postinst.d/initramfs-tools
b/kernel/postinst.d/initramfs-tools
index d4db23d..d820a55 100755
--- a/kernel/postinst.d/initramfs-tools
+++ b/kernel/postinst.d/initramfs-tools
@@ -27,5 +27,12 @@ if [ -n $DEB_MAINT_PARAMS ]; then
fi
fi
+# don't run on a non-modular kernel
+if [ -f /boot/config-$version ]; then
+ if grep -vq CONFIG_MODULES=y /boot/config-$version; then
+ exit 0
+ fi
+fi
+
# we're good - create initramfs. update runs do_bootloader
update-initramfs -c -t -k ${version} ${bootopt} 2
--
1.7.1
Bug#432971: Similar issue, but solved
I had a similar problem for 2.6.20 and 2.6.21, but it was solved for me in 2.6.22... Does this work for you too? Can this be closed? Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423006: Bugs merged
Hi! I've reassigned the bug we had against xen to initramfs-tools, as it is, as reported, the same bug, and being a bug with the image generation we can't do anything on our side about it. Also I re-raised the severity to critical because, as stated by the severity description, this bug makes unrelated software on the system (or the whole system) break. Namely it breaks xen, or whole systems with xen installed. Feel free to lower its severity if you think this is inappropriate, but please provide a reason, so I can know why I am mistaken! :) Thanks!! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401558: Possible explanation
Hi! What I found out is that the debian ipw3945-modules-* package (made by kernel-package with make-kpkg) distributes the /etc/modprobe.d/ipw3945-modules file while ipw3945d distributes /etc/modprobe.d/ipw3945d which both start the daemon. This might be the cause of the problem. I suggest removing the file from ipw3945-modules-* as there might be more than one of those package installed at the same time, and they would fight for ownership of that file, I think... So this could probably be retitled to shouldn't ship /etc/modprobe.d/ipw3945-modules and reassigned to ipw3945-source... Correct me if I'm wrong... Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401692: Can the daemon be started without root privileges?
Package: ipw3945d Version: 1.7.22-2 Severity: wishlist Hi, ipw3945d documentation says it can work in non-root mode and provides examples for that... Can the debian package be done so it by default adds an unprivileged ipw3945d and runs the daemon under it? Thanks, Guido -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.19.0rw02 Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8) Versions of packages ipw3945d depends on: ii adduser 3.99Add and remove users and groups ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii lsb-base 3.1-22 Linux Standard Base 3.1 init scrip Versions of packages ipw3945d recommends: ii firmware-ipw3945 0.3Binary firmware for IPW3945 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Tue, Feb 28, 2006 at 02:17:45PM +0100, Sven Luther wrote: Hi, I can. :) Guido, be warned that Bastian often communicates with a few monosylabes and SVN commits :) This doesn't make working with him too problematic usually though :) We've been a bit more chatty, for now, but I guess we will survive as long as the commits are agreed by everyone... ;) At this point I propose Jeremy to add Bastian to the pkg-xen alioth project (he's the only one who can do that, I think) and we can go ahead! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Mon, Feb 27, 2006 at 02:29:51PM +0100, Sven Luther wrote: Hi, I guess that if people are able to find a kernel source tree outside of debian, they are perfectly capable of downloading and applying a patch too. Just include an URL to wherever such a patch is in the README.Debian of the packages, should be enough. Yes, this is the current plan! Thanks for your suggestions! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Mon, Feb 27, 2006 at 01:51:51PM +0100, Sven Luther wrote: Hi, The kernel patches for XEN should be maintained inside the kernel team and in linux-2.6, they are free to join the kernel team to handle this, but it is unacceptable to have some kind of external patch to the kernel floating around, and having no cooperation between the XEN team and the kernel team will kind of encourage people to build their own xen kernel from mainline upstream sources, which i believe is not what we want. Absolutely true! The current xen team is fully agrees on this position! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Xen in Debian [u]
On Sat, Feb 25, 2006 at 01:11:35AM +0100, Frederik Schueler wrote: Hi, I am sorry things have rushed today, things which should have better been discussed by all concerned persons, _before_. True, we're sorry on our part about that! We have been tracking xen support in the linux-2.6 source package as an item on the todo list for 2.6.16 since a week or two, but we have not yet discussed the details of what that means within the kernel team. And since a couple of weeks we've started working on packaging the hypervisor and userspace utils, after some time failing to contact the current Xen maintainer through the BTS. Sorry we have delayed reaching the kernel team! We didn't know it was on your todo list and so we had planned to do it later, after fixing the hypervisor! (as we thought sorting out the kernel that would have been a bit longer term than having a better shaped and newer hypervisor and utils). Looking at the components of xen, I think we should at least take care of the dom0 kernels, and of course stay in close contact with the pkg-xen team to coordinate releases with the userland tools. We fully support this course of action (as it's something we've already discussed)! I agree with everything else you said. Thanks, Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
Bastian Blank wrote: Hi! The debian kernel team will maintain xen images with the linux-2.6 source. I currently prepare both xen 3.0 and unstable packages, which can be hopefully uploaded today. Maintainer will be the kernel team, as there are heavy dependencies between xen and the kernel. This is great! In the meantime we are working on uploading xen 3.0 to unstable, and our packages I think are almost ready too! We planned to contact the kernel team after the upload to see how to coordinate, but it's nice to know that the kernel part is being taken care of! :) Our packages don't contain any kernel (we wouldn't have uploaded them without asking the kernel team, of course) but we plan on shipping just the xen patch for a kernel.org kernel, just in case someone preffers running a non-debian kernel: is that OK, or should we remove that from our sources? Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 04:54:24PM +0100, Julien Danjou wrote: Hi, As far as I understand, you will just maintain Xen kernel images. (for dom0 only ?). Actually I think he meant the hypervisors too... Anyway I also think that if the kernel team is going to maintain the kernel images there should be some made for unprivileged domains too! :) We just have to duplicate our packages to add a -unstable release. I don't think this is a great deal, at the point we are, we can do it. Yeah, I think so too... But I'm also for making xen 3.0 enter unstable first, and uploading the unstable branch a bit later! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:20:17PM +0100, Isaac Clerencia wrote: Hi, Well, if the kernel team answers left to the kernel team and you close the alioth project, I guess you can always move into the kernel team ;) Yes, we could, of course... But on the other hand I believe that the xen hypervisor and userspace tools are actually different from the linux kernel (as they support multiple kernels and operating systems), even though the linux kernel patch has its right place inside the kernel itself... I agree that we should have probably have publicized more about our intent to work on xen, but at least it was spread all other the BTS in the xen package! And on the other hand we didn't know about Bastian's effort (which was not in the bts under either wnpp or xen), or we wouldn't have started our work without asking him! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:41:53PM +0100, Isaac Clerencia wrote: Hi, I agree. I just would like to ask that, please, don't disband just because of disagreement with the kernel team, but try to cooperate anyway. I don't think we want to! And I hope there is no disagreement (we still don't know)! The reason I think xen would be better served having its own committed team, repository, etc, is that it would be easier for anyone interested in xen to follow just mailing lists dedicated to it and its repository commits, rather than having to closely follow all the linux kernel work, mailing list, etc! Of course I also think it's great to have some people on both, so to have a close coordination between the xen and kernel releases. Also the xen team would need to coordinate with the glibc team (for the segmentation issues) and one day with the d-i team too, in order to try making a Debian/GNU/Xen/Linux (or whatever that should be called) installable directly on a system! Even upstream considers the linux kernel patch, the hypervisor and the tools separate, has separate mailing lists for them, and a separate mercurial repository for linux, even if for now they distribute the linux patch together with xen, until xen is merged into Linus' tree (or at least so Ian Pratt has said). If we can have the xen patch included in the debian kernel, thus pre-dating kernel.org inclusion that's really a good thing! Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 06:06:22PM +0100, Bastian Blank wrote: Hi, It is a sort of kernel. Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems the kernel team is about the linux kernel, not just any kernel, isn't it? Just to say, how connected xen to linux is: For example: There are three kernel trees of xen: - from xen-3.0-testing, 2.6.12 - from linux-2.6-xen, 2.6.16-rc4 - from linux-2.6-merge, 2.6.16-rc3 All of them have different needs from xen. The kernels from xen-3.0-testing and linux-2.6-merge works with a 3.0 and unstable hypervisor. The 3.0 utils only works on the kernel from xen-3.0-testing. The unstable utils with the other. But with both hypervisors. That's I think because xen is still young, and is starting just now its distribution integration, and probably will happen a lot less when it will be integrated with Linux (Linus' tree) and the development of xenolinux will proceed at a different pace than the hypervisor. Then probably it will just be that any xen version will have a minimum linux version needed, just as now a lot of other stuff does, and there will be nothing special in it, except the fact that it needs a kernel compiled for the appropriate subarch). I won't reject the help of volunteers but I strongly think that the kernel team needs to have its hands on them. What do other people in the kernel team think? If the majority of them agree fine, otherwise are you sure it's not counterproductive to force xen in the kernel team hands if most of them don't want to touch it, and on the other hand to risk driving away other people who just cannot follow the whole linux business but could work on the xen hypervisor and tools, help coordinate with xen's upstream, debian glibc and d-i, etc! Especially if you and other people who would do both can still do it! :) Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:34:44PM -0800, Steve Langasek wrote: Hi, Yeah, it's a sort of kernel, but it's not the linux kernel... And it seems the kernel team is about the linux kernel, not just any kernel, isn't it? The dom0 kernel is a Linux kernel built for the Xen hypervisor target. If Debian is to provide a complete packaged environment for Xen, which is certainly the goal I'm interested in (and Bastian as well, by the looks of it), that means packaging (at least) a dom0 kernel; and the only way to do that which would make the cut for stable is if it's kept synchronized with the main linux-2.6 package. I think the only reasonable way to do that is within the kernel team, which means people interested in helping with this part should consider joining the kernel team. Yes, we absolutely agree about this! We also would have liked for the patch to be integrated in the kernel team's work and from the xen kernel to be built and maintained by the kernel team (of course we hadn't contacted them yet, so we didn't know before if they were interested or if that would have been possible, so it's great to know that such intrest exists!). Of course I agree that anyone interested in Linux+Xen kernel work should join the kernel team! For the userspace tools and the hypervisor, clearly there's no reason why these need to be part of the kernel team repo as long as they aren't going to be part of the same linux-2.6 source package. As Bastian points out, though, there does still need to be close coordination between the hypervisor/userspace tools and the XenoLinux build, because we don't yet have mix-and-match compatibility. I absolutely agree... That's why I'm kindly asking Bastian to join us and to be on both teams, so he and other people interested in doing both can act as a bridge. My feeling is that it still makes sense to maintain the hypervisor and userspace tools in a separate pkg-xen group, and just coordinate between the kernel and xen teams for this; but that should be sorted out among those doing the work. I certainly can't see any benefits in terms of source management to having them in the same svn repo with the kernel, anyway. Thanks for your comments! And are any of them applicable as patches to today's 2.6.15 linux-2.6 tree? I haven't tried, for now... Bastian, have you? What are the results? That's I think because xen is still young, and is starting just now its distribution integration, and probably will happen a lot less when it will be integrated with Linux (Linus' tree) and the development of xenolinux will proceed at a different pace than the hypervisor. Then probably it will just be that any xen version will have a minimum linux version needed, just as now a lot of other stuff does, and there will be nothing special in it, except the fact that it needs a kernel compiled for the appropriate subarch). In the meantime, to the extent this is an issue it probably means that some of this stuff isn't ready for inclusion in etch. I don't see a point in uploading two versions of xen to unstable, certainly, if they aren't both going to work with the provided kernels. Of course I agree with you that until the kernel team (together with the interested people on the xen team) is able to produce working kernels for at least one version of Xen (and possibly the stable one) it's better for us not to push for its inclusion. We are planning to maintain unofficial packages for sarge (for people that want to use Xen right now) and can do that for etch too, if things don't sort out before release. It would be nice anyway to have some more support for Xen in etch (perhaps non segmented glibcs) even if xen itself is not included! Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-xen-devel] Re: Packaing Xen 3.0 etc for Debian
On Fri, Feb 24, 2006 at 05:40:04PM -0800, Steve Langasek wrote: Hi, FWIW, the policy on kernel patches for sarge was that if it didn't apply to the kernel sources we shipped, it didn't need to be included as a package in stable. We're obviously not shipping a 2.6.12 kernel for etch, so I wouldn't bother uploading that part... And if they do they can probably be integrated anyway! Ok then, we can probably withraw the patch! Even though that can make things a bit harder for those not running debian kernels since xen is not yet integrated in there... Thanks! Guido -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
