Re: Offer help on initramfs-tools
Hi! * Benjamin Drung [Wed Mar 06, 2024 at 11:45:38AM +0100]: > initramfs-tools hasn't seen an upload since 2022-07-12 and has several > open merge requests without response. Since I am maintaining initramfs- > tools in Ubuntu, I offer my help on initramfs-tools in Debian. In case I > became uploader, I would merge the fixes and uncontroversial changes and > cut a release. For various reasons I am personally no longer really active in initramfs-tools (i-t) development, but since nobody else responded to you yet: thanks for your work and efforts and reaching out, *I* think any contributions and work around i-t are more than welcome. > One change that we did in Ubuntu recently is using dracut-install which > speeds up the initramfs generation a lot: > https://launchpad.net/bugs/2031185 > Do you want to have that in Debian as well? Sounds great to me! :) regards -mika- signature.asc Description: PGP signature
Re: Bug#1022172: /lib/modprobe.d/50-nfs.conf causes initramfs-tools to stop including sunrpc module for nfs
* Marco d'Itri [Sun Oct 23, 2022 at 12:05:18AM +0200]: > On Oct 22, Andras Korn wrote: > > nfs-kernel-server, for example, the 'install' command wants to invoke > > sysctl --pattern, but the busybox sysctl installed in the initramfs by > > default doesn't support --pattern. So the package would need to force > > initramfs to include the /sbin/sysctl from procps, and maybe also any > > pertinent files from /etc/sysctl.d. > Looks like this is a different problem. FYI: I reported this one as #1024082, looks like the new /lib/modprobe.d/50-nfs.conf file is causing quite some problems. (FTR, this showed up at the Grml live system, see e.g. https://github.com/grml/grml/issues/193 ) regards -mika- signature.asc Description: PGP signature
Bug#998749: firmware-misc-nonfree: i915 freezes randomly in X especially when playing videos
severity 998749 important thanks Hi, * Jonibek Ander uulu [Sun Nov 07, 2021 at 09:45:52PM +0600]: > Package: firmware-misc-nonfree > Version: 20210315-3 > Severity: grave > Justification: renders package unusable I'd assume this bug report needs further information so it can be handled by the kernel team. Furthermore this RC bug ended up removing all src:firmware-nonfree packages from Debian/testing, so I'll hereby downgrade the severity of this bug. regards -mika- signature.asc Description: PGP signature
Bug#992798: initramfs-tools: please drop shellcheck autopkgtest
Hi, * Samuel Henrique [Sat Sep 11, 2021 at 09:50:08PM +0100]: > > Thanks for letting me know! I just updated the MR accordingly. > Awesome, do you have any plans of uploading that anytime soon? > Shellcheck is still waiting in unstable and I would like to provide > the new release on backports. No, I don't have any such plans currently, especially as I'd like to get the MR accepted by someone else in the (kernel) team first. (Same for https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/41 btw) regards -mika- signature.asc Description: Digital signature
Bug#992798: your mail
Hi Samuel, * Samuel Henrique [Fri Aug 27, 2021 at 07:10:14PM +0100]: > Thanks for providing the MR, Michael, > There's just one thing missing so the MR can close this bugreport; it > needs to drop the shellcheck autopkgtest. > Would you like to amend this change to your MR? Ah, I misunderstood the request regarding autopkgtest. Thanks for letting me know! I just updated the MR accordingly. regards -mika- signature.asc Description: Digital signature
Bug#992798: initramfs-tools: please drop shellcheck autopkgtest
tags 992798 + patch thanks Hi, * Paul Gevers [Mon Aug 23, 2021 at 05:41:20PM +0200]: > Source: initramfs-tools [...] > Control: affects -1 src:shellcheck > Dear maintainer(s), > With a recent upload of shellcheck the autopkgtest of initramfs-tools > fails in testing when that autopkgtest is run with the binary packages > of shellcheck from unstable. It passes when run with only packages from > testing. In tabular form: >passfail > shellcheck from testing0.7.2-2 > initramfs-toolsfrom testing0.140 > all others from testingfrom testing [...] I took care of this and created a MR which addresses those shellcheck issues: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/50 It's worth mentioning, that shellcheck v0.7.2 includes a regression, see https://github.com/koalaman/shellcheck/issues/2217 regards -mika- signature.asc Description: Digital signature
Bug#980788: Acknowledgement (netboot: support booting from USB WiFi devices)
Patch/MR is available at https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/41 regards -mika- signature.asc Description: Digital signature
bpfcc: Provide separate package for libbpf-tools?
Package: bpfcc Version: 0.17.0-9 Severity: wishlist Hi! (Cc-ing the kernel team, since it might be relevant for coordination or packaging efforts, please feel free to reassign to src:linux if that should be more appropriate) With the ongoing efforts around BTF and CO-RE (see http://www.brendangregg.com/blog/2020-11-04/bpf-co-re-btf-libbpf.html), it would be nice to have a decent and working toolchain for it with our upcoming bullseye release. Given that CONFIG_DEBUG_INFO_BTF support is in the works (see #973870), it would be nice, if we could provide bcc's libbpf-tools through a separate package. Looking at e.g. libbpf-tools's compiled biolatency binary, it only depends on libc6, libelf1 + zlib1g and it's less than 250kb (stripped) total size: | % ldd ./biolatency | linux-vdso.so.1 (0x7ffcb01ef000) | libelf.so.1 => /lib/x86_64-linux-gnu/libelf.so.1 (0x7f348b386000) | libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f348b369000) | libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f348b1a4000) | /lib64/ld-linux-x86-64.so.2 (0x7f348b3e6000) | % ls -lah ./biolatency | -rwxr-xr-x 1 mika mika 239K Dec 30 13:47 ./biolatency Same for all the other tools which are currently shipped via libbpf-tools (see https://github.com/iovisor/bcc/tree/master/libbpf-tools), all being below 250KB and depending only on libc6, libelf1 + zlib1g. Whereas bpfcc-tools pulls in over 200MB of of additional disk space, bpftrace still also adds ~190MB of disk space - mainly due to their dependency on libllvm11. So IMO it would be great, if it's possible to ship libbpf-tools on Debian/bullseye systems without giving it much thoughts due to dependencies and disk space requirements. regards -mika- signature.asc Description: Digital signature
Bug#976054: initramfs-tools: [RFC] Compress initramfs file with zstd
* Hideki Yamane [Sun Nov 29, 2020 at 10:06:21AM +0900]: > Now initramfs files are compressed with gzip > But we can use other compression, i.e. LZO, LZ4 and ZSTD. > Then which one is the best? > * compression ratio >ZSTD > GZIP > LZO > LZ4 > * decompression speed >LZ4 > LZO = ZSTD > GZIP > I suggest to choose ZSTD, instead of GZIP since > - better compression ratio than current GZIP > - also better decompresion speed than current GZIP [...] > Yes, 59MB initramfs file becomes 40MB (2/3)! plus bonus, better decompression > speed. Thanks for bringing this up. Do we have any numbers for where xz resides in terms of decompression speed? Is it enough to just decompress the files in userspace for getting numbers, or is the kernel doing something special™ to be kept in mind? JFTR, some further numbers regarding file sizes: | # file netboot.initrd* | netboot.initrd.gzip: gzip compressed data, last modified: Wed Dec 2 10:13:21 2020, from Unix, original size 135559168 | netboot.initrd.lz4: LZ4 compressed data (v0.1-v0.9) | netboot.initrd.lzop: lzop compressed data - version 1.030, LZO1X-1, os: Unix | netboot.initrd.xz: XZ compressed data | netboot.initrd.zstd: Zstandard compressed data (v0.8+), Dictionary ID: None | # ls -lah netboot.initrd* | -rw-r--r-- 1 root root 43M Dec 2 10:13 netboot.initrd.gzip | -rw-r--r-- 1 root root 51M Dec 2 10:25 netboot.initrd.lz4 | -rw-r--r-- 1 root root 60M Dec 2 10:24 netboot.initrd.lzop | -rw-r--r-- 1 root root 29M Dec 2 10:17 netboot.initrd.xz | -rw-r--r-- 1 root root 32M Dec 2 10:16 netboot.initrd.zstd regards -mika- signature.asc Description: Digital signature
Re: Initramfs-tools boot issue with bad console
Hi, * Guilherme Piccoli [Fri Jul 03, 2020 at 05:29:52PM -0300]: > Thanks for your +1 there Michael! Do you know if there's a way to get > that merged? I'd like to follow the proper process and fix that on > Debian before Ubuntu. I'm not sure if Ben is watching/noticing Salsa MRs, Ben? Guilherme, you already added the patch to #962545 (excellent and thanks :)), that's where Ben should notice it for sure. :) > Also, just for my knowledge for future submissions: is it better to > send a patch via email, as an attachment in a bug report message, than > a merge request in salsa? I'd like to follow the procedure that is > preferred by the maintainers. > Thanks, I'm no longer active in the initramfs-tools maintenance, so I'll leave that answer to Ben (and possible further/upcoming maintainers of i-t). regards -mika- signature.asc Description: Digital signature
Bug#900349: linux-image-4.9.0-6-amd64 does not support RAID controller (530-4i Flex) of Lenovo ThinkSystem SN550 servers
* Michael Prokop [Wed May 30, 2018 at 10:05:16AM +0200]: > * Ben Hutchings [Tue May 29, 2018 at 08:58:35PM +0100]: > > On Tue, 29 May 2018 13:41:13 +0200 Michael Prokop wrote: > > > The current kernel version of Debian/stretch (4.9.0-6-amd64) doesn't > > > support the RAID controller as present in Lenovo ThinkSystem SN550 > > > blade servers (https://lenovopress.com/lp0637-thinksystem-sn550-server). [...] > > Is it sufficient to apply that single commit? I'm attaching a > > slightly modified version that applies to stretch. > Thanks for providing that patch, sadly it doesn't seem to be enough. > `cat /proc/partitions` is empty and I'm stuck in busybox/initramfs > during boot: > (initramfs) dmesg | grep megaraid > [2.735633] megaraid_sas :08:00.0: Waiting for FW to come to ready > state > (initramfs) modinfo megaraid_sas | grep -i 001c > alias: pci:v1000d001Csv*sv*sd*bc*sc*i* FTR, kernel v4.15 and newer support the said RAID controller, feel free to close this bug report (not doing it myself just in case you think it's useful to keep it open for someone else). regards -mika- signature.asc Description: Digital signature
Bug#900349: linux-image-4.9.0-6-amd64 does not support RAID controller (530-4i Flex) of Lenovo ThinkSystem SN550 servers
* Ben Hutchings [Tue May 29, 2018 at 08:58:35PM +0100]:
> On Tue, 29 May 2018 13:41:13 +0200 Michael Prokop wrote:
> > The current kernel version of Debian/stretch (4.9.0-6-amd64) doesn't
> > support the RAID controller as present in Lenovo ThinkSystem SN550
> > blade servers (https://lenovopress.com/lp0637-thinksystem-sn550-server).
> > It's known to be supported with Ubuntu 18.10 using kernel 4.15, I
> > gathered hardware information from a Grml live system which uses
> > kernel 4.15 though, being based on Debian's debian/4.15.17-1 (git
> > commit 0b520de976c19).
> [...]
> > AFAICT the relevant support has been introduced as of git commit
> > 45f4f2eb3da3 ("scsi: megaraid_sas: Add new pci device Ids for SAS3.5
> > Generic Megaraid Controllers") in upstream kernel repository, present
> > in kernel versions 4.11 and newer.
> [...]
> Is it sufficient to apply that single commit? I'm attaching a
> slightly modified version that applies to stretch.
Thanks for providing that patch, sadly it doesn't seem to be enough.
`cat /proc/partitions` is empty and I'm stuck in busybox/initramfs
during boot:
(initramfs) dmesg | grep megaraid
[2.735633] megaraid_sas :08:00.0: Waiting for FW to come to ready state
(initramfs) modinfo megaraid_sas | grep -i 001c
alias: pci:v1000d001Csv*sv*sd*bc*sc*i*
(Manually extracted from remote console screenshot:
https://michael-prokop.at/screeni/screenshot.2018-05-30T09:50:11.png)
regards,
-mika-
signature.asc
Description: Digital signature
Re: [PATCH initramfs-tools 0/9] Fix resume device configuration
* Ben Hutchings [Fri Apr 21, 2017 at 04:33:09AM +0100]: > The change in version 0.128 to wait for the resume device to appear > uncovered a number of systems for which the resume device is not > properly configured. In fact, systems with swap partitions that > are never available at boot could not be configured correctly, > other than by adding 'noresume' to the kernel command line! > While working on that, I found and fixed a couple of other > longstanding bugs in resume device selection. [...] > If no-one finds issues with this these changes then I'm hoping > to make one more release for "stretch" with just these. The changes LGTM (I didn't test/verify them though). Thanks, Ben. regards, -mika- signature.asc Description: Digital signature
Bug#844600: initramfs-tools-core: inconditional copy of /etc/modprobe.d/*
* Ben Hutchings [Thu Nov 17, 2016 at 03:29:44PM +]: > On Thu, 2016-11-17 at 16:16 +0100, Michael Prokop wrote: > > * Raphael Geissert [Thu Nov 17, 2016 at 03:51:33PM +0100]: > > > mkinitramfs attempts to copy /etc/modprobe.d/* (module-init-tools > > > section), without checking if there are actually files in that > > > directory. This results in a warning in the middle of update- > > > initramfs > > > as /etc/modprobe.d/* does not exist. > > This is #829280 and just waiting for a new release to be done. > > Ben, do you have any timeline/plans WRT new i-t release? (I can take > > care of the upload if that would help.) > I do intend to make at least one upload before stretch release, > addressing several of the open bugs including this one. But I don't > mean to block anyone else from working on it. I'll leave it to you then, thanks! :) regards, -mika- signature.asc Description: Digital signature
Bug#844600: initramfs-tools-core: inconditional copy of /etc/modprobe.d/*
* Raphael Geissert [Thu Nov 17, 2016 at 03:51:33PM +0100]: > mkinitramfs attempts to copy /etc/modprobe.d/* (module-init-tools > section), without checking if there are actually files in that > directory. This results in a warning in the middle of update-initramfs > as /etc/modprobe.d/* does not exist. This is #829280 and just waiting for a new release to be done. Ben, do you have any timeline/plans WRT new i-t release? (I can take care of the upload if that would help.) regards, -mika- signature.asc Description: Digital signature
Bug#829280: initramfs-tools: "cannot stat '/etc/modprobe.d/*'" warning from empty /etc/modprobe.d/
control: tag -1 +pending * Christoph Biedl [Sat Jul 02, 2016 at 12:16:07PM +0200]: > Michael Prokop wrote... > > Right (while kmod ignores the non *.conf files - so no harm done - > > it might still be confusing for the user). > (...) > > http://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?h=mika/829280) > > and let us know whether this works for you? > Looks good. Thanks for your swift reaction. Thanks for testing and prompt feedback, merged and pushed to master, scheduled for next release. regards, -mika- signature.asc Description: Digital signature
Bug#829280: initramfs-tools: "cannot stat '/etc/modprobe.d/*'" warning from empty /etc/modprobe.d/
* Christoph Biedl [Sat Jul 02, 2016 at 12:17:11AM +0200]: > when /etc/modprobe.d/ exists but is empty, update-initramfs issues > a warning: > | # update-initramfs -k all -u > | update-initramfs: Generating /boot/initrd.img-4.6.0-1-amd64 > | cp: cannot stat '/etc/modprobe.d/*': No such file or directory > Besides cosmetical issues I wonder what happens if there are files that > just are a reminder of dpkg conffile handling, like e.g. > /etc/modprobe.d/pptpd.conf.dpkg-remove > since appearently update-initramfs happily processes them. Which is > probably not the right thing to do. Right (while kmod ignores the non *.conf files - so no harm done - it might still be confusing for the user). Could you please give the package build from http://jenkins.grml.org/job/initramfs-tools-binaries/architecture=amd64/154/ a try (or if you prefer to test a patch see http://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?h=mika/829280) and let us know whether this works for you? regards, -mika- signature.asc Description: Digital signature
Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
* Karsten Merker [Thu Sep 25, 2014 at 08:15:48AM +0200]: On Tue, Sep 23, 2014 at 11:42:08PM +0200, Michael Prokop wrote: Does this look like it would provide what you're asking for? http://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?h=mika/bug_762634id=3b835665015c0a9287284c2548b12ab7c8cabc78 outside d-i and for the MODULES=most configuration, this works fine: [...] Inside the /target chroot created by d-i, update-initramfs is by default configured to run with MODULES=dep and gives only the following modules on my armhf/sunxi test system: Hmpf, I so much am not a fan of this default MODULES=dep behaviour of d-i... [...] The phy-sun4i-usb module is missing there, although it is loaded by the running kernel: # lsmod |grep phy_sun4i_usb phy_sun4i_usb 4260 4 Without phy_sun4i_usb, USB support does not work at all on this platform, so this module would always have to be included. The missing ohci-hcd and ohci-platform modules would be explained by the fact that this particular device technically has both EHCI and OHCI controllers, but the platform-dependent OHCI glue code is not yet implemented in the kernel, so the OHCI part is currently invisible to the kernel. Ok When manually running update-initramfs with MODULES=most inside the d-i /target chroot, all three modules (ohci-platform, ehci-platform and phy-sun4i-usb) are there, but by default the user is not presented with a choice regarding MODULES=dep vs. MODULES=most in d-i. The relevant debconf prompt is only presented at debconf priority medium, i.e. when running d-i in expert mode, so I would appreciate very much if you could include the missing phy-sun4i-usb module also when building the initramfs with MODULES=dep. Is there a /sys/... entry which would make it obvious for i-t that phy-sun4i-usb exists/should be loaded? regards, -mika- signature.asc Description: Digital signature
Bug#652459: too little, too late?
* Joey Hess [Thu Sep 25, 2014 at 01:32:36AM -0400]: We're starting to have to work around this bug in d-i, by eg making separate /usr a harder situation to get into when installing Debian. My calendar says 10 days until freeze start. I sincerely hope someone does something. I get your point, but in my calendar it's ~41 days until the freeze, am I mistaken? * Marco d'Itri [Thu Sep 25, 2014 at 07:43:43AM +0200]: Would anybody mind if I just uploaded straight to unstable a new initramfs-tools package with no concern at all for the maintainer's unexpressed wishes? It would have been more useful if you provided feedback on my calls for help/feedback (e.g. in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459#136 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459#194) Anyway, I'm working on it (even though I have zero interest in this feature on my own and actually don't have time for it) - I noticed some problems with the code which I try to resolve... regards, -mika- signature.asc Description: Digital signature
initramfs-tools 0.117 release
Hi, trying to address Please support mounting of /usr in the initramfs - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459 - I've just uploaded initramfs-tools version 0.117 to Debian unstable. regards, -mika- Git shortlog: Michael Prokop (3): Bump Standards-Version to 3.9.6 hooks/fsck: fall back to blkid, make sure fsck binary exists + install /sbin/sulogin Releasing version 0.117 Roger Leigh (12): nfs: Move retry_nr to site of use and rename to nfs_retry_count nfs: Rename do_nfsmount to nfs_mount_root_impl resolve_device: Canonicalise symbolic links to real device nodes Add support for running fsck local: Add local_top, local_premount and local_bottom nfs: Add nfs_top, nfs_premount and nfs_bottom functions: Add read_fstab_entry functions: Add resolve_device function Add functions to mount filesystems from /etc/fstab scripts: Add overridable indirect functions init: Use generic mount functions, and mount /usr local: Generalise local device setup signature.asc Description: Digital signature
Bug#762634: initramfs-tools: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
* Cyril Brulebois [Thu Sep 25, 2014 at 12:32:22PM +0200]: Michael Prokop m...@debian.org (2014-09-25): * Karsten Merker [Thu Sep 25, 2014 at 08:15:48AM +0200]: Inside the /target chroot created by d-i, update-initramfs is by default configured to run with MODULES=dep and gives only the following modules on my armhf/sunxi test system: Hmpf, I so much am not a fan of this default MODULES=dep behaviour of d-i... Can you please clarify? I see this in base-installer: | if db_get base-installer/initramfs-tools/driver-policy \ |[ -z $RET ]; then | # Get default for architecture | db_get base-installer/kernel/linux/initramfs-tools/driver-policy | db_set base-installer/initramfs-tools/driver-policy $RET | fi | db_settitle debian-installer/bootstrap-base/title | db_input medium base-installer/initramfs-tools/driver-policy || true | if ! db_go; then | db_progress stop | exit 10 | fi | | db_get base-installer/initramfs-tools/driver-policy | if [ $RET != most ]; then | cat $IT_CONFDIR/driver-policy EOF | # Driver inclusion policy selected during installation | # Note: this setting overrides the value set in the file | # /etc/initramfs-tools/initramfs.conf | MODULES=$RET | EOF | fi Granted, no coffee yet. But I seem to recall that people having issues with MODULES=dep are those who actually selected it manually (e.g. through expert install). I'm just not a friend of MODULES=dep as a default behaviour, good to know that d-i uses a sane default here. :) Thanks for verifying! My local test confirms that a basic installation (netboot-gtk image on amd64 using udebs from sid) leads to MODULES=most in /target. I didn't go further than the popcon prompt though. Excellent, then from my PoV there's nothing further to be done in i-t, since the default configuration works fine. regards, -mika- signature.asc Description: Digital signature
Bug#762870: initramfs-tools: fails to boot after upgrade from 0.116 to 0.117
* pdorm...@free.fr [Thu Sep 25, 2014 at 10:21:42PM +0200]: System fails to boot with 0.117. Following messages are displayed: -f: No such file or directory fsck: No such file or directory fsck exited with status code 1 Usage : mount [-r] [-w] [-o options] [-t type] [-f] [-i ] [-n] device directory mount: No such file or directory Could not copy file: No such file or directory Target filesystem doesn't have requested /sbin/init No init found. Try passing init=bootarg Do you have a separate /usr partition? If so, is it a normal partition or used on top of LVM/RAID/...? Please, let me know what other information may be usefull. Can you please execute: bash -x mkinitramfs -o /dev/null /tmp/trace.log 21 and provide us the resulting /tmp/trace.log file? regards, -mika- signature.asc Description: Digital signature
Bug#762634: [armhf] mounting rootfs on USB disk fails / some USB host controller drivers missing in initramfs
* Karsten Merker [Tue Sep 23, 2014 at 11:22:32PM +0200]: running Debian with the root filesystem on a USB mass storage device (such as a USB harddisk) requires that the driver modules for the USB host controllers of the system are available in the initramfs. If they are missing, the root filesystem cannot be mounted, which currently happens on a number of armhf systems. On i386/amd64, the OHCI/EHCI host controllers are PCI devices which are supported by the ohci-pci and ehci-pci modules. On many armhf systems the USB host controllers are OHCI/EHCI-compatible, but implemented as a platform device, so they are not supported by ohci-pci and ehci-pci. Instead these systems need the following platform device driver modules: - ohci-platform - ehci-platform and in the case of armhf/sunxi-based systems an additional USB phy driver module: - phy-sun4i-usb These modules are not included in the initramfs built by initramfs-tools (even if MODULES=most is set in initramfs.conf), which makes it impossible to boot with the rootfs on a USB disk on such systems. Please always include ohci-platform, ehci-platform and phy-sun4i-usb into the initramfs if they are provided by the kernel for which the initramfs is built. Does this look like it would provide what you're asking for? http://anonscm.debian.org/cgit/kernel/initramfs-tools.git/commit/?h=mika/bug_762634id=3b835665015c0a9287284c2548b12ab7c8cabc78 regards, -mika- signature.asc Description: Digital signature
Bug#760119: /dev/disk/by-uuid: Is a directory
* Norbert Preining [Mon Sep 01, 2014 at 02:44:36PM +0900]: On Mon, 01 Sep 2014, Michael Prokop wrote: Which version of initramfs-tools did you use before? in my aptitude.log I find: [UPGRADE] initramfs-tools:amd64 0.115 - 0.116 Ok. Did your upgrade also involve an update of the kernel/reboot of your system? sh -x /usr/sbin/mkinitramfs -o /tmp/initramfs.output 2/tmp/mkinitramfs.log Here it is. Thanks, so this commandline seems to be a problem for your system: blkid -o value -s UUID /dev/root Can you please provides its output and also attach output of: mount cat /proc/mounts ls -la /dev/root ? regards, -mika- signature.asc Description: Digital signature
Bug#760119: /dev/disk/by-uuid: Is a directory
* Norbert Preining [Mon Sep 01, 2014 at 04:11:17PM +0900]: On Mon, 01 Sep 2014, Michael Prokop wrote: Ok. Did your upgrade also involve an update of the kernel/reboot of your system? Hmm, hard to say. I often update between kernels. So it might have been the same time I swtiched form 3.16 to 3.17-rc2. 3.17-rc2 isn't part of any Debian repos AFAICS, is that a self compiled one? blkid -o value -s UUID /dev/root no output. ok, as expected mount /dev/root on / type btrfs (rw,relatime,ssd,space_cache) devtmpfs on /dev type devtmpfs (rw,relatime,size=4041792k,nr_inodes=1010448,mode=755) [...] cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / btrfs rw,relatime,ssd,space_cache 0 0 devtmpfs /dev devtmpfs rw,relatime,size=4041792k,nr_inodes=1010448,mode=755 0 0 [...] rootfs / rootfs rw 0 0 /dev/root / btrfs rw,relatime,ssd,space_cache 0 0 devtmpfs /dev devtmpfs rw,relatime,size=4041792k,nr_inodes=1010448,mode=755 0 0 [...] ls -la /dev/root ls: cannot access /dev/root: No such file or directory This is strange, reporting /dev/root in /proc/mounts but not having the file/symlink actually. Please verify: * You're booting using GRUB * You used btrfs for the root filesystem also before the upgrade * initramfs-tools v0.115 generates an initramfs just fine If the answer to all those question is yes please test an older Linux kernel version as present in an official Debian repository. regards, -mika- signature.asc Description: Digital signature
Bug#760119: /dev/disk/by-uuid: Is a directory
* Norbert Preining [Tue Sep 02, 2014 at 08:09:17AM +0900]: On Mon, 01 Sep 2014, Michael Prokop wrote: * initramfs-tools v0.115 generates an initramfs just fine Yes-No. It depends on the *running* kernel: - running 3.16 initramfs 0.115 and 0.116 can create proper initrams for *all* kernels, also for 17-rc2 - running 3.17-rc2 initramfs fails Ha perfect, that's what I was hoping for. :) (I really couldn't imagine that i-t 0.116 triggered your problem.) When I switch to a new kernel I normally to make oldconfig and check through the new options and that works. How to proceed? Do you want to close the bug because it is a 3.17-rc2 bug? Or search for the reason? I'm definitely interested in getting to the root of the problem. Could you please provide output of mount and cat /proc/mounts when running the 3.16 kernel? regards, -mika- signature.asc Description: Digital signature
initramfs-tools 0.116 release
Hi, I just released and uploaded version 0.116 of initramfs-tools towards Debian/unstable, addressing several bug reports we had pending in Debian's BTS and trying to get i-t into better shape for the upcoming Debian/jessie release. The shortlog has the details: Aurelien Jarno (1): hook-functions: add support for virtio-mmio Helge Deller (1): get_fstype: initialize FSTYPE variable Michael Prokop (9): Fix hidden dependency issue with btrfs and crc32c Do not spawn shell when panic=... is used Preserve file permissions if root builds the initramfs images Support drop_capabilities=... boot option Support MODULES=dep usage on i2o hardware RAID controller Support usage of partitioned nbd devices with MODULES=dep Inform user that lsinitramfs doesn't support cpio archives yet Bump Standards-Version to 3.9.5 Releasing version 0.116 maximilian attems (1): scripts/nfs: fix nfs mount check for possible init symlink regards, -mika- signature.asc Description: Digital signature
Bug#717805: Adding an advice about lsinitramfs is not working when hit this bug ?
Hi, JFTR: * Javier Barroso [Tue Mar 25, 2014 at 11:11:31PM +0100]: While the patch at 22 comment in this bug [1] is not accepted (can you clarify why it is not accepted or applied?), I suggest adding an advice to script. [...] I just uploaded initramfs-tools v0.116 to Debian/unstable including a change close to what you proposed - thanks for that. This should improve the situation until someone comes up with a future-proof(ier) patch which properly supports the cpio initramfs. Any further help welcome! regards, -mika- signature.asc Description: Digital signature
Bug#678696: Event based block device handling (fixes USB and nested devices problem)
Hi, f'up to our recent discussion we had on IRC * Goswin von Brederlow [Sat Jun 23, 2012 at 09:25:28PM +0200]: the attached patch adds an event based loop for block devices to the init script. New blockdevices are recorded in /run/initramfs/block-events by an udev rule as they appear. The init script repeadately waits for that and then calls /scripts/local-block/* with a list of new devices storedin NEWDEVS until $ROOT and $resume (if set) exists or a timeout is reached. This fixes the problem that USB devices take too long to be discovered and crypto, raid, lvm or multipath can't be started on them. It also adds support for arbitrary nestings of them, e.g. raid5 over raid1. [...] First of all thanks again for the patch and your helpful feedback on IRC. I've tested your patch based on top of current i-t git master (v0.116) with a setup like: BOOT_IMAGE=/boot/vmlinuz-3.14-2-amd64 root=/dev/mapper/vg0-root ro quiet but it sadly fails to work as intended (it boots but doesn't find the block devices until the timeout is kicking in). I didn't investigate closer yet, but AFAICS it seems to be related to the fact that /dev/mapper/vg0-root doesn't exist at that time yet. If you or someones else finds time to try and possibly further investigate I'd very much welcome and appreciate that. regards, -mika- signature.asc Description: Digital signature
Bug#760119: /dev/disk/by-uuid: Is a directory
* Norbert Preining [Mon Sep 01, 2014 at 07:53:36AM +0900]: since update to 0.116 (yesterday) initramfs-tools does not work anymore: Processing triggers for initramfs-tools (0.116) ... update-initramfs: Generating /boot/initrd.img-3.17.0-rc2+ /dev/disk/by-uuid: Is a directory mkinitramfs: for root /dev/disk/by-uuid missing disk/by-uuid /sys/block/ entry [...] Which version of initramfs-tools did you use before? I assume this problem is btrfs specific. Can you please execute: sh -x /usr/sbin/mkinitramfs -o /tmp/initramfs.output 2/tmp/mkinitramfs.log and share its resulting /tmp/mkinitramfs.log? regards, -mika- signature.asc Description: Digital signature
Bug#632627: uswsusp patches for initramfs-tools (was: Bug#632627: Re[2]: resume file)
Hi, while going through the initramfs-tools bugs I stumbled upon this one too: * Rodolfo Garc�a [Sat Aug 10, 2013 at 10:37:16PM +0200]: No. uswsusp doesn't need the kernel package (you can boot from a floppy). We need a (new?) package. uswsusp and initramfs-tools should depend on it. This package should include a script (/usr/bin/update-resume-file?) and the script should create/update a config file. The config file will be used by initramfs-tools and uswsusp (and cryptsetup and probably others). The file should include two lines, one for the resume device and other for the offset. Perhaps we should continue this thread on debian-devel, because more people could help. Feel free to forward this mail (my Internet connection here is crap). I'm unsure what to do about this one and we have several bugs open related to it (#530618, #574653 + #632627). Not being a user of neither uswsusp nor resume from disk it's hard for me to decide how to proceed here, is anyone willing to work on this? regards, -mika- signature.asc Description: Digital signature
Bug#602331: plymouth does not allow to enter maintenance shell
Hi, * Laurent Bigonville [Fri Aug 01, 2014 at 03:55:17PM +0200]: An idea on how this could be fixed? In Ubuntu they have added a panic hook to initramfs-tools that is being called in the panic() function. Do you think it's the way to go here? Otherwise I can also provide a patch for the same function to directly call the needed plymouth command (plymouth quit) I just took a look at Ubuntu's i-t and their try_failure_hooks function with features related to plymouth etc totally makes sense for me, I'd love to see that in Debian's i-t as well, so if anyone is willing to work on it you'd have my full support for that. regards, -mika- signature.asc Description: Digital signature
Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs
Hi everyone, (if you don't want to get Cc-ed any longer please let me know, just trying to involve everyone and get some traction) * Michael Prokop [Thu Jul 31, 2014 at 05:30:53PM +0200]: * Matthew Gabeler-Lee [Thu Jul 31, 2014 at 10:29:18AM -0400]: Recent package upgrades have made it all but impossible for a Debian install supporting a graphical desktop environment not to use systemd. This quietly caused a system of mine to get switched from sysvinit to systemd, and thus no longer boot properly because of this issue (among others, but this isn't the place for that rant). Can we _pretty please_ get versions of the affected packages at least uploaded to experimental? I will add my voice to those volunteering to help test. I've rebased the patchset against current git master and a preliminary and *untested*(!) package is available at: https://people.debian.org/~mika/initramfs-tools/ Feedback definitely welcome and required. maks, are you willing to accept the patchset once https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459#47 has been addressed? Maks, sadly still no reply from your side yet :( Is anyone else willing to help us in getting this issue resolved? If we want to see this issue resolved for jessie we need to get this forward soonish. So is there anyone else who has tested my package and can confirm that the issue is resolved by it? Michael Biebl, you also wrote: | Agreed. The actual patch to mount /usr is rather small. The one for | mounting /etc complicates things quite a bit. Please let's not | entangle the two and just upload the bits for mounting /usr. If | there is later demand for the /etc-mount feature, it can be added | then. This sounds good to me, is there any chance that either you, Roger Leigh or someone else would be willing to provide the according patchset (without the /etc-mount feature) rebased against our current git master and possibly while at it also take care of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459#89 ? If so please ping me (either by mail, IRC or at DebConf), any help is really appreciated. Thanks everyone regards, -mika- signature.asc Description: Digital signature
Bug#697017: root=compute fails at parse_numeric() for lilo compatibility
Hi everyone, while going through the list of initramfs-tools bugs I stumbled upon this one. * Stephen Powell [Sat Jan 05, 2013 at 09:57:08AM -0500]: On Thu, 03 Jan 2013 01:49:14 -0500 (EST), Jonathan Nieder wrote: Less than or equal to 4095 and 255 respectively, technically. ;-) The full formula was just trivia. (stat's st_dev and lilo's MKDEV() macro use it, for what it's worth.) Well I rolled up my sleeves and took a look at lilo's source code, particularly the MKDEV, MAJOR, and MINOR functions, and now I understand what you are talking about. And you're right. The current initramfs-tools code, particularly the parse_numeric function, can handle major device numbers up to 4095 and minor device numbers up to 255. Whether lilo itself, in actual fact, can correctly handle major and minor device numbers outside this range, I don't know. I didn't dig deeply enough to verify that. But given that the above three functions understand the format, I suspect that it will. If you want to enhance the code to correctly handle the full 16-hex-digit composite device number, go ahead. As you say, it's trivial. And that would once again make you the author of the final patch, which is fine. Is anyone still interested in getting this issue resolved? If someone would provide an up2date patch (against current git master would be awesome) which resolves this issue (without possibly breaking anything else :)) I'm absolutely willing to accept it. Myself not being a lilo user and not seeing any real progress in this issue for more than 1,5 years am tending to close this report otherwise. Thanks for any input. regards, -mika- signature.asc Description: Digital signature
Re: Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs
* Roger Leigh [Sat Aug 30, 2014 at 11:19:42PM +0100]: On Sun, Aug 31, 2014 at 12:13:29AM +0200, Michael Prokop wrote: * Michael Prokop [Thu Jul 31, 2014 at 05:30:53PM +0200]: I've rebased the patchset against current git master and a preliminary and *untested*(!) package is available at: https://people.debian.org/~mika/initramfs-tools/ [...] This sounds good to me, is there any chance that either you, Roger Leigh or someone else would be willing to provide the according patchset (without the /etc-mount feature) rebased against our current git master and possibly while at it also take care of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459#89 ? If so please ping me (either by mail, IRC or at DebConf), any help is really appreciated. I'm afraid I can't commit to any work at present. But regarding the mounting of /etc, that's just one or two commits at the end of the patchset. Just drop them to remove the feature. But do note that the feature is entirely harmless even if left in--it's not used by default. Thanks for additional information and the fast reply, then it would be even easier for me to integrate it since it's already there. If someone has objections please let me/us know NOW. regards, -mika- signature.asc Description: Digital signature
Bug#632627: uswsusp patches for initramfs-tools (was: Bug#632627: Re[2]: resume file)
* Askar Safin [Sun Aug 31, 2014 at 01:02:04AM +0400]: Sat, 30 Aug 2014 22:37:50 +0200 от Michael Prokop m...@debian.org: while going through the initramfs-tools bugs I stumbled upon this one too: Perhaps we should continue this thread on debian-devel, because more people could help. Feel free to forward this mail (my Internet connection here is crap). Discussion was really continued on debian-devel ( https://lists.debian.org/debian-devel/2013/08/msg00331.html ), but then disappeared :( Well, from my PoV Ben's suggestion looks good: https://lists.debian.org/debian-devel/2013/08/msg00716.html I agree that this bug should be fixed :) Are you willing to work on this? :) regards, -mika- signature.asc Description: Digital signature
Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs
[Cc-ing Roger as the author of the patchset and Marco who pinged me on IRC] * Matthew Gabeler-Lee [Thu Jul 31, 2014 at 10:29:18AM -0400]: Recent package upgrades have made it all but impossible for a Debian install supporting a graphical desktop environment not to use systemd. This quietly caused a system of mine to get switched from sysvinit to systemd, and thus no longer boot properly because of this issue (among others, but this isn't the place for that rant). Can we _pretty please_ get versions of the affected packages at least uploaded to experimental? I will add my voice to those volunteering to help test. I've rebased the patchset against current git master and a preliminary and *untested*(!) package is available at: https://people.debian.org/~mika/initramfs-tools/ Feedback definitely welcome and required. maks, are you willing to accept the patchset once https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459#47 has been addressed? Is anyone else willing to help us in getting this issue resolved? regards, -mika- signature.asc Description: Digital signature
Bug#751143: initramfs-tools: please add support for virtio-mmio
* Aurelien Jarno [Tue Jun 10, 2014 at 08:26:03PM +0200]: On most virtual machines it is possible to use the virtio interface through the PCI bus to export for example block or net devices. On some architectures the emulated machine does not have a PCI bus, and thus the transport goes through an MMIO interface. Currently initramfs-tools correctly handle the PCI case, but not the MMIO on. In case of a virtio based root device, the virtio_mmio module is not available in the initramfs causing the boot to fail. The patch below adds the virtio_mmio module if virtio is used (in dep mode), or by default (in most mode). Could you please apply it in the next upload? Thanks for the patch, applied to master so will be part of the next upload. regards, -mika- signature.asc Description: Digital signature
Bug#633582: initramfs-tools: All files in initrd owned by root
[Adding Harald Hoyer from dracut to CC, maybe he can enlighten us about the reasoning in dracut. Harald, this is about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633582 which I'm also quoting in the following mail ] * Teddy Hogeborn [Thu Jan 30, 2014 at 10:35:56AM +0100]: intrigeri intrig...@boum.org writes: Michael Prokop wrote (23 Nov 2011 11:45:14 GMT) : maximilian: i've scheduled the patch for inclusion via mika/user_permissions. Was this included eventually? No. We have, for two years now, a very ugly workaround in mandos-client to deal with this. Maks, please report back what's your opinion how to handle that. FTR, that's what dracut uses (latest git as of today): , [ dracut.sh ] | if [[ $create_early_cpio = yes ]]; then | echo 1 $early_cpio_dir/d/early_cpio | # The microcode blob is _before_ the initramfs blob, not after | (cd $early_cpio_dir/d; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet ../early.cpio) | mv $early_cpio_dir/early.cpio $outfile.$$ | fi | if ! ( umask 077; cd $initdir; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet | \ ` And see: , [ dracut.git % git show 8e5db363 ] | commit 8e5db363e8c14f2964fe71100f3dcd7f912ca283 | Author: Harald Hoyer har...@redhat.com | Date: Fri Jan 24 15:27:15 2014 +0100 | | dracut.sh: set file owners of early cpio files to 0:0 | | diff --git a/dracut.sh b/dracut.sh | index 2142e2d..0970710 100755 | --- a/dracut.sh | +++ b/dracut.sh | @@ -1464,10 +1464,10 @@ rm -f -- $outfile | dinfo *** Creating image file *** | if [[ $create_early_cpio = yes ]]; then | # The microcode blob is _before_ the initramfs blob, not after | -(cd $early_cpio_dir/d; find . -print0 | cpio --null -o -H newc --quiet ../early.cpio) | +(cd $early_cpio_dir/d; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet ../early.cpio) | mv $early_cpio_dir/early.cpio $outfile.$$ | fi | -if ! ( umask 077; cd $initdir; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet| \ | +if ! ( umask 077; cd $initdir; find . -print0 | cpio --null -R 0:0 -H newc -o --quiet | \ | $compress $outfile.$$; ); then | dfatal dracut: creation of $outfile.$$ failed | exit 1 ` So there might be a good reason why also dracut goes for all files in initrd owned by root. Harald, do you have any bug reports or details about why dracut decided to handle it this way that you might share with us? regards, -mika- signature.asc Description: Digital signature
Bug#721097: base: boot of encrypted LVM with USB inserted, passphrase is not recognized. removing USB stick solves problem.
* wim [Wed Aug 28, 2013 at 07:28:11AM +0900]: Dear Maintainer, * What led up to the situation? boot of system with USB stick present. * What exactly did you do (or not do) that was effective (or ineffective)? remove USB stick * What was the outcome of this action? after USB stick was removed, rebooted normally without problems Please provide output of 'cat /proc/cmdline'. regards, -mika- signature.asc Description: Digital signature
Bug#721088: initramfs-tools: nfsroot with pxelinux fails on systems with multiple NICs
* Martin Mares [Tue Aug 27, 2013 at 10:49:38PM +0200]: When I try to use Debian initramfs to mount root over NFS on a machine with multiple NICs, it never succeeds, because the initramfs configures all NICs with the same IP address. [...] I propose the following fix: In the complex ip parameter case (around line 393 in my version of the scripts/functions file), the DEVICE variable should be checked and if it already set, ipconfig should be run only on the selected device. Also, the NEW_DEVICE logic below that call to ipconfig is likely wrong for the same reason. I think it should be moved to the same place where the BOOTIF check resides. Hm, your approach sounds good to me. If it doesn't break any setups by modifying existing behaviour I'm totaly in favor of it. If you wish, I can provide a patch. That would be definitely appreciated. Thanks for your detailed bug report and willingness to fix it. regards, -mika- signature.asc Description: Digital signature
Bug#718533: linux-image-3.10-1-amd64: conf/modules typo dm-raid45 makes RAID5 arrays unbootable
severity 718533 important retitle 718533 linux-image-3.10-1-amd64 fails to boot with RAID5 thanks * Jesse Molina [Thu Aug 01, 2013 at 04:35:23PM -0700]: I rebooted a system today on linux-image-3.10-1-amd64 and it was unable to boot. linux-image-3.2.0-x-amd64 works fine. A initrd.img-3.2.0-4-amd64 file was generated at the same time the 3.10 one was crated and it boots normally. I don't know what the difference is. Please provide output of 'lsinitramfs /boot/initrd.*' for both the working and the broken initramfs. The problem is that the raid456 module is not being loaded by initramfs. I manually loaded the module with modprobe raid5, assembled by arrays with mdadm, and was able to boot normally. The initramfs file /conf/modules says dm-raid45, but I suspect it should say dm-raid456. [...] This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411172 - unrelated to mdadm and initramfs-tools but being a dmraid issue. I'm tending to reassign this bugreport to mdadm actually. regards, -mika- signature.asc Description: Digital signature
Bug#652459: initramfs-tools: [patch] Please support mounting of /usr in the initramfs
[Cc-ing everyone who was involved in discussing #652459] * Roger Leigh [Sun May 12, 2013 at 06:53:11PM +0100]: And one final patch to use panic rather than sulogin on fsck failure. Thanks for all your patches, I've applied them on top of current master (and edited debian/changelog on my own, being based on your patches). The result is currently sitting in branch mika/bug_652459 of initramfs-tools.git. Does anyone have any objections against the current implementation of #652459 to support mounting of /usr in the initramfs? If so, which objections do you have and what needs to be done to resolve this issue so all involved parties are happy? If there aren't any objections against the current implementation, are there any objections against uploading the current state to experimental? If someone wants to test Roger's implementation, my CI environment provides a Debian package of it: http://jenkins.grml.org/job/initramfs-tools-binaries/26/architecture=amd64/artifact/initramfs-tools_0.114~20130723074828.38_all.deb [md5sum: 7bbd3f70f6483d8506429fa9ace32a0d] regards, -mika- signature.asc Description: Digital signature
Bug#714155: initramfs-tools: mdadm starts up before all needed devices are available
reassign 714155 mdadm thanks * Brian Minton [Wed Jun 26, 2013 at 08:59:06AM -0400]: Package: initramfs-tools Version: 0.113 Severity: normal Dear Maintainer, bminton@bminton:~$ dmesg|grep sde [3.114799] sd 8:0:0:0: [sde] 2930277168 512-byte logical blocks: (1.50 TB/1.36 TiB) [3.115888] sd 8:0:0:0: [sde] Write Protect is off [3.119758] sd 8:0:0:0: [sde] Mode Sense: 00 3a 00 00 [3.119808] sd 8:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.134660] sde: unknown partition table [3.135237] sd 8:0:0:0: [sde] Attached SCSI disk [45018.662644] md: export_rdev(sde) [45018.748222] md: bindsde [45018.772292] disk 2, o:1, dev:sde bminton@bminton:~$ dmesg|grep md1 [2.164616] md: md1 stopped. [2.171754] md/raid:md1: device sdc operational as raid disk 0 [2.172104] md/raid:md1: device sda2 operational as raid disk 1 [2.173021] md/raid:md1: allocated 3282kB [2.173416] md/raid:md1: raid level 5 active with 2 out of 3 devices, algorithm 5 [2.174093] md1: detected capacity change from 0 to 3000603639808 [2.177433] md1: unknown partition table [45018.773937] md: recovery of RAID array md1 Here's some info about my RAID setup: Personalities : [raid6] [raid5] [raid4] md1 : active raid5 sde[3] sdc[0] sda2[1] 2930276992 blocks level 5, 64k chunk, algorithm 5 [3/2] [UU_] [===.] recovery = 19.4% (285554336/1465138496) finish=684.0min speed=28741K/sec unused devices: none /dev/md1: Version : 0.90 Creation Time : Wed Jun 3 09:16:22 2009 Raid Level : raid5 Array Size : 2930276992 (2794.53 GiB 3000.60 GB) Used Dev Size : 1465138496 (1397.26 GiB 1500.30 GB) Raid Devices : 3 Total Devices : 3 Preferred Minor : 1 Persistence : Superblock is persistent Update Time : Wed Jun 19 11:22:09 2013 State : clean, degraded, recovering Active Devices : 2 Working Devices : 3 Failed Devices : 0 Spare Devices : 1 Layout : parity-last Chunk Size : 64K Rebuild Status : 19% complete UUID : bfa46bf0:67d6e997:e473ac2a:9f2b3a7b Events : 0.2609536 Number Major Minor RaidDevice State 0 8 320 active sync /dev/sdc 1 821 active sync /dev/sda2 3 8 642 spare rebuilding /dev/sde [snip package information] I'm not sure what initramfs-tools could do about that, AFAICS it's an issue with mdadm's i-t hook, so reassigning to mdadm. PS: It would be nice to write a few more words about misbehaviour/expected behaviour and not just c/p some logs into a bug report. regards, -mika- signature.asc Description: Digital signature
Bug#712521: initramfs-tools: please add early-initramfs support for ucode update
* Henrique de Moraes Holschuh [Mon Jun 17, 2013 at 06:12:27PM -0300]: On Mon, 17 Jun 2013, Michael Prokop wrote: * Henrique de Moraes Holschuh [Sun Jun 16, 2013 at 03:42:45PM -0300]: Enclosed you will find two patches to add early-initramfs support to initramfs-tools. Thanks! I just applied it after reviewing it together with maks and pushed it to master. Thank you. I have the intel-microcode side ready and tested, do you have any tentative time-frame for the initramfs-tools upload? I'll release and upload a new version today. regards, -mika- signature.asc Description: Digital signature
initramfs-tools 0.113 release
Hi, we just released a new initramfs-tools version (0.113), featuring early initramfs support thanks to Henrique de Moraes Holschuh. More details available in Debian's #712521 issue. Git shortlog attached as usual. regards, -mika- Henrique de Moraes Holschuh (2): implement early initramfs support lsinitramfs(8): document failure to deal with early initramfs Michael Prokop (1): Releasing version 0.113 signature.asc Description: Digital signature
Bug#712521: initramfs-tools: please add early-initramfs support for ucode update
tags 712521 + pending thanks * Henrique de Moraes Holschuh [Sun Jun 16, 2013 at 03:42:45PM -0300]: Enclosed you will find two patches to add early-initramfs support to initramfs-tools. It adds, and properly documents, a hook function that allows packages to _prepend_ data to the main initramfs archive. [...] Please review and comment. If it is OK, please apply. git tree for git merge available upon request. Thanks! I just applied it after reviewing it together with maks and pushed it to master. regards, -mika- signature.asc Description: Digital signature
Bug#710119: initramfs-tools: Installation with dmraid randomly fails to boot
severity 710119 important thanks * Quentin Lefebvre [Tue May 28, 2013 at 05:31:33PM +0200]: Package: initramfs-tools Version: 0.109.1 Severity: grave Dear Maintainer, I found this bug described very well in bug #699437, but as the author of the bug, I strongly believe that the bug is related to initramfs-tools. My RAID controller is a Silicon Image SiI 3112A SATARaid, configured in RAID1. I strongly encourage you to read the previously mentionned bug report. [...] Hm, why didn't you just follow up in #699437 then? Looks like a bug with dmraid and if the maintainer of dmraid thinks it's really a bug in initramfs-tools then he can still reassign the bug accordingly. So I'm actually tending to reassign/merge this bug report with #699437. But I didn't go through all the details yet, so I'm just adjusting the severity for now (doesn't qualify for severity grave AFAICT). regards, -mika- signature.asc Description: Digital signature
Bug#697619: Processed: found 697619 in 0.110
* Adam D. Barratt [Tue Apr 23, 2013 at 09:03:26PM +0100]:
On Mon, 2013-04-22 at 21:36 +, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
found 697619 0.110
Bug #697619 {Done: Ben Hutchings b...@decadent.org.uk} [initramfs-tools]
Many HID drivers not included in initramfs
Marked as found in versions initramfs-tools/0.110 and reopened.
What's the issue with the fix? If we need another upload for i-t for r0
then it'll need to be soon. :-|
We've 0.109.1 which fixes that in wheezy and unstable, shouldn't
this be enough? Is experimental's 0.110 of i-t an issue WRT to r0?
I'd push a 0.111 release to experimental immediately then.
regards,
-mika-
signature.asc
Description: Digital signature
Bug#697619: Processed: found 697619 in 0.110
* Adam D. Barratt [Tue Apr 23, 2013 at 09:20:04PM +0100]: On Tue, 2013-04-23 at 22:17 +0200, Michael Prokop wrote: * Adam D. Barratt [Tue Apr 23, 2013 at 09:03:26PM +0100]: What's the issue with the fix? If we need another upload for i-t for r0 then it'll need to be soon. :-| We've 0.109.1 which fixes that in wheezy and unstable, shouldn't this be enough? Is experimental's 0.110 of i-t an issue WRT to r0? I'd push a 0.111 release to experimental immediately then. Bah, I misread the versions and thought it was affecting the recent upload to sid; sorry for the noise. No worries, I've just released and uploaded i-t v0.111 which includes the fixes which went into wheezy (thanks for that, Ben) to avoid further confusion. regards, -mika- signature.asc Description: Digital signature
Bug#704073: [multipath-tools-boot] error when update-initramfs
reassign 704073 multipath-tools-boot thanks * Ritesh Raj Sarraf [Thu Mar 28, 2013 at 10:58:20AM +0530]: On Wednesday 27 March 2013 10:03 PM, Guy Roussin wrote: I get this error when upgrading from squeeze to wheezy on a boot on san (ibm ds4700) update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 /var/tmp/mkinitramfs_aO0QW9/scripts/init-top/multipath: 5: .: Can't open /scripts/functions I copy and paste /usr/share/initramfs-tools/scripts/functions in /usr/share/initramfs-tools/scripts/init-top/multipath and the error is gone ... I can't see a reason why this would fail. I suspect it to be an initramfs problem. Looks like /usr/share/initramfs-tools/scripts/init-top/multipath is missing the PREREQ/prereqs header (see e.g. initramfs-tools(8)), so set this up (so the script works also outside the initramfs) and *then* use . /scripts/functions. Reassigning back to multipath-tools-boot. regards, -mika- signature.asc Description: Digital signature
Bug#703859: initramfs-tools: initramfs not including the xenblk-front (net, and back) modules, so cannot boot any Debian Xen DomU
severity 703859 important thanks * Stefano Marinelli [Mon Mar 25, 2013 at 12:03:47AM +0100]: initramfs not including the xenblk-front (net, and back) modules, so cannot boot any Debian Xen DomU using the same dom0 kernel. Not having the same problem with an old (some months ago) wheezy install. So you're using initramfs-tools 0.109 with kernel 3.2.0-4-amd64? Which linux-image-amd64 version exactly? And which combination of initramfs-tools and linux-image works for you? Because AFAIK we haven't had any changes in initramfs-tools that could be responsible for a breakage here. regards, -mika- signature.asc Description: Digital signature
Bug#703859: initramfs-tools: initramfs not including the xenblk-front (net, and back) modules, so cannot boot any Debian Xen DomU
* Ben Hutchings [Mon Mar 25, 2013 at 01:57:47PM +]: On Mon, 2013-03-25 at 14:24 +0100, Stefano Marinelli wrote: I investigated some more. After some tests, I found out what happens: * xen-create-image (from the package xen-tools) just takes the dom0 kernel and initram and puts them in the domU config file. * the domU isn't booting as the initram on the dom0 doesn't contain the necessary xen block device modules. modules=most should include, by description, all the ide/ata/scsi block device drivers, but actually it doesn't include the xen ones. [...] I agree that it should include xen-blkfront. I don't know why you mention xen-blkback though. This should already be the case since we have: | copy_modules_dir kernel/drivers/block in-place. What does: lsinitramfs /boot/initrd* | grep xen output for the initrd in question, Stefano? What initramfs-tools version with what config are you using on dom0? regards, -mika- signature.asc Description: Digital signature
Bug#703859: initramfs-tools: initramfs not including the xenblk-front (net, and back) modules, so cannot boot any Debian Xen DomU
* Stefano Marinelli [Mon Mar 25, 2013 at 03:45:02PM +0100]: What does: lsinitramfs /boot/initrd* | grep xen It doesn't show anything at all. Nothing about xen is present on my initramfs. Ok. output for the initrd in question, Stefano? What initramfs-tools version with what config are you using on dom0? The dom0 is a Debian Wheezy amd64 machine, installed (and updated) yesterday. Linux hostname 3.2.0-4-amd64 #1 SMP Debian 3.2.39-2 x86_64 GNU/Linux initramfs-tools is version 0.109, with default configuration (modules=most). update-initramfs -u -v shows: [...] That's strange. Please provide /tmp/log of running: sh -x /usr/sbin/mkinitramfs -o /tmp/initramfs 2/tmp/log (please try to avoid wrapping the log lines in your mail client). regards, -mika- signature.asc Description: Digital signature
Bug#703859: initramfs-tools: initramfs not including the xenblk-front (net, and back) modules, so cannot boot any Debian Xen DomU
* Stefano Marinelli [Mon Mar 25, 2013 at 03:59:46PM +0100]: That's strange. Please provide /tmp/log of running: sh -x /usr/sbin/mkinitramfs -o /tmp/initramfs 2/tmp/log As it's 50 KB, attaching it. Thanks, that looks ok-ish actually. Now what's the output of: lsinitramfs /tmp/initramfs | grep xen ? regards, -mika- signature.asc Description: Digital signature
Bug#703859: initramfs-tools: initramfs not including the xenblk-front (net, and back) modules, so cannot boot any Debian Xen DomU
* Stefano Marinelli [Mon Mar 25, 2013 at 03:59:46PM +0100]:
That's strange. Please provide /tmp/log of running:
sh -x /usr/sbin/mkinitramfs -o /tmp/initramfs 2/tmp/log
[...]
+ for i in '${EXTRA_CONF}'
+ '[' -d /etc/initramfs-tools/conf.d/driver-policy ']'
+ '[' -e /etc/initramfs-tools/conf.d/driver-policy ']'
+ . /etc/initramfs-tools/conf.d/driver-policy
++ MODULES=dep
[...]
As pointed out by Ben (on IRC), you're using MODULES=dep.
regards,
-mika-
signature.asc
Description: Digital signature
Bug#701953: closed by Michael Prokop m...@debian.org (Bug#700572: fixed in initramfs-tools 0.110)
* Touko Korpela [Tue Mar 05, 2013 at 05:23:36PM +0200]: I think that initramfs-tools 0.110 fixes should go to sid/wheezy. Or make kernels in experimental depend on this version or higher. http://lists.alioth.debian.org/pipermail/kernel-svn-changes/2013-March/018772.html regards, -mika- signature.asc Description: Digital signature
Bug#701953: initramfs-tools: Missing modules prevent passphrase entry with usb keyboard
severity 701953 important forcemerge 701953 700572 thanks * Ben Caradoc-Davies [Fri Mar 01, 2013 at 02:04:20PM +0800]: Package: initramfs-tools Version: 0.109 Severity: critical Justification: breaks the whole system You're using a kernel from experimental with a non-standard setup, this definitely doesn't qualify for severity 'critical', adjusting. I have a usb keyboard attached to a system with an unencrypted /boot and a LUKS-encrypted partition (LVM physical volume) containing the other filesystems. Today I installed linux-image-3.8-trunk-amd64 (3.8-1~experimental.1). initramfs-tools created a corresponding initrd, as expected. Booting this kernel/initrd in grub2 resulted in a plymouth passphrase entry screen, but a usb keyboard that did not work in any port. All keyboard lights were off. The system was thus unbootable without a non-usb keyboard (hence critical severity). Without a non-usb keyboard or backup grub entry (3.7 kernel with working initrd), I would have been unable to access my system without rescue media. [...] This is #700572, I'm trying to release an updated package. regards, -mika- signature.asc Description: Digital signature
initramfs-tools 0.110 release
Hi,
we just uploaded initramfs-tools 0.110 to Debian/experimental,
getting rid of deprecated references to '2.6' and making sure the
changes in recent upstream kernel with the nfsv{2,3,4} split and the
new ehci-pci module are adressed.
The shortlog has the details:
Ben Hutchings (2):
Bug#697319: [PATCH 1/2] Remove '2.6.' from initramfs wildcard in bug
script (Closes: #697319)
Remove more references to linux-2.6 in manual page and comments
Michael Prokop (3):
Install nfsv{2,3,4} kernel modules as used by Kernels =3.6
include ehci-pci in auto_add_modules list
Releasing version 0.110
regards,
-mika-
signature.asc
Description: Digital signature
Bug#689336: fixed in initramfs-tools 0.109
* Michael Bell [Tue Oct 09, 2012 at 02:39:43PM +0200]: I just updated from 0.108 to 0.109. The log from aptitude upgrade looks like this: Setting up initramfs-tools (0.109) ... [...] setupcon is missing. Please install the 'console-setup' package. [...] I don't think that the issue is solved. Nobody notices this small warning and still the passphrase prompt uses a wrong keymap. I am not a package maintainer, so just a question: why is it a problem to define console-setup as a real dependency? Initramfs-tools does not work properly from my perspective if the console-setup package is not present. Perhaps the dependency should be placed in the package cryptsetup. Bugreport against cryptsetup is already there: #689722 regards, -mika- signature.asc Description: Digital signature
Bug#689336: closed by Michael Prokop m...@debian.org (Bug#689336: fixed in initramfs-tools 0.109)
* Samuel Hym [Sat Oct 06, 2012 at 09:33:15AM +0200]: At least for the record, I might mention that in my previous configuration without console-setup installed, the configuration was saying KEYMAP=n and still 0.107 was adding the keymap in the initrd. Admittedly this was a strange behaviour, but the upgrading 0.107 to the new 0.109 would have failed just the same. The cryptsetup hook script sets KEYMAP=y regards, -mika- signature.asc Description: Digital signature
Bug#689851: initramfs-tools: Wrong keymap at boot while prompting for the passphrase
* Jean-Luc Coulon (f5ibh) [Sun Oct 07, 2012 at 09:55:54AM +0200]: I've some encrypted filesystems over lvm. After upgrading from 0.107 to 0.108, it refuses my passphrase at boot. I suppose it is related to the keymap. I've reverted to 0.107 at that fixed the problem. I've then upgraded to 0.109 and I've the same problem again. Once again, I've reverted to 0.107 and the probelm is fixed. Please provide output of: update-initramfs -u -k $(uname -r) -v for your system, both for v0.107 and v0.109. regards, -mika- signature.asc Description: Digital signature
Bug#689851: initramfs-tools: Wrong keymap at boot while prompting for the passphrase
[Cc-ing Anton as being maintainer of setupcon] * Jean-Luc Coulon [Mon Oct 08, 2012 at 01:50:31PM +0200]: Le 08/10/2012 08:15, Michael Prokop a écrit : Please provide output of: update-initramfs -u -k $(uname -r) -v Output attached [...] Calling hook keymap Adding binary /bin/loadkeys Adding library /lib/libcfont.so.0 Adding library /lib/libctutils.so.0 Adding library /lib/libconsole.so.0 WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger WARNING: Unknown X keysym XF86Messenger [...] This looks like the culprit. Anton, what do you think about this issue? regards, -mika- signature.asc Description: Digital signature
initramfs-tools 0.109 release
Hi, the initramfs-tools 0.109 release addresses #689336 to provide a check for loadkeys/setupcon and inform the user if KEYMAP=y is set (as done by crypsetup, see #689722) but one of the tools is missing. git shortlog: Michael Prokop (2): keymap hook: provide warning message if loadkeys/setupcon are not available Releasing version 0.109 regards, -mika- signature.asc Description: Digital signature
Bug#689336: initramfs-tools 0.108 cannot decrypt dm_crypt filesystems
* Samuel Hym [Mon Oct 01, 2012 at 06:41:10PM +0200]: My disk is dm_crypted. After upgrading from 0.107 to 0.108, my system could not boot anymore with the newly generated ramfs: entering the passphrase did not unlock the disk, yielding the same error message as a wrong passphrase. Downgrading to 0.107 solved the problem. [...] What version of cryptsetup are you using? Is there any visible difference between running update-initramfs -u -v for 0.107 and 0.108? What about differences between the generated initramfs (check e.g. with lsinitramfs /boot/initrd.img-$(uname -r))? Does setting KEYMAP=y in /etc/initramfs-tools/initramfs.conf help? regards, -mika- signature.asc Description: Digital signature
Bug#619711: console-setup: breaks copying keymap to initramfs
Hi! * Anton Zinoviev [Sat Sep 15, 2012 at 02:44:05PM +0300]: On Thu, Sep 13, 2012 at 05:33:50PM +0200, Ralf Jung wrote: is there any progress on this one? This recently bit me quite hard when I installed a system with full-disk encryption, using a password which required the correct keyboard layout to be entered. As far as I can understand, this bug can be fixed in two ways - by code provided by console-setup, or by code provided by initramfs-tools. [...] I just uploaded initramfs-tools v0.108 which fixes this issue. I'll try to get a release exception for it once it has been hanging in unstable for a few days without any known problems so it can make its way into Debian/wheezy. Anton, while working on this issue I noticed that setupcon doesn't always return an according error code. Example: http://michael-prokop.at/screeni/gkrellShoot_12-09-21_112226.png Could you please take care of that? regards, -mika- signature.asc Description: Digital signature
initramfs-tools 0.108 release
Hi, on behalf of the initramfs-tools developers I'm announcing a new release, which most importantly fixes a keymap issue (see bug report http://bugs.debian.org/619711 for details). , [ git shortlog ] | Michael Prokop (2): | Use setupcon to install system's keymap | Releasing version 0.108 | | Petr Baudis (1): | initramfs-tools: allow disabling initrd for make deb-pkg | | maximilian attems (2): | hook-functions: add hid-generic module | debian/control: Scratch 2.6 mention ` regards, -mika- signature.asc Description: Digital signature
Bug#685109: initramfs-tools: wrong executable name (update-initramfs)
* Malte Dik [Thu Aug 16, 2012 at 11:21:46PM +0200]: initramfs-tools failed to configure in postinst stage because /usr/sbin/update-initramfs was not found. There is, however, a executable /usr/sbin/update-initramfs.initramfs-tools. [...] This looks like the bug from live-tools: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684423 This is not an initramfs-tools problem therefore as noted by Bastian 'waldi' Blank already. regards, -mika- signature.asc Description: Digital signature
Bug#679571: modprobe: no module unix found in modules.dep
* Zack Weinberg [Fri Jun 29, 2012 at 01:35:04PM -0700]: No matter how I configure the initramfs, I always get the warning message modprobe: no module unix found in modules.dep on boot. [...] This is #654282 (package udev) regards, -mika- signature.asc Description: Digital signature
Bug#676486: mkinitramfs: Error: missing parameters. See -h.
tags 676486 + pending merge 676439 676486 thanks * Jakub Wilk [Thu Jun 07, 2012 at 11:41:46AM +0200]: If I run update-initramfs, it prints an error message about missing parameters: # update-initramfs -u -k 3.3.0-trunk-amd64 update-initramfs: Generating /boot/initrd.img-3.3.0-trunk-amd64 Error: missing parameters. See -h. [...] This seems to be #676439, upload will follow soon. regards, -mika- signature.asc Description: Digital signature
Bug#662766: update-initramfs: does not find modules xhci ext4dev zfcp dasd_* on 3.2.0-1-amd64
* mazkagaz [Tue Mar 06, 2012 at 10:31:00AM +0100]: I did a system update/upgrade and noticed a problem while updating the initrd. So i tried to reproduce the problem by calling : update-initramfs -u That is what i got : [...] WARNING: could not open /var/tmp/mkinitramfs_QGQyan/lib/modules/3.2.0-1-amd64/modules.builtin: No such file or directory [...] This is already reported and pending: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659866 Please check existing bug reports before reporting a new one. regards, -mika- signature.asc Description: Digital signature
initramfs-tools 0.101 release
Hi, we just released a new version of initramfs-tools, most important is Ben's fix regarding the modules.builtin file, full shortlog is attached. regards, -mika- - git shortlog: Ben Hutchings (1): mkinitramfs: Copy modules.builtin into initramfs Michael Prokop (2): Bump Standards-Version to 3.9.3 Releasing version 0.101 Vadim Solomin (1): initramfs-tools: Add per default missing hid-logitech-dj maximilian attems (3): hook-functions: ext4dev is gone debian/control: Get rid of old findutils versioned depends update-initramfs: Don't call flash-kernel directly - signature.asc Description: Digital signature
Bug#662664: Messages NOT spurious!
* David Baron [Tue Mar 06, 2012 at 03:57:55PM +0200]: Note that this is duplicate so merge! The initrd's built are not bootable. I get very early: tso timesource waiting for root file system... Get to further. Other post cite more missing files running update-initramfs. Please test initramfs-tools 0.101 avilable from Debian/unstable. regards, -mika- signature.asc Description: Digital signature
Bug#662612: initramfs-tools: could not open /var/tmp/mkinitramfs_lbieCP/lib/modules/3.2.0-1-amd64/modules.builtin
* Christoph Anton Mitterer [Mon Mar 05, 2012 at 11:38:50AM +0100]: Since today's updates I get this: update-initramfs: Generating /boot/initrd.img-3.2.0-1-amd64 W: mdadm: /etc/mdadm/mdadm.conf defines no arrays. W: mdadm: no arrays defined in configuration file. WARNING: could not open /var/tmp/mkinitramfs_lbieCP/lib/modules/3.2.0-1-amd64/modules.builtin: No such file or directory But the only potentially related packages would be: linux-libc-dev (doubt that) ntfs-3g Duplicated of #659866, patch is sitting in bwh/mit branch. regards, -mika- signature.asc Description: Digital signature
Bug#659948: [initramfs-tools] Fails to upgrade (Sid)
* David Baron [Wed Feb 15, 2012 at 10:49:53AM +0200]: --- Please enter the report below this line. --- On attempted upgrade From which initramfs-tools version are you upgrading? update-initramfs: deferring update (trigger activated) Processing triggers for initramfs-tools ... update-initramfs: Generating /boot/initrd.img-3.2.0-1-686-pae /rootfs: No such file or directory mkinitramfs: for root /rootfs missing /rootfs /sys/block/ entry mkinitramfs: workaround is MODULES=most mkinitramfs: Error please report the bug update-initramfs: failed for /boot/initrd.img-3.2.0-1-686-pae with 1. dpkg: error processing initramfs-tools (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports Errors were encountered while processing: initramfs-tools Did you recently switch to the usage of root=UUID=df24bea0-5520-4281-b053-021bd5a96628 or did you use the very same kernel command line also with the older version of initramfs-tools? -- /etc/initramfs-tools/initramfs.conf MODULES=dep Same question for MODULES=dep (and as noted in the error message switching to MODULES=most will work around your issue). Please also provide output of 'mount' of your system. regards, -mika- signature.asc Description: Digital signature
Bug#659948: [initramfs-tools] Fails to upgrade (Sid)
* David Baron [Wed Feb 15, 2012 at 12:23:47PM +0200]: On Wednesday 15 February 2012 11:40:02 Michael Prokop wrote: Please also provide output of 'mount' of your system. :~$ mount [...] rootfs on / type rootfs (rw) Please provide your /etc/fstab How did you set up your system? debian-installer? regards, -mika- signature.asc Description: Digital signature
initramfs-tools 0.100 release
Hi, we just released initramfs-tools v0.100, with a bunch of bugfixes. The shortlog at the end of this mail has the details, find the git stuff at the usual place: * Git repository: git://git.debian.org/kernel/initramfs-tools.git * Git web: http://git.debian.org/?p=kernel/initramfs-tools.git;a=summary regards, -mika- Git shortlog: Alkis Georgopoulos (1): configure_networking() wait for udev to populate available nics Colin Watson (1): mark Multi-Arch: foreign Harald Hoyer (1): MODULES=dep: awk free version for root dev search Martin Pitt (1): hooks/busybox: Fix 2.99 busybox breakage Michael Prokop (5): lsinitramfs: support xz/lzma, bzip2 and lzop as compress methods. set_initlist: redirect warning messages to stderr. Alternate Recommends on busybox-static warn user if directory is present in confdir Releasing version 0.100 Sven Joachim (1): copy_exec: Handle optimized libraries under multiarch paths Timo Juhani Lindfors (2): panic(): print the name of each module before loading it panic: Load modules for highly probable USB keyboard maximilian attems (13): manual_add_modules: No longer add firmware.agent too. mkinitramfs: Use version comparison for xz or other compression tools initramfs-tools: rephrase description mkinitramfs: Check if TMPDIR is writable mkinitramfs: Use /var/tmp rather then /tmp for space reasons Revert Revert mkinitramfs: Nuke MIN_VERSION handling. MODULES=dep: Use /sys again to decide for libata or ide debian/control: Drop versioned depend on pre-Etch udev version debian/control: Tighten dep on klibc-utils 1.5.23-2 init: Prepare for switch_root(8) usage update-initramfs: Cleanup nowadays unused run_lilo() update-initramfs: run_bootloader() hooks on create too preinst: get rid of awk usage signature.asc Description: Digital signature
Bug#649399: initramfs-tools: please mark Multi-Arch: foreign
* Ben Hutchings [Sat Feb 11, 2012 at 07:13:10PM +]: On Sun, 2011-11-20 at 17:41 +, Colin Watson wrote: It would be useful for initramfs-tools to be marked Multi-Arch: foreign, to indicate that it can satisfy dependencies of packages of other architectures. Although Debian's dpkg doesn't yet do anything special with this, it's safe to add this tag in advance of package manager support. In Ubuntu, this is an early step in being able to crossgrade from i386 to amd64, because we don't have an -amd64 kernel flavour on i386 and (of course) our kernel packages depend on initramfs-tools. While Debian does have an -amd64 flavour on i386, it still wouldn't hurt to add this tag. [...] This is also relevant to Debian now. Max, please apply this patch. Colin's patch is already applied on our i-t.git, I'll upload a new i-t release in the next few days. regards, -mika- signature.asc Description: Digital signature
Bug#619711: console-setup: breaks copying keymap to initramfs
* maximilian attems [Die Apr 05, 2011 at 11:00:49 +0200]: On Tue, 29 Mar 2011, Anton Zinoviev wrote: [...] It will be difficult for initramfs-tools to tell what is the correct name of the cached keymap. Symlinking the new name to the old is unreliable so I'd prefer not to implement this. Because of this in version 1.72 of console-setup a new option of setupcon is implemented --save-keyboard. Suppose you want to save the keymap in /tmp/initrd/etc/console-setup/cached.kmap.gz. Then simply use the following command: setupcon --save-keyboard /tmp/initrd/etc/console-setup/cached.kmap.gz Alternatively, instead of --save-keyboard you can use --setup-dir. I will explain this second option in a separate bug report. Both new options of setupcon are for now undocumented because I want to know first that they will be useful. I'd prerfer that console-setup would ship an proper initramfs hook telling what to add to initramfs, will followup on the other report on that soonest. So, how could we resolve this issue? Anton, is there any chance you could provide an initramfs hook which takes care of that? (The advantage of this approach would be that the hook can use features of console-setup according to its version and you'd have full control over it.) regards, -mika- signature.asc Description: Digital signature
Bug#633582: initramfs-tools: All files in initrd owned by root
* Mandos Maintainers [Die Jul 12, 2011 at 12:16:39 +0200]: Converted patch to Git format; it is attached. Thanks! [...] maximilian: i've scheduled the patch for inclusion via mika/user_permissions. regards, -mika- signature.asc Description: Digital signature
Bug#636495: initramfs-tools: installs optimized libraries into the initramfs
* Sven Joachim [Fre Aug 05, 2011 at 01:24:46 +0200]: On 2011-08-03 14:16 +0200, Sven Joachim wrote: My initramfs contains a libc6 that is optimized for i686: [...] Attached is a patch against git master that works for me: Thanks, Sven! I've scheduled the patch for review and inclusion in branch mika/optimized_lib_under_multiarch regards, -mika- signature.asc Description: Digital signature
Bug#409271: Same to me
[Adding Jan-Marek to Cc] * Denny Schierz [Fri Mar 11, 2011 at 11:29:51AM +0100]: we have the same problem. We need the security features form NFSv4 for our diskless clients. I build the initramfs under Squeeze but it seems, that it isn't working, if I tell Solaris to support only NFSv4. So, how can I get the NFSv4 working ? I'd like to see this issue resolved. Jan-Marek, IIRC the company you're working for has some patches addressing this issue. Is there any chance that you could share them with us so we could provide official support for NFSv4 within initramfs-tools? regards, -mika- signature.asc Description: Digital signature
Bug#565225: Resume device should be detected when creating initramfs, or not at all
* Sebastian Leske [Mon Nov 29, 2010 at 01:38:21 +0100]: I got bitten by this bug as well, similarly to Michael Conner above: I installed uswsusp to be able to hibernate/resume. s2disk worked flawlessly, but on booting the system simply did not bother to resume, booting normally instead. My analysis: After digging through the initramfs scripts, I discovered that this is because on booting resume is only triggered if $resume is set. As far as I understand, the initramfs takes $resume from the kernel command line (if set), and from /etc/initramfs-tools/conf.d/resume otherwise. In my case /etc/initramfs-tools/conf.d/resume did not exist. It should have been created by the preinst of initramfs-tools; however the preinst ( /var/lib/dpkg/info/initramfs-tools.preinst ) uses vol_id: [...] This will always fail, because vol_id is no longer part of Debian (it was removed from udev for version 146-1, see /usr/share/doc/udev/changelog.Debian.gz ). This is no longer true for current versions of initramfs-tools, JFYI. In summary: * Resume from hibernation will only work if /etc/initramfs-tools/conf.d/resume sets RESUME * However, there is no (working) code to write /etc/initramfs-tools/conf.d/resume, and no documentation explaining that it needs to be set manually to make resume work Thus, resume will probably fail to work in most cases. I believe there are actually several bugs here: 1) The code in the preinst of initramfs-tools to detect the swap partition does not work, because it uses vol_id. Fixed nowadays. 2) Even if 1) were fixed, there may be cases where the swap partition is incorrectly detected at installation time, or later changes. So fixing preinst is not enough. I agree with bug submitter jidanni that the swap partition should be detected when building the initramfs, not during preinst. 3) Additionally, I don't quite understand why uswsusp refuses to resume if $resume is not set (in /usr/share/initramfs-tools/scripts/local-premount/uswsusp ). The script does not actually use the value of $resume, it just aborts if it is not set :-(. I guess this could be considered a bug in uswsusp; I can report it against uswsusp if discussion of this bug indicates that this makes sense. To fix this, I would propose the following: * Drop the code in initramfs-tools.preinst which tries to write RESUME to /etc/initramfs-tools/conf.d/resume , which does not work anyway. Sounds reasonable too me. maximilian, what do you think of it? * Document (e.g. in /usr/share/doc/initramfs-tools/README.Debian ) that /etc/initramfs-tools/conf.d/resume can be used to set the resume device. * When building the initramfs, use the value from /etc/initramfs-tools/conf.d/resume if it exists; otherwise try to find it yourself: - if /etc/uswsusp.conf exists, it probably makes sense to read it (resume device =) - otherwise grab the current swap device (the config script from uswsusp already has code for that) This is still problematic if there is 1 swap device. Even better probably would be to use debconf to prompt for the resume device, if this is practical... I am willing to help implement / test this, but first I'll wait for some feedback if I'm even on the right track :-). Sorry that no one seemed to care about it for so long. What could be a proper way to resolve that nowadays, taking uswsusp, hibernate,... into account? dracut has some code in modules.d/95resume/. IMHO we should find a way which avoids duplicated code. Related bug reports: http://bugs.debian.org/574653 https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/50437 regards, -mika- signature.asc Description: Digital signature
Bug#597581: update-initramfs should not set PATH
tags 597581 + pending
thanks
* Ian Jackson [Die Sep 21, 2010 at 12:25:28 +0100]:
I've been doing some exciting initramfs hacking and I found that my
hook scripts were not working because although I call update-initramfs
with /usr/local/{sbin,bin} on my path, they were being removed.
$ dpkg -L initramfs-tools | xargs grep PATH
/usr/sbin/mkinitramfs:export PATH='/usr/bin:/sbin:/bin'
...
I don't think this is correct. It seems to have been introduced in
response to #409995, which was a complaint that (in effect) /sbin
could be missing from the path.
The correct approach would be to add /usr/sbin and /sbin to the end of
PATH, something like this:
export PATH=${PATH-/usr/local/bin:/bin:/usr/bin}:/sbin:/usr/sbin
I'm sorry that no one seemed to care about this bug for so long.
AFAICS your fix is sitting in branch maks/path of
initramfs-tools.git, so marking this bug as pending, since it's
scheduled for review and inclusion for the upcoming release.
regards,
-mika-
signature.asc
Description: Digital signature
Bug#601324: initramfs-tools: PREREQ only honored inside single directory
tags 601324 + pending thanks * Marc Haber [Mon Okt 25, 2010 at 10:17:18 +0200]: Package: initramfs-tools Version: 0.98.5 Severity: normal Hi, at least for hook scripts, PREREQ is only honored in /etc/initramfs-tools resp /usr/share/initramfs-tools. First all scripts in /usr/share/initramfs-tools are ordered according to their PREREQ values and executed, then all scripts in /etc/initramfs-tools are ordered according to _their_ PREREQ values and executed. There is no possibility to have a local script executed before one from the package. This is at least surprising. I'm sorry that no one seemed to care about this issue for so long. Does: http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=commit;h=9e961c66b894b8779f13ceafdc58d7de8dd70756 solve the issue for you? Thanks for reporting. regards, -mika- signature.asc Description: Digital signature
Bug#620814: initramfs-tools: fails to include essential module for other leg of md0
* Arno Schuring [Mit Apr 06, 2011 at 01:00:23 +0200]: Thusly spoke maximilian attems (m...@debian.org on 2011-04-05 06:44 +): [...] As you noticed the file is unowned and can be removed and the initramfs regenerated. Nevertheless your fail in MODULES=dep is interesting and didn't have time yet to properly read this corresponding bug. Since I had already spent so much time reading into the source, I spent another hour yesterday to rewrite hook-functions to my liking. Patch attached. It basically replaces the entire sysfs-from-dev divination with a walker that uses sysfs' slave links to reach the underlying device, collecting modules along the way. Please treat this as an FYI, not a push. The exercise is academic anyway, since this is not in any way a resource-constrained device. I'm not comfortable signing off on this code, because a) I simply can't test and have no experience with block devices other than lvm, md and plain partitions. b) the code assumes a lot about sysfs that I have not been able to support with documentation: - there appears to be no guarantee about the existence of a block device at all (maybe it's driver-dependent?) - no guarantee about whether following slaves/ in /block/ will always reach an endpoint under /devices/ - Never depend on the device-link is mentioned explicitly in the document, but there appears to be no other way to reach driver/ from /block/ (?). It also explicitly says Accessing /sys/class/net/eth0/device is a bug in the application c) initramfs is not exactly the place where you can afford to be naive without consequence That said, this code WorksForMe(tm), I've tried very hard not to break any old code paths. It can't replace the existing code anyway because it relies on udev, which is non-essential. I think sys_walk_device might be useful though. Oh, and there's several indentation violations to avoid huge whitespace-only changes. Like I said, it's not a submission. So, maximilian (and other kernel devs reading this) - how do we plan to proceed with this issue? a) Align/integrate this patch? b) Further investigate? c) Mark won't fix? d) ...? Please comment. :) regards, -mika- signature.asc Description: Digital signature
Bug#621375: backup_initramfs=yes
* maximilian attems [Sam Apr 09, 2011 at 09:55:57 +0200]: On Wed, 06 Apr 2011, Joey Hess wrote: I recently suffered 2 weeks of downtime of a machine in a location that made fixing it hard, caused by a broken initramfs due to bug #621137. This highlighted to me that there are many things that can go wrong and break an initramfs when it is refreshed, not just when upgrading to a new kernel. And yet backup initramfses are not kept by default, except for ones that accompany old kernel versions. it was an Ubuntu merge, as initramfs-tools initramfs were considered stable, one could think to have this set for sid/testing until freeze. Space should not be a concern, since /boot is always provisioned with space for multiple kernel and initramfs pairs. So I feel that setting backup_initramfs=yes would be better than the current default, leading to more robust and recoverable systems. Thank you. the -ENOSPC error accounts for 50% of the Ubuntu bugs. I do agree that it is not an initramfs-tools bug per se, but of the invovled apt that do not cleanup a huge number of linux-images that heppen due to their easy ABI bump. Nevertheless due to the triggering the error happens very late and kills the box. (Not even starting to account for seperate /boot partitions) maximilian, how do we proceed with this issue? regards, -mika- signature.asc Description: Digital signature
Bug#644850: linux-image-2.6.32-5-kirkwood: 2.6.32-38 does not recognise USB harddisks any longer
* Dominique Lenoir [Mon Oct 24, 2011 at 07:51:23PM -0400]: Same problem here, My outputs were similar to Joerg's. I reflashed the kernel (twice), but still have the two errors, and my USB drive is not recognized. Can you please report what's the output of: # flash-kernel --supported # echo $? on your system(s)? regards, -mika- signature.asc Description: Digital signature
Bug#639902: Alternate Recommends on busybox-static
* maximilian attems [Mit Aug 31, 2011 at 02:34:31 +]: On Wed, Aug 31, 2011 at 03:58:27PM +0200, Moritz Muehlenhoff wrote: We're including attached patch in Univention Corporate Server, a Debian derived Distribution based on Stable. happy to do so if newer busybox no longer spits at one face on invocation aka if that is resolved: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=454665#17 your testing is appreciated. If Moritz/Univention is using busybox-static I'd say it's working as opposed, no? :) I've scheduled this patch in branch mika/busybox-static for inclusion. Please comment. regards, -mika- signature.asc Description: Digital signature
Bug#509077: initramfs-tools: support alternate DHCP port and DHCP vendor-class-identifier
* Vagrant Cascadian [Son Jun 20, 2010 at 07:11:41 -0700]: On Sat, Jun 19, 2010 at 06:43:16PM +0200, maximilian attems wrote: On Tue, 08 Jun 2010, Michael Prokop wrote: * Vagrant Cascadian vagrant+debianb...@freegeek.org [Mit Dez 17, 2008 at 07:01:51 -0800]: please consider the attached patch, which adds boot prompt parameters for two of ipconfig's commandline options in the configure_networking function: - using an alternate DHCP port (dhcpport=NNN, ipconfig -p NNN) - specifying the vendor-class-identifier (dhcpvci=XXX, ipconfig -i XXX) [...] understandable. perhaps it would be better to rewrite in such a way that ipconfig could be passed arbitrary arguments? of course, if it ever switched away from ipconfig to some other dhcp client, it'd be nice to not have to change syntax or configuration names... I do not see so much the point of setting ipconfig vendor class id. why would that be needed for booting? in order to distinguish a machine that's doing network boot for debian-installer, LTSP or PXE. for example, in each case, you might want to hand it a different dhcp filename option. pxe should get pxelinux.0, d-i gets a preseeding URL, and ltsp could get a configuration file... the alternate DHCP port looks indeed more interesting, but no idea how common that is in the wild? i don't know that it's incredibly common, but is not infrequently asked for in LTSP environments, though there are other alternatives using dnsmasq's dhcp proxy support now, so it's maybe less important. and if there is not a place in the ip= monster bootparam? don't believe so. Hm, so again no one took care of that for another period of time. I'm sorry, Vagrant. :( This patch is non-intrusive, but I'd still vote for non-inclusion as of today since it depends on ipconfig and not too much people seem to really care about it. If someone still thinks it should be included please stand up. maximilian, please comment. regards, -mika- signature.asc Description: Digital signature
Bug#610462: update-initramfs: failed for /boot/initrd.img-2.6.32-5-686 (errorcode 127)
tags 610462 + pending tags 610462 + patch thanks * Steff [Thu Jan 20, 2011 at 05:27:39PM +0100]: Sorry, the mail below bounced from Mika's mail, but not from 610...@bugs.debian.org, so I assumed you had had it. Sorry again for wasting your time, and thanks again for the help. [...] Found the culprit, between the chair and the keyboard as usual. I backup my config files using rcs. removing the RCS folder mentioned below makes everything run smooth again. Thanks both for the quick help, and sorry for the burden. [...] Even though this is kind of EBKAC (thanks to Steff for the debugging output) I'd like to make sure a user is notified about such a situation. Therefore I just prepared a branch addressing this issue for review and inclusion: http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=shortlog;h=refs/heads/mika/test_for_directory Feedback welcome. regards, -mika- signature.asc Description: Digital signature
Bug#649399: initramfs-tools: please mark Multi-Arch: foreign
Hi Colin, * Colin Watson [Sun Nov 20, 2011 at 05:41:09PM +]: It would be useful for initramfs-tools to be marked Multi-Arch: foreign, to indicate that it can satisfy dependencies of packages of other architectures. Although Debian's dpkg doesn't yet do anything special with this, it's safe to add this tag in advance of package manager support. [...] I've added it to the mika/multi_arch_foreign branch in initramfs-tools.git so it's scheduled for review and inclusion in the upcoming initramfs-tools release. Thanks for your patch! regards, -mika- signature.asc Description: Digital signature
Bug#638479: kernel-handbook: please consider providing a Vcs-Git header
Package: kernel-handbook Version: 1.0.11 Severity: minor kernel-handbook provides a working Vcs-Browser header already and git://anonscm.debian.org/kernel-handbook/kernel-handbook.git seems to work for public git access, would be nice if your package could provide the according Vcs-Git header. regards, -mika- -- 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/2011-08-19t16-53...@devnull.michael-prokop.at
Bug#601319: initramfs-tools: existing foo~ causes foo to be ignored
* Marc Haber [Mon Okt 25, 2010 at 09:48:55 +0200]: at least in /etc/initramfs-tools/hooks, existence of a foo~ file causes foo (the version without the tilde) to be ignored. If that's a feature, it needs to be documented, and update-initramfs -v output should more prominently reflect this. This is clearly not the expected behaviour, I've just commited a bugfix into our git which is supposed to fix your issue: http://git.debian.org/?p=kernel/initramfs-tools.git;a=commit;h=ee16a4ebfa07b5579519039cbc6e48d3a5494a6e Thanks for reporting, regards, -mika- signature.asc Description: Digital signature
Bug#615839: initramfs-tools: Kernel panic - not syncing: No init found
Hi :) * Fladischer Michael fladischermich...@fladi.at [Mon Feb 28, 2011 at 02:28:25PM +0100]: I'm affected by this too. Though it seems to be unrelated to the Linux kernel package itself as after an update-initramfs -k all -u all the other initrd files for the older kernels were also showing the same problem after a reboot. I managed to fix this by building the initrd from within a grml-2010.12 live CD (using their version of initramfs-tools). So I guess it is related to initramfs-tools. If anyone needs more information to investigate this I'm happy to assist. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 3.9M Feb 28 12:21 /boot/initrd.img-2.6.37-1-amd64 -rw-r--r-- 1 root root 18M Feb 28 12:09 /boot/initrd.img-2.6.37-1-amd64.working Hm, Grml 2010.12 shipped initramfs-tools 0.98.7. The /boot/initrd.img-2.6.37-1-amd64 was build using initramfs-tools 0.98.8? Building it with initramfs-tools 0.98.7 fixes your problem? Can you please provide the output of lsinitramfs for /boot/initrd.img-2.6.37-1-amd64 and /boot/initrd.img-2.6.37-1-amd64.working? regards, -mika- signature.asc Description: Digital signature
Bug#611555: initramfs-tools: Modules needed for btrfs not included in initramfs
* Julian Andres Klode j...@debian.org [Sun Jan 30, 2011 at 06:22:31PM +0100]: Version: 0.98.8 The btrfs module depends on libcrc32c which requires a crc32c provider like crc32c, but does not specify it in depends; and the module is thus not included. The result is that if you choose to install with / formatted as btrfs, the installation is not able to boot. A possible solution is to include the crc32c module whenever a module requests libcrc32c. Since you're reporting against version 0.98.8: | initramfs-tools (0.98.8) unstable; urgency=high | [...] | * [78d9e04] initramfs-tools: Handle hidden dependency of libcrc32c on | crc32c. (Closes: #608538) This is supposed to provide exactly what you're asking for. What am I missing? regards, -mika- signature.asc Description: Digital signature
Bug#610462: update-initramfs: failed for /boot/initrd.img-2.6.32-5-686 (errorcode 127)
* steff steff.hel...@gmail.com [Tue Jan 18, 2011 at 09:22:20PM +0100]: ~ $ update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.32-5-686 update-initramfs: failed for /boot/initrd.img-2.6.32-5-686 What does 'sh -x /usr/sbin/mkinitramfs -o /tmp/foo' display? regards, -mika- signature.asc Description: Digital signature
Bug#608538: btrfs root installation results in initramfs busybox prompt
* Ben Hutchings b...@decadent.org.uk [Mon Jan 03, 2011 at 09:03:37PM +]: On Mon, 2011-01-03 at 16:37 -0400, Joey Hess wrote: I hope this can be dealt with, it seems to be the only remaining issue in getting Debian to support btrfs root filesystems. This is easily reproducible, I installed from a recent daily build netinst, put /boot on ext3 and / on btrfs and same problem on boot. The problem is that btrfs depends on libcrc32c, which demand loads any of several crc32c implementations, depending on hardware. Those modules are not declared as dependencies, so initramfs-tools does not include them. So, another way to see the same problem: r...@gnu:/lib/modules/2.6.32-5-686/kernel/cryptomv crc32c.ko ~ r...@gnu:/lib/modules/2.6.32-5-686/kernel/cryptoinsmod ../lib/libcrc32c.ko insmod: error inserting '../lib/libcrc32c.ko': -1 Unknown symbol in module r...@gnu:/lib/modules/2.6.32-5-686/kernel/cryptomv ~/crc32c.ko . r...@gnu:/lib/modules/2.6.32-5-686/kernel/cryptoinsmod ../lib/libcrc32c.ko r...@gnu:/lib/modules/2.6.32-5-686/kernel/crypto So, at least a workaround would be for the initramfs to have crc32c added to it whenever libcrc32c is. Attached patch just adds it to the base modules list; since btrfs is already there that seems like an ok quick fix. This is stupid. Without a declared module dependency, a MODULES=dep configuration will remain broken. I think this needs to be fixed in the kernel instead. Note that it would probably be better to try first loading hardware optimised versions like crc32c-intel, and only load crc32c if they fail to load. I believe that happens automatically, as the hardware-optimised modules provide an alias of 'crc32c'. (BTW, this bug probably also breaks netbooting with certian ethernet cards whose drivers also use libcrc32c.) Right. Thanks for showing up, would be nice to see this fixed. I just want to make sure you're aware of my bugreport #602254 (which Joey seemed to have noticed already according to its BTS history). Ben, do you think this could be fixed at the kernel side? regards, -mika- signature.asc Description: Digital signature
Bug#608538: btrfs root installation results in initramfs busybox prompt
* Ben Hutchings b...@decadent.org.uk [Mon Jan 03, 2011 at 09:50:46PM +]: On Mon, 2011-01-03 at 22:16 +0100, Michael Prokop wrote: * Ben Hutchings b...@decadent.org.uk [Mon Jan 03, 2011 at 09:03:37PM +]: On Mon, 2011-01-03 at 16:37 -0400, Joey Hess wrote: So, at least a workaround would be for the initramfs to have crc32c added to it whenever libcrc32c is. Attached patch just adds it to the base modules list; since btrfs is already there that seems like an ok quick fix. This is stupid. Without a declared module dependency, a MODULES=dep configuration will remain broken. I think this needs to be fixed in the kernel instead. Note that it would probably be better to try first loading hardware optimised versions like crc32c-intel, and only load crc32c if they fail to load. I believe that happens automatically, as the hardware-optimised modules provide an alias of 'crc32c'. (BTW, this bug probably also breaks netbooting with certian ethernet cards whose drivers also use libcrc32c.) Right. Thanks for showing up, would be nice to see this fixed. I just want to make sure you're aware of my bugreport #602254 (which Joey seemed to have noticed already according to its BTS history). Ben, do you think this could be fixed at the kernel side? Eventually, yes, but unfortunately it turns out that we can't fix it immediately. 'depmod' only looks at symbol dependencies; there is no way for modules to declare explicit dependencies through module information. We can bodge it by exporting a specific symbol from crc32c and referring to that from libcrc32c, but since the optimised version doesn't satisfy that dependency it will not be loaded. Ok, that's what I expected. So I'm afraid this will have to be worked around in initramfs-tools for now: whenever you add libcrc32c, add crc32c as well (no matter how libcrc32c was selected). So we should just add crc32c-intel, libcrc32c and crc32c by default via initramfs-tools for now, ACK? Thanks. regards, -mika- signature.asc Description: Digital signature
Bug#608138: initramfs-tools: NMI error on boot only in recovery mode
reassign 608138 linux-2.6 thanks * Cesare Leonardi celeo...@gmail.com [Mon Dec 27, 2010 at 09:36:44PM +0100]: Every time i boot in recovery mode, i see this message: - Loading Linux 2.6.37-rc5-686 ... Loading initial ramdisk ... [0.020165] NMI watchdog failed to create perf event on cpu0: ffa1 Loading, please wait... resume: libgcrypt version: 1.4.5 INIT: version 2.88 booting - No error with normal boot. It happen with both 2.6.37-rc7-686, 2.6.37-rc5-686, 2.6.36-trunk-686, but not with 2.6.32-5-686 (2.6.32-29). Grub command lines are identical except that lapic hpet=force in normal boot is substituted by single in recovery mode. Apart for the message, the system seems to behave well. This is not an initramfs-tools issue. Re-assigning to linux-2.6 and leaving it to the kernel maintainers how to proceed with this issue (see #599368 for similar issue). regards, -mika- signature.asc Description: Digital signature
