Bug#636697: initramfs-tools: no way to include library modules for libraries installed in multiarch path
* Joachim Selinger [Fri May 31, 2013 at 10:25:17PM +0200]: [...] run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-4-amd64 /boot/vmlinuz-3.2.0-4-amd64 update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 E: /usr/share/initramfs-tools/hooks/pcidetect failed with return 1. [...] Well, I'm not aware of a file /usr/share/initramfs-tools/hooks/pcidetect shipped by Debian. What does 'dpkg -S /usr/share/initramfs-tools/hooks/pcidetect' return? regards, -mika- signature.asc Description: Digital signature
Bug#636697: initramfs-tools: no way to include library modules for libraries installed in multiarch path
Package: initramfs-tools Version: 0.109.1 Followup-For: Bug #636697 Dear Maintainer, I ran into a problem with wheezy. * What led up to the situation? Updating from squeeze to wheezy in the running system was successfull except for the error as given below when trying to generate the initrd for kernel 3.2 on amd64 (multiarch with i386) Quote: Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/dkms 3.2.0-4-amd64 /boot/vmlinuz-3.2.0-4-amd64 run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.2.0-4-amd64 /boot/vmlinuz-3.2.0-4-amd64 update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64 E: /usr/share/initramfs-tools/hooks/pcidetect failed with return 1. update-initramfs: failed for /boot/initrd.img-3.2.0-4-amd64 with 1. run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Failed to process /etc/kernel/postinst.d at /var/lib/dpkg/info/linux-image-3.2.0-4-amd64.postinst line 696. dpkg: error processing linux-image-3.2.0-4-amd64 (--configure): subprocess installed post-installation script returned error exit status 1 * What exactly did you do (or not do) that was effective (or ineffective)? I tracked down the problem to the script pcidetect that trys to copy_exec some libs/bins to the new initrd-root. E.g. libresolv, libpci and lspci directly from /lib or /usr/lib or /usr/bin without considering that in multiarch on amd64 the libs are in sub-dirs. I worked around this by creating symlinks, e.g. in /usr/lib: libpci.so.3 - /lib/x86_64-linux-gnu/libpci.so.3 * What was the outcome of this action? Now, initramfs completes without a hitch and the systems boots. :-) * What outcome did you expect instead? - Request: would it be possible to fix this or tell me, what I should do to correct this problem in a systematic and reliable way? I guess my solution might break anytime... :-( Thanks Joachim -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 19M Dec 16 2011 /boot/initrd.img-2.6.38-7-generic -- /proc/cmdline BOOT_IMAGE=/vmlinuz-3.2.0-4-amd64 root=/dev/mapper/ssd-root ro nosplash noplymouth ipv6.disable=1 nomodeset fb=false -- /proc/filesystems btrfs ext4 ext2 fuseblk -- lsmod Module Size Used by parport_pc 22364 0 ppdev 12763 0 lp 17149 0 parport31858 3 lp,ppdev,parport_pc bnep 17567 2 cpufreq_conservative13147 0 rfcomm 33700 0 cpufreq_powersave 12454 0 cpufreq_stats 12866 0 bluetooth 119455 10 rfcomm,bnep cpufreq_userspace 12576 0 rfkill 19012 2 bluetooth autofs427628 2 binfmt_misc12957 1 fuse 62020 1 nfsd 216029 2 nfs 312433 1 nfs_acl12511 2 nfs,nfsd auth_rpcgss37143 2 nfs,nfsd fscache36739 1 nfs lockd 67306 2 nfs,nfsd sunrpc173730 15 lockd,auth_rpcgss,nfs_acl,nfs,nfsd ext2 59231 1 dm_crypt 22586 0 isl642312520 2 stv6110x 13008 2 stv090x42943 2 snd_hda_codec_hdmi 30824 1 snd_hda_codec_realtek 188858 1 snd_hda_intel 26259 0 snd_hda_codec 78031 3 snd_hda_intel,snd_hda_codec_realtek,snd_hda_codec_hdmi psmouse64497 0 snd_hwdep 13186 1 snd_hda_codec radeon718073 2 snd_pcm68083 3 snd_hda_codec,snd_hda_intel,snd_hda_codec_hdmi snd_page_alloc 13003 2 snd_pcm,snd_hda_intel snd_seq45126 0 powernow_k817618 1 mperf 12453 1 powernow_k8 snd_seq_device 13176 1 snd_seq snd_timer 22917 2 snd_seq,snd_pcm serio_raw 12931 0 pcspkr 12579 0 edac_mce_amd 17103 0 k10temp12611 0 edac_core 35258 0 ttm53664 1 radeon evdev 17562 12 drm_kms_helper 31370 1 radeon drm 183952 4 drm_kms_helper,ttm,radeon power_supply 13475 1 radeon asus_atk0110 17297 0 i2c_algo_bit 12841 1 radeon snd52889 9 snd_timer,snd_seq_device,snd_seq,snd_pcm,snd_hwdep,snd_hda_codec,snd_hda_intel,snd_hda_codec_realtek,snd_hda_codec_hdmi saa716x_ff 30323 0 sp5100_tco 12900 0 saa716x_core 56797 23 saa716x_ff dvb_core 77873 2 saa716x_core,saa716x_ff i2c_piix4 12536 0 i2c_core 23876 9 i2c_piix4,saa716x_core,i2c_algo_bit,drm,drm_kms_helper,radeon,stv090x,stv6110x,isl6423 soundcore 13065 1 snd shpchp
Bug#636697: initramfs-tools: no way to include library modules for libraries installed in multiarch path
Excerpts from intrigeri's message of Mon Jun 11 15:42:59 +0200 2012: Hi, Michal Suchanek wrote (05 Aug 2011 12:08:37 GMT) : At the very least the libc nss modules are required in intramfs to get dns lookup for netbooting. Splashscreen solutions like plymouth might need some of the graphics rendering modules. I think it would be useful to mark as blocked by this bug the ones that demonstrate the (very real!) need for a good solution to the described problem. Of course, there is no need. All packages that really needed it roll their own by now ;-) This simple additional function in hook-functions should allow initramfs hooks to install loadable modules effortlessly. I suggest attaching a patch against the current initramfs-tools package, making it clear if whether it was actually tested OK, and then tags + patch. (I would understand if the package maintainers did not feel should allow to be very confidence inspiring.) Back then many packages were not multiarch yet so I could not tell if the function would work for them. In particular this will possibly not work for Mesa drm modules due to glx-alternatives. The patch would just adds a function so it's applicable to any version of initramfs tools and the previously attached function was tested for NSS modules in live-initramfs, the only thing that does not have its own ad-hoc solution yet. The function uses only direct shell scripting and documented initramfs tools functions so should be pretty independent of initramfs version. Attaching an updated version of the function which aims at handling some odd filenames better. Note however that copy_exec handles odd filenames poorly in itself so this might be wasted code lines for the most part. I tested this in an environment which replaces copy_exec with echo and it appears to find and copy the modules all right. Thanks Michal multiarch-script-rel.sh Description: Bourne shell script
Bug#636697: initramfs-tools: no way to include library modules for libraries installed in multiarch path
Hi, Michal Suchanek wrote (05 Aug 2011 12:08:37 GMT) : At the very least the libc nss modules are required in intramfs to get dns lookup for netbooting. Splashscreen solutions like plymouth might need some of the graphics rendering modules. I think it would be useful to mark as blocked by this bug the ones that demonstrate the (very real!) need for a good solution to the described problem. This simple additional function in hook-functions should allow initramfs hooks to install loadable modules effortlessly. I suggest attaching a patch against the current initramfs-tools package, making it clear if whether it was actually tested OK, and then tags + patch. (I would understand if the package maintainers did not feel should allow to be very confidence inspiring.) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636697: initramfs-tools: no way to include library modules for libraries installed in multiarch path
Package: initramfs-tools
Version: 0.99
Severity: normal
Hello
initramfs-tools hook-functions include copy_exec function that copies an
executable including all required libraries, possibly including
libraries in some odd places like /lib32 /lib64 /lib/i386-linux-gnu,
etc.
However, some libraries use modules which are dynamically loaded and are
not copied by cope_exec. This includes libc nss modules, pango, pixbuf
and gtk modules, etc.
At the very least the libc nss modules are required in intramfs to get
dns lookup for netbooting. Splashscreen solutions like plymouth might
need some of the graphics rendering modules.
It is possible to require libraries to install some module lists which
would allow initramfs-tools to copy these modules automagically whenever
a library is copied into initramfs. There are multiple problems, though.
The module list would have to be maintained in different package than
the one where it is used (live-boot vs libc, plymouth vs pango) leading
to bitrot. The other issue is that not all modules are required. libc
has some 4-5 nss modules but only 1-2 are used in initramfs.
The solution I would like to propose requires some knowledge of the library in
the package that includes it in initramfs but lets initramfs-tools locate the
exact place where the library is located in the system. It requires that any
dynamically loaded modules always reside in the same path relative to the
library which seems to be the case with current packages and is generally
sensible.
This simple additional function in hook-functions should allow initramfs hooks
to install loadable modules effortlessly.
Thanks
Michal
# include a module dynamically loaded by a library
# $1 - directory to search for the library (may be / to search all of initramfs)
# $2 - library to search for
# $3 - module to include relative to library found
# example: lib_module /lib 'libc.so.*' 'libnss_dns.so.*'
# lib_module /usr/lib 'libpango-*.so.*'
'pango/*/modules/pango-basic-fc.so'
# Does not handle spaces in directory or module names and .. in module names.
lib_module()
{
local dir lib mod lib_dir i j
dir=$1
lib=$2
mod=$3
{ find ${DESTDIR}${dir} -name ${lib} -type l
find ${DESTDIR}${dir} -name ${lib} -type f ; } | { while read i ;
do
lib_dir=$(dirname $i | sed -e s ^${DESTDIR} )
ls ${lib_dir}/${mod} | { while read j ; do
copy_exec $j
done ; }
done ; }
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
