Bug#638068: [bisected] initramfs-tools generates unbootable initrd.img on IA-64 platform (Itanium)
On Wed, Aug 17, 2011 at 12:18:38AM +0200, Émeric Maschino wrote: Package: initramfs-tools Version: 0.99 Severity: grave As stated in this thread http://lists.debian.org/debian-ia64/2011/08/msg1.html, Debian Wheezy Testing cannot be booted at all on IA-64 (current linux-image-3.0.0-1-mckinley in Testing depends on initramfs-tools 0.99, so initramfs-tools cannot be downgraded to previously working 0.98.8). Hence severity set to grave. Last message displayed on console is: [ 17.146492] Freeing unused kernel memory: 1024kB freed Loading, please wait... And then, nothing. Regression has been bisected to commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 (mkinitramfs: copy over on build instead of using symlink tree) from maximilian attems, 2011-02-21 (initramfs-tools v0.99 development cycle). Comparison of last good and first bad generated initrd.img ramdisks show that: - good one has bin/busybox and bin/sh, bin/sh being a soft link on bin/busybox and size of bin/busybox matching size of system /bin/busybox (1320720 bytes) - bad one has no bin/busybox, only bin/sh (executable, not a link) but size (199144 bytes) doesn't match size of system /bin/busybox (1320720 bytes). Indeed, analyzing hook-functions and hooks/busybox source code, it's my understanding that bin/sh should be a copy of system /bin/busybox and thus should have the same size, right? I don't know where this 199144 bytes executable comes from. does initramfs-tools boot with BUSYBOX=no in initramfs.conf? according to your aboves statement it might not as the shared klibc dash and not the static dash might end up in the initramfs? see ls /usr/lib/klibc/bin Applying patch proposed in bug #628374 (initramfs-tools: Recent changes to hooks break busybox in initrd) to revert changes on busybox hook doesn't help. Simply reverting commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 from initramfs-tools v0.99 source code doesn't help either as resulting initramfs-tools binaries generate initrd.img failing to boot system with kernel panic, probably because of post-8f8299d9ba017d2a5af853a52be37ee50c89fac2 commits. The problem is still present in current initramfs-tools git repository. are you sure? there are easy test build around that fixes the busybox breakage: dpkg -l initramfs-tools | grep ^ii ii initramfs-tool 0.100~16.gbp8d generic modular initramfs generator relevant apt source line is: deb http://jenkins.grml.org/debian initramfs-tools main please test that one, thank you. -- maks -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: [bisected] initramfs-tools generates unbootable initrd.img on IA-64 platform (Itanium)
Hi, does initramfs-tools boot with BUSYBOX=no in initramfs.conf? Well, I don't know! Indeed, with BUSYBOX=no in initramfs.conf, initrd.img generation fails: root@longspeak:/# dpkg-reconfigure linux-image-3.0.0-1-mckinley Running depmod. Examining /etc/kernel/postinst.d. run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.0.0-1-mckinley /bo ot/vmlinuz-3.0.0-1-mckinley update-initramfs: Generating /boot/initrd.img-3.0.0-1-mckinley mv: cannot stat `/tmp/mkinitramfs_Z30F2f/bin/sh.shared': No such file or directo ry E: /usr/share/initramfs-tools/hooks/klibc failed with return 1. update-initramfs: failed for /boot/initrd.img-3.0.0-1-mckinley 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.0.0 -1-mckinley.postinst line 774. This is with initramfs-tools 0.99, as currently shipped in Testing. The same error occurs with source code currently in git. according to your aboves statement it might not as the shared klibc dash and not the static dash might end up in the initramfs? see ls /usr/lib/klibc/bin OK, here's where the 199144 bytes bin/sh exec comes from (size matches /usr/lib/klibc/bin/sh exec). Thanks for pointing this out. More on this later... Applying patch proposed in bug #628374 (initramfs-tools: Recent changes to hooks break busybox in initrd) to revert changes on busybox hook doesn't help. Simply reverting commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 from initramfs-tools v0.99 source code doesn't help either as resulting initramfs-tools binaries generate initrd.img failing to boot system with kernel panic, probably because of post-8f8299d9ba017d2a5af853a52be37ee50c89fac2 commits. The problem is still present in current initramfs-tools git repository. are you sure? Well, yes, I'm sure that the generated initramfs is unbootable. That being said, I've bisected the first bad commit. It's also possible that following commits fixed this issue, but other ones make it appear again, maybe with a different root cause. relevant apt source line is: deb http://jenkins.grml.org/debian initramfs-tools main please test that one, thank you. Still unbootable initramfs with this one. And initrd.img creation fails with the same error than with 0.99 and git with BUSYBOX=no in initramfs.conf. However, with BUSYBOX=yes, initrd.img can be generated successfully. If I look at its content, ls -l bin/ gives: -rwxr-xr-x 1 root root 199144 Aug 17 22:05 busybox lrwxrwxrwx 1 root root 7 Aug 17 22:05 sh - busybox Is it expected that bin/busybox in initramfs is in fact a copy of /usr/lib/klibc/bin/sh and not /bin/busybox? Indeed, ls -l on my system gives: -rwxr-xr-x 1 root root 1320720 Jul 25 16:17 /bin/busybox -rwxr-xr-x 1 root root 199144 Jul 27 17:32 /usr/lib/klibc/bin/sh Hope this helps, Émeric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638068: [bisected] initramfs-tools generates unbootable initrd.img on IA-64 platform (Itanium)
Package: initramfs-tools Version: 0.99 Severity: grave As stated in this thread http://lists.debian.org/debian-ia64/2011/08/msg1.html, Debian Wheezy Testing cannot be booted at all on IA-64 (current linux-image-3.0.0-1-mckinley in Testing depends on initramfs-tools 0.99, so initramfs-tools cannot be downgraded to previously working 0.98.8). Hence severity set to grave. Last message displayed on console is: [ 17.146492] Freeing unused kernel memory: 1024kB freed Loading, please wait... And then, nothing. Regression has been bisected to commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 (mkinitramfs: copy over on build instead of using symlink tree) from maximilian attems, 2011-02-21 (initramfs-tools v0.99 development cycle). Comparison of last good and first bad generated initrd.img ramdisks show that: - good one has bin/busybox and bin/sh, bin/sh being a soft link on bin/busybox and size of bin/busybox matching size of system /bin/busybox (1320720 bytes) - bad one has no bin/busybox, only bin/sh (executable, not a link) but size (199144 bytes) doesn't match size of system /bin/busybox (1320720 bytes). Indeed, analyzing hook-functions and hooks/busybox source code, it's my understanding that bin/sh should be a copy of system /bin/busybox and thus should have the same size, right? I don't know where this 199144 bytes executable comes from. Applying patch proposed in bug #628374 (initramfs-tools: Recent changes to hooks break busybox in initrd) to revert changes on busybox hook doesn't help. Simply reverting commit 8f8299d9ba017d2a5af853a52be37ee50c89fac2 from initramfs-tools v0.99 source code doesn't help either as resulting initramfs-tools binaries generate initrd.img failing to boot system with kernel panic, probably because of post-8f8299d9ba017d2a5af853a52be37ee50c89fac2 commits. The problem is still present in current initramfs-tools git repository. -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 18M Aug 16 21:45 /boot/initrd.img-2.6.39-2-mckinley -- /proc/cmdline BOOT_IMAGE=scsi1:/EFI/debian/vmlinuz.old root=UUID=59bf61ca-bdc4-4819-b6c7-5e6f8 057e8be ro -- resume RESUME=UUID=d550ead1-5755-40a6-af3a-07725fe4e688 -- /proc/filesystems ext4 fuseblk -- lsmod Module Size Used by fuse 148263 1 nfsd 580932 2 nfs 667482 0 lockd 148031 2 nfsd,nfs fscache78844 1 nfs auth_rpcgss80673 2 nfsd,nfs nfs_acl 5191 2 nfsd,nfs sunrpc401530 6 nfsd,nfs,lockd,auth_rpcgss,nfs_acl ipv6 667084 36 loop 30718 0 radeon 2088892 2 snd_fm801 35165 2 snd_ac97_codec184761 1 snd_fm801 ac97_bus1838 1 snd_ac97_codec ttm 117516 1 radeon drm_kms_helper 53852 1 radeon snd_pcm 147663 2 snd_fm801,snd_ac97_codec snd_page_alloc 11557 1 snd_pcm snd_tea575x_tuner 8774 1 snd_fm801 videodev 160214 1 snd_tea575x_tuner media 22901 1 videodev drm 318125 4 radeon,ttm,drm_kms_helper i2c_algo_bit 10968 1 radeon fm801_gp4776 0 gameport 15903 2 fm801_gp i2c_core 35751 5 radeon,drm_kms_helper,videodev,drm,i2c_algo_bit power_supply 16323 1 radeon evdev 20535 4 snd_opl3_lib 19238 1 snd_fm801 snd_timer 42224 2 snd_pcm,snd_opl3_lib snd_hwdep 13629 1 snd_opl3_lib snd_mpu401_uart13763 1 snd_fm801 snd_rawmidi40192 1 snd_mpu401_uart snd_seq_device 10749 2 snd_opl3_lib,snd_rawmidi snd 102026 13 snd_fm801,snd_ac97_codec,snd_pcm,snd_opl3_lib,s nd_timer,snd_hwdep,snd_mpu401_uart,snd_rawmidi,snd_seq_device soundcore 10343 1 snd ext4 554604 1 mbcache12842 1 ext4 jbd2 118997 1 ext4 crc16 1479 1 ext4 sd_mod 75886 3 crc_t10dif 1420 1 sd_mod usbhid 61155 0 hid 134780 1 usbhid sg 47353 0 sr_mod 32745 0 cdrom 73444 1 sr_mod ata_generic 5671 0 ohci_hcd 53106 0 pata_cmd64x10096 0 libata349825 2 ata_generic,pata_cmd64x mptspi 27375 2 mptscsih 38872 1 mptspi ehci_hcd 91574 0 mptbase 116134 2 mptspi,mptscsih scsi_transport_spi 44772 1 mptspi usbcore 284414 4 usbhid,ohci_hcd,ehci_hcd scsi_mod 252243 7 sd_mod,sg,sr_mod,libata,mptspi,mptscsih,scsi_tra nsport_spi tg3 299933 0 e100 64313 0 mii 8419 1 e100 libphy 36137 1 tg3 -- /etc/initramfs-tools/modules -- /etc/kernel-img.conf #
