Bug#1063162: please omit single initrd.img generation if dpkg trigger for all is pending
Source: initramfs-tools Severity: minor Currently, when installing other packages together with a new kernel, initramfs image for the new kernel is generated two times: once it is kernel-activated from /etc/kernel/postinst.d/initramfs-tools, and next it is dpkg-trigger-activated by updating certain paths (eg installing or upgrading busybox, mdadm, etc, which triggers initramfs rebuilds). This is especially annoying when building images for virtual machines (like debvm-create etc), - there, initramfs is especially slow (it is already very slow as it is, but makes several times slower when run in emulated environment). The whole thing needs to be generated only once, dpkg trigger should be enough, but it is actually generated twice. For that I suggest to check in /etc/kernel/postinst.d/initramfs-tools if dpkg trigger for it is pending already, and if yes, do not generate the whole thing but create just a stub, an empty /boot/initrd.img-$kver, to be updated later when dpkg trigger is fired. That will save a lot of time in various situations, including regular user machines where initrd is often regenerated multiple times during upgrades. Thanks, /mjt
Re: Immediate fallouts from the big linux changes, and actions
24.12.2023 11:16, Cyril Brulebois : ... Searching for information about fuse and virtio, I finally noticed this entry, which probably explains both fuse's “going away” and ditto for some (but not all) virtio modules: * Set CONFIG_VIRTIO_FS and its dependencies to builtin, to allow building images that boot directly to rootfs (skipping the initrd) as it changes: -CONFIG_VIRTIO_PCI=m +CONFIG_VIRTIO_PCI=y -CONFIG_FUSE_FS=m +CONFIG_FUSE_FS=y -CONFIG_VIRTIO_FS=m +CONFIG_VIRTIO_FS=y Hm. This same argument can be used to include every storage- and filesystem-related module into the kernel. Why don't we have ahci and sd_mod built-in? This does look quite a bit strange to me to include this stuff.. (This commit is not about big linux changes but about small debian changes ;) /mjt
Bug#810154: [PATCH initramfs-tools 0/4] Changes to busybox integration
22.01.2016 01:14, Ben Hutchings wrote: > This series removes the busybox hook script and definition of > BUSYBOXDIR from initramfs-tools, leaving busybox itself responsible > for these. Oh well. How many times I talked with Max on IRC, sent patches, created a git tree for initramfs to pull from.. His answer has always been the same: no need. So I gave up, creating an ugly zzz-busybox which undoes the mess done in initramfs script. Please note that once the d-i team prevented me from maintaining busybox, this package remains unmaintained. So maybe it is a better idea to remove usage of busybox in initramfs (which this series actually does). Thank you Ben! (And yes, I'm still subscribed to busybox package, for unknown reason). /mjt
Bug#677049: [trivial] please don't hardcode /bin/sleep path
Package: initramfs-tools Version: 0.106 Severity: wishlist Two scripts in initramfs-tools currently hardcodes path to sleep as /bin/sleep, because busybox sleep (which were used when busybox is in used) didn't accept fractional secounds. Fractional secounds are accepted by busybox sleep since version 1:1.18.5-1, so it is safe now to stop hardcoding the path. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120611102105.32626.49417.reportbug@gandalf.local
Bug#677049: [trivial] please don't hardcode /bin/sleep path
On 11.06.2012 19:45, Julien Cristau wrote: On Mon, Jun 11, 2012 at 14:21:05 +0400, Michael Tokarev wrote: Two scripts in initramfs-tools currently hardcodes path to sleep as /bin/sleep, because busybox sleep (which were used when busybox is in used) didn't accept fractional secounds. Fractional secounds are accepted by busybox sleep since version 1:1.18.5-1, so it is safe now to stop hardcoding the path. It's not safe without Breaks on older busybox (or Depends on the newer one). Yes it's not safe, I know. I tried to understand whenever a versioned Recommends does the trick (there's already a versioned recommends in initramfs-tools against busybox), and, later, what does a versioned recommends _does_, or a Breaks is needed instead. So from a trivial change in one package it turned into a bit less trivial question about the package relationship. /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd61a23.4080...@msgid.tls.msk.ru
reassign 676001 back to initramfs-tools
reassign 676001 initramfs-tools thanks Reassigning the bug back to initramfs-tools where it belongs according to my comments below and lack of any arguments to the opposite. With all my dislike to such a ping-pong. Thanks, /mjt On 05.06.2012 08:45, Michael Tokarev wrote: [] I disagree it is a busybox problem, and don't think it is a switch_root business (be it from busybox or from util-linux). There are a few special directories which needs to be moved or umounted. This includes /proc, /dev, /sys and not mentioned here /run. These directories might be mounted in the new root already, or there may be some option passed to initramfs to not mount these, or there may be other local policy or whatever decisions. All that can't be handled and can't be known to switch_root -- this is exactly why we have initramfs/init as a script, to be able to handle various local usecases/policies and made it extendable. Also, as shown by Vagrant in the initial bugreport, it is really trivial to fix it in initramfs. The fact that util-linux is doing this does not make it right thing to do. Why do you think it is a busybox bug? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd19c52@msgid.tls.msk.ru
Re: Processed: reassign 676001 to busybox
[Adding debian-devel@ to the Cc list] Short story (and it is short): the bug has been filed against initramfs-tools initially, it is about how /proc and /sys filesystem should be handled in initramfs when switching to new root. Original reporter included a trivial patch for initramfs that does re-mounting of these filesystems. Max reassigned it to busybox without giving any reasonings or comments whatsoever. I explained that it is none of switch_root business, in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676001#24 , and asked to not reassign bugs without giving a word of explanation. After a few days of inactivity I reassigned this bug back to initramfs, per my explanation. Now max reassigned it back. On 08.06.2012 14:49, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: reassign 676001 busybox Bug #676001 [initramfs-tools] initramfs-tools: busybox's switch_root doesn't handle /proc or /sys moving Bug reassigned from package 'initramfs-tools' to 'busybox'. Wonderful. I asked you nicely a) to stop reassigning without explanation, and b) to provide some comments about why do you think it is a busybox isue, at the same time providing my reasoning why it is not. After you failed to provide any comments, I reassigned it back to initramfs-tools. And you, 2nd time in a row, does the same: reassigning it back to bysubox (where, as I described before, it does not belong to), and gives neither explanation nor any comments/answers to my reasoning. So I've no other solution but to tag this as wontfix in busybox, because I think it is not where it should be fixed, as per my previous explanation. Mind you, this solution does not help users at all. /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd1db0e.6040...@msgid.tls.msk.ru
Re: Processed: reassign 676001 to busybox
On 08.06.2012 14:59, Michael Tokarev wrote: [] Wonderful. I asked you nicely a) to stop reassigning without explanation, and b) to provide some comments about why do you think it is a busybox isue, at the same time providing my reasoning why it is not. Ok. This was premature. Somehow I received this reassigning message quite a bit before the comments you actually added when doing it the second time. So yes, there are some comments now, I stand corrected. I'll address these in #676001. Thanks. /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd1dc19.7020...@msgid.tls.msk.ru
Re: Processed: reassign 676001 to busybox
On 08.06.2012 14:52, maximilian attems wrote: dude care to have a bit of patience before reassigning back, that be really nice. I gave a few days, maybe it was too few, I dunno. On Tue, Jun 05, 2012 at 08:45:59AM +0400, Michael Tokarev wrote: [] I disagree it is a busybox problem, and don't think it is a switch_root business (be it from busybox or from util-linux). switch_root in util-linux does it. Yes, but it is still none of its business. There are a few special directories which needs to be moved or umounted. This includes /proc, /dev, /sys and not mentioned here /run. These directories might be mounted in the new root already, or there may be some option passed to initramfs to not mount these, or there may be other local policy or whatever decisions. All that can't be handled and can't be known to switch_root -- this is exactly why we have initramfs/init as a script, to be able to handle various local usecases/policies and made it extendable. If you name a command switch-root and not run-init, you'd have to take care to emmulate what the original command does. In this case it is util-linux is clearly predating busybox and thus busybox is buggy not fully implementing the command. Almost no of busybox commands implements fully the corresponding big brother behavour. But this is not the point. The point is, and I described it above, it is none of switch_root business to move other filesystems, because it does not have enough information. We've a long list of actions an initramfs does, and this list includes mounting many filesystems. The script which does that has much more information about what it should do and how, and has much more chances to report errors (eg, when the new root does not have /proc or /sys directory or whatever). Besides, and I also mentioned that in my initial explanation above, /proc and /sys are not different from any other filesystem which should be moved to the new root - like /run or /dev. Now it'd be nice to know why util-linux handles these, but again, it is not the point at all. Just move these explicitly, exactly the way it is done with /run or anything else which might be needed later. /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd1ddb2.7050...@msgid.tls.msk.ru
Re: Processed: reassign 676001 to busybox
On 08.06.2012 15:28, maximilian attems wrote: On Fri, Jun 08, 2012 at 02:59:26PM +0400, Michael Tokarev wrote: [Adding debian-devel@ to the Cc list] Short story (and it is short): the bug has been filed against initramfs-tools initially, it is about how /proc and /sys filesystem should be handled in initramfs when switching to new root. Original reporter included a trivial patch for initramfs that does re-mounting of these filesystems. Max reassigned it to busybox without giving any reasonings or comments whatsoever. I explained that it is none of switch_root business, in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=676001#24 , and asked to not reassign bugs without giving a word of explanation. After a few days of inactivity I reassigned this bug back to initramfs, per my explanation. Now max reassigned it back. no, no, you get the story wrong. The bug on initramfs-tools side is fixed^Wworked-around. I reassigned the *cloned* bug to busybox to have it properly fixed there. Aha. This makes MUCH more sense now. Somehow I thought you reassigned just the original bugreport to busybox. please get an ice cream and keep cool. No need to make a drama out of a simple single bug. Without the above explanation (cloned), it looked to me like completely wrong thing to do from your side, and indeed, I become very upset seeing a reassign again without explanations/comments (these were somehow received later, after I already sent the hot email out). That's exactly what I talked about on the initial reassignment -- lack of any comments. Now when you explained and I actually looked at the bug history and noticed the clone operation (#660297), things become real again. And no, I can't get an ice cream. I've a flu currently with body temperature being 38.6°C, so I guess an ice cream may do more harm than good. And in this context, I can buy the argument about busybox not implementing switch_root functionality from util-linux. Thank you for explaining things, and I'm sorry for being upset for nothing. /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fd22cc7.6050...@msgid.tls.msk.ru
Re: Processed: reassign 676001 to busybox
On 05.06.2012 00:45, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: reassign 676001 busybox Bug #676001 [initramfs-tools] initramfs-tools: busybox's switch_root doesn't handle /proc or /sys moving Bug reassigned from package 'initramfs-tools' to 'busybox'. When reassigning bugs like this, care to explain the reasoning too, so that it wont be necessary to send a followup questions like this one? I disagree it is a busybox problem, and don't think it is a switch_root business (be it from busybox or from util-linux). There are a few special directories which needs to be moved or umounted. This includes /proc, /dev, /sys and not mentioned here /run. These directories might be mounted in the new root already, or there may be some option passed to initramfs to not mount these, or there may be other local policy or whatever decisions. All that can't be handled and can't be known to switch_root -- this is exactly why we have initramfs/init as a script, to be able to handle various local usecases/policies and made it extendable. Also, as shown by Vagrant in the initial bugreport, it is really trivial to fix it in initramfs. The fact that util-linux is doing this does not make it right thing to do. Why do you think it is a busybox bug? Thanks, /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fcd8f07.9030...@msgid.tls.msk.ru
Bug#653067: package description missing some info
Package: tgt Version: 1:1.0.17-1 Severity: minor The description of tgt package, from 1:1.0.17-1 version: Description: Linux SCSI target user-space tools The Linux target framework (tgt) allows a Linux system to provide SCSI devices (targets) over networked SCSI transports. . Tgt consists of kernel modules, user-space daemon, and user-space This package contains the user-space daemon and tools; a recent Linux kernel is required for the modules. Apparently there's one or more lines missing in the 2nd paragraph: Tgt consists of ..., and user-space here This package... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111223133311.19422.2540.reportbug@gandalf.local
Bug#640672: moving files to arch specific include breaks compilations with -m32
The same is obviously true the other way around: on a 32bit x86 userspace it was possible to compile 64bit binaries using -m64. Now this is broken in exactly the same way as it is for -m32 on 64bits. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e6e05f5.6080...@msgid.tls.msk.ru
Bug#632457: mount.nfs segfaults with 2-component kernel version number (like 3.0)
Package: nfs-common
Version: 1:1.2.3-3
Severity: normal
Tags: upstream
mount.nfs segfaults if kernel version number does not contain
at least 3 components delimited with a dot.
The following patch fixes it somehow, but it's wrong because
it does not take into account that a dot may be part of, say,
debian release number like 3.0-debian3.0.1 for example.
--- nfs-utils-1.2.3.orig/utils/mount/version.h
+++ nfs-utils-1.2.3/utils/mount/version.h
@@ -38,13 +38,15 @@ static inline unsigned int linux_version
{
struct utsname my_utsname;
unsigned int p, q, r;
+ const char *rp;
if (uname(my_utsname))
return 0;
p = atoi(strtok(my_utsname.release, .));
q = atoi(strtok(NULL, .));
- r = atoi(strtok(NULL, .));
+ rp = strtok(NULL, .);
+ r = rp ? atoi(rp) : 0;
return MAKE_VERSION(p, q, r);
}
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20110702115410.11692.48528.reportbug@gandalf.local
Re: [PATCH 5/5] create links in initramfs to busybox with other names if not already exist
08.04.2011 15:13, maximilian attems wrote:
On Sat, 19 Mar 2011, Michael Tokarev wrote:
[]
+for link in $(${BUSYBOXDIR}/busybox --list-full 2/dev/null); do
+if [ ! -e ${DESTDIR}/$link ]; then
+[ -d ${DESTDIR}/${link%/*} ] || mkdir -p
${DESTDIR}/${link%/*}
+ln -s /bin/busybox ${DESTDIR}/$link
+fi
+done
h
Care to explain the beauty of aboves compared to STANDALONE_SHELL
simplicity?
Yes, easily. The above way we can control which implementations
are used. With CONFIG_STANDALONE_SHELL (which this whole thing
tries to remove) if something is built into busybox it gets
executed, no matter if the actual utility may be not from busybox.
Consider for example module-init-tools - if I enable modprobe in
busybox it will be used no matter which implementation you actually
put into initramfs.
It is also quite unnatural, so to say, - to provide an utility with
some extended arguments/features and wonder why it fails when you
run it in initramfs or whatever else busybox is used.
Note the patch above creates links to busybox only when there's
no alternative implementation already available in initramfs.
In other words, it gives us a choice -- either use busybox
implementation or whatever else user may have wish to use.
Later on, continuing modprobe example again, we can make
module-init-tools initramfs hook optional (conditional),
controlled by presense of busybox and a configuration
variable for example.
That's the whole reason of the change - to make busybox
to act as any other regular command does, and provide
what a user actually expects.
Thanks!
/mjt
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d9f4ddf.2090...@msgid.tls.msk.ru
iniramfs: smal bunch of small changes, getting rid of busybox STANDALONE_SHELL
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I'm trying to get rid of the ugly hack in busybox, which is activated by CONFIG_STANDALONE_SHELL in busybox configuration. What it does is: when you run its shell, ash, and run a command, such as dd or ls, and this command is provided by this busybox binary too, busybox executes itself to run this command, instead of trying to search it in $PATH as it's usually done. So effectively, all busybox commands becomes shell builtins like cd and echo (which is a built-in in most shells nowadays). This standalone shell mode helps when you're working in some rescue environment where you want as less filesystem access as possible, so that just one (probably statically linked) executable is enough for everything. But such a usage case is very, well, special. In all other cases, such behavour is unexpected and confusing at best, and there's no good way to control which implementation of commands will be used if both busybox and an external binary provides the same command. So I'm trying to get rid of CONFIG_STANDALONE_SHELL in busybox, and initramfs is the only user of this feature currently. The plan is to introduce (sym)links in initramfs pointing to busybox for all applets it provides, instead of just one executable which when executes itself. The patchset that follows is a bunch of very small changes for initramfs hooks that does the following: [001] don't move klibc's sh.shared to sh, link instead this is a tiny optional change, for consistency, so to say: when using symlinks it becomes more obvious which implementation is being used. Moreover, by not moving the original sh.shared we keep it even in case we'll use something else in the future. [002] don't warn about md-root need busybox: it doesn't anymore unrelated cleanup patch but it is in the same place I'll touch later: we believed mdadm needs busybox in initramfs, but it has been fixed long ago [003] don't copy busybox to sh, use proper name and symlink [004] rename hooks/busybox to hooks/zz-busybox to reorder it to be last hook this is in order to ensure that busybox hook will be run last, in order to fill the gaps, -- to create links to busybox only for those commands which don't already exist in initramfs. [005] create links in initramfs to busybox with other names if not already exist the final thing The whole thing is also available in a git repository, git://git.corpit.ru/initramfs-tools.git in create-links-to-busybox branch. This series is based on maks/mkinitramfs_cp branch of initramfs git repository on alioth, since it requires commit 11e9453a29cbc1 mkinitramfs: copy over on build instead of using symlink tree, because it uses symlinks heavily. This is just one possible approach. Another approach will be to move whole hooks/busybox into busybox package, just like hooks/klibc actually, -- I'm not sure what kernel team prefers. Thanks! /mjt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iJwEAQECAAYFAk2EjNIACgkQUlPFrXTwyDiUWgQA0nWrEU7ryNkA/RltD3aLBKDz 7U9rcME69OkaQy+1KsP4jnFjyJ/OBU1IBxdGbUeSaBzax8ZKgqnx5xnRsC9cnxB5 N8ZGR9tTPdYPXSOxwv0AtLhUVW47OVz7X/kvHIPuYcXVy3MUH3wFx0+NPtWdeNUc Ga/Vv0k8HwAq1+8pVxI= =h3jX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d848cd2.2020...@msgid.tls.msk.ru
[PATCH 1/5] don't move klibc's sh.shared to sh, link instead
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hooks/klibc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/hooks/klibc b/hooks/klibc
index 7690ca5..681c504 100755
--- a/hooks/klibc
+++ b/hooks/klibc
@@ -20,5 +20,5 @@ cp -pL /usr/lib/klibc/bin/* ${DESTDIR}/bin
cp -pL /lib/klibc-*.so ${DESTDIR}/lib
rm -f ${DESTDIR}/bin/kinit* ${DESTDIR}/bin/zcat
if [ ${BUSYBOX} = n ] || [ ! -e ${BUSYBOXDIR}/busybox ]; then
- mv ${DESTDIR}/bin/sh.shared ${DESTDIR}/bin/sh
+ ln -s sh.shared ${DESTDIR}/bin/sh
fi
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1300532524-25825-1-git-send-email-...@msgid.tls.msk.ru
[PATCH 3/5] don't copy busybox to sh, use link instead
mkinitramfs uses cpio --dereference, so it copies each symlink
as its target not as symlink. In order to compensate for that,
use hard link instead.
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hooks/busybox |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hooks/busybox b/hooks/busybox
index d6acd20..d6dd3f5 100755
--- a/hooks/busybox
+++ b/hooks/busybox
@@ -20,5 +20,6 @@ if [ ${BUSYBOX} != n ] [ -e ${BUSYBOXDIR}/busybox ];
then
. /usr/share/initramfs-tools/hook-functions
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
- copy_exec ${BUSYBOXDIR}/busybox /bin/sh
+ copy_exec ${BUSYBOXDIR}/busybox /bin/busybox
+ ln -s busybox ${DESTDIR}/bin/sh
fi
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1300532524-25825-3-git-send-email-...@msgid.tls.msk.ru
[PATCH 3/5] don't copy busybox to sh, use proper name and symlink
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hooks/busybox |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/hooks/busybox b/hooks/busybox
index d6acd20..d6dd3f5 100755
--- a/hooks/busybox
+++ b/hooks/busybox
@@ -20,5 +20,6 @@ if [ ${BUSYBOX} != n ] [ -e ${BUSYBOXDIR}/busybox ];
then
. /usr/share/initramfs-tools/hook-functions
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
- copy_exec ${BUSYBOXDIR}/busybox /bin/sh
+ copy_exec ${BUSYBOXDIR}/busybox /bin/busybox
+ ln -s busybox ${DESTDIR}/bin/sh
fi
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1300532524-25825-4-git-send-email-...@msgid.tls.msk.ru
[PATCH 4/5] rename hooks/busybox to hooks/zz-busybox to reorder it to be last hook
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hooks/{busybox = zz-busybox} |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename hooks/{busybox = zz-busybox} (100%)
diff --git a/hooks/busybox b/hooks/zz-busybox
similarity index 100%
rename from hooks/busybox
rename to hooks/zz-busybox
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1300532524-25825-5-git-send-email-...@msgid.tls.msk.ru
[PATCH 5/5] create links in initramfs to busybox with other names if not already exist
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hooks/zz-busybox |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/hooks/zz-busybox b/hooks/zz-busybox
index d6dd3f5..1846376 100755
--- a/hooks/zz-busybox
+++ b/hooks/zz-busybox
@@ -22,4 +22,13 @@ if [ ${BUSYBOX} != n ] [ -e ${BUSYBOXDIR}/busybox ];
then
rm -f ${DESTDIR}/bin/busybox
copy_exec ${BUSYBOXDIR}/busybox /bin/busybox
ln -s busybox ${DESTDIR}/bin/sh
+ # Create links with other names if not already exist
+ # (for this to work this hook should be the last)
+ # Current busybox may come without --list[-full] support
+ for link in $(${BUSYBOXDIR}/busybox --list-full 2/dev/null); do
+ if [ ! -e ${DESTDIR}/$link ]; then
+ [ -d ${DESTDIR}/${link%/*} ] || mkdir -p
${DESTDIR}/${link%/*}
+ ln -s /bin/busybox ${DESTDIR}/$link
+ fi
+ done
fi
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1300532524-25825-6-git-send-email-...@msgid.tls.msk.ru
[PATCH 2/5] don't warn about md-root need busybox: it doesn't anymore
Signed-off-by: Michael Tokarev m...@tls.msk.ru
---
hooks/busybox |8 +---
1 files changed, 1 insertions(+), 7 deletions(-)
diff --git a/hooks/busybox b/hooks/busybox
index 6f2db8c..d6acd20 100755
--- a/hooks/busybox
+++ b/hooks/busybox
@@ -16,13 +16,7 @@ prereqs)
esac
# busybox
-if [ ${BUSYBOX} = n ] || [ ! -e ${BUSYBOXDIR}/busybox ]; then
- # those root need busybox
- eval $(mount | awk '/ \/ / {print r_dev= $1; exit}')
- if [ ${r_dev#/dev/mapper/} != ${r_dev} ]; then
- echo W: Busybox is required for successful boot!
- fi
-else
+if [ ${BUSYBOX} != n ] [ -e ${BUSYBOXDIR}/busybox ]; then
. /usr/share/initramfs-tools/hook-functions
rm -f ${DESTDIR}/bin/sh
rm -f ${DESTDIR}/bin/busybox
--
1.7.2.3
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/1300532524-25825-2-git-send-email-...@msgid.tls.msk.ru
Re: [PATCH 3/5] don't copy busybox to sh, use link instead
19.03.2011 17:00, Ben Hutchings wrote:
On Sat, 2011-03-19 at 14:02 +0300, Michael Tokarev wrote:
mkinitramfs uses cpio --dereference, so it copies each symlink
as its target not as symlink. In order to compensate for that,
use hard link instead.
[...]
+ln -s busybox ${DESTDIR}/bin/sh
[...]
Really?
There are 2 patches numbered 3/5 - one of them leaked
from before I rebased the changes on top of Max's branch
(it was in my temp dir from git format-patch). This one
should be ignored, and it's not present in the git tree
either.
Thanks,
/mjt
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d84e34b.9060...@msgid.tls.msk.ru
Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
28.11.2010 05:25, Ben Hutchings wrote: Please can you test whether this is fixed in 2.6.32-28? We backported a KVM feature (VCPU_EVENTS) which meant we needed an additional fix beyond the one which Michael Tokarev identified, and that was done in -28. Yes, with 2.6.32-28 686 kernel I can't reproduce the problem anymore, kvm works as intended, while reverting back to -27 returns the issue. Reading #599507 again, together with this #604604 and also #604900, it looks like all this stuff is the same thing. There's also #580652. Out of curiocity, why this feature (VCPU_EVENTS) were backported/applied in the first place (it was in 2.6.32-12)? Isn't it somewhat too buggy having in mind all the above? Thank you! /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cf23166.1000...@msgid.tls.msk.ru
Bug#604604: qemu-kvm: vm entry failed with error 0xffffffff; kvm_run returned -22
tags 604604 - upstream patch thanks Hello again. After a bit more testing it turns out this problem is somehow specific to debian 2.6.32-5-686-27 kernel, it does not occur on upstream (kernel.org) kernel even when not applying the mentioned patch (which went into upstream -stable just a few days ago, but which was in debian for quite some time already). Stock kernel - with or without that patch - works fine. amd64 Debian kernel works fine too. But Debian 686 kernel immediately returns that ugly -22 to every kvm_run(). At least here on a CPU similar to your (mine is Turion TL-52, which is of the same generation as 4400+ you're using, with the same problems). I'm not sure yet if it's specific to svm (amd) or general. /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4cebe9ed.60...@msgid.tls.msk.ru
Bug#592707: kernel should be protected against old package kvm-source
Source: linux-2.6 Severity: minor There was a package in Lenny, kvm-source, which contains kernel module for kvm subsystem and is built from package named kvm. All modern kernels includes kvm modules. Kvm package is now transitional to qemu-kvm, which does not provide any kernel modules or packages like kvm-source. kvm-source package has been removed from squeeze. When kvm-source package is installed, it replaces kvm modules in current kernel with old, obsolete ones, so that current kvm userspace does not work anymore. But current kernel includes more recent kvm modules which works correctly even with old userspace. So kvm-source breaks current kernels. It breaks even lenny's kernel (2.6.26), which includes more recent kvm modules than in kvm-source_72 (from lenny), and even more - 2.6.26 received a few security fixes for kvm modules which are not present in kvm-source. The only solution to this I see is to include Conflicts: into kernel against kvm-source (unversioned). Note that it is not sufficient to add such conflicts: to qemu-kvm (userspace component), because one may have installed kvm-source without qemu-kvm, kvm-source broke the kernel module (replacing it with older and buggy one), and later qemu-kvm is installed on already broken system. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c63b1c7.6010...@msgid.tls.msk.ru
Bug#589055: qemu-kvm: booting sid amd64 kernel 2.6.32-17 fails
reassign 589055 linux-2.6 2.6.32-17 thanks 14.07.2010 19:39, Michal Suchanek wrote: Package: qemu-kvm Version: 0.12.4+dfsg-1 Severity: normal Booting a live CD with the 2.6.32-17 kernel stops early on message Write protecting the kernel read-only data: 4220k The CPU loops, with -smp 2 two CPUs loop The -15 kernel from squeeze works fine. The qemu-system-x86_64 without accel also works fine. This is a bug in kernel, apparently fixed by this patch: http://patchwork.kernel.org/patch/85087/ which went into 2.6.32.12 stable series. I'm not sure if it is already available in Debian. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c5691e9.4020...@msgid.tls.msk.ru
Re: lxc linux image flavour
Marco d'Itri wrote: On Jan 24, maximilian attems m...@stro.at wrote: [] On the negative side it doesn't have yet checkpointing support and not all net/ has netns support yet. It's not just that, AFAIK there is no match for many of the user_beancounters features (especially the accounting part) and e.g. lack of the equivalent of vzctl enter is a critical issue for my applications. Accounting is done in cgroups. Not as flexible as in openvz, but it works. As of `vzctl enter', there's something very similar, but it requires to have getty (or similar) running on ttyN in guest. Probably not what you want. While I am happy to see better support for lxc in Debian, it does not look like an openvz replacement yet. It doesn't, indeed. Both has their own bad and good sides. The main good about lxc is that it's in the standard kernel, and kernel components are ready (maybe modulo some features like freezing/migration). Openvz, linux-vserver, other things - all require quite intrusive patches, which complicating support tasks alot. /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
