Processed: Re: Bug#522041: initramfs-tools: conf/conf.d/cryptroot missing from initrd.img when using file system label
Processing commands for cont...@bugs.debian.org: reassign 522041 cryptsetup Bug#522041: initramfs-tools: conf/conf.d/cryptroot missing from initrd.img when using file system label Bug reassigned from package `initramfs-tools' to `cryptsetup'. stop Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522041: initramfs-tools: conf/conf.d/cryptroot missing from initrd.img when using file system label
reassign 522041 cryptsetup stop On Tue, 31 Mar 2009, Michael Lange wrote: On Tue, 31 Mar 2009 14:31:28 +0200 maximilian attems m...@stro.at wrote: On Tue, Mar 31, 2009 at 11:47:49AM +0200, Michael Lange wrote: Package: initramfs-tools Version: 0.92o Severity: important After upgrading from etch to lenny the new kernel would not boot, but stop with a message Waiting for root file system. The root file system is on a luks partiton as /dev/mapper/root. As suggested in the debian docs I added a file system label to /etc/fstab to avoid possible /dev/hda - /dev/sda confusions with a new kernel before upgrading, so the line for the root partition in /etc/fstab looked like: LABEL=CRYPTOROOT / ext3defaults,errors=remount-ro 0 1 When I opened the initrd.img with gzip and cpio I found the conf/conf.d/cryptroot was missing; when I added it manually and re-packaged the initrd.img the system would boot up normally. On a web search I found the discussion about bug #507721 and although I was not able to fully understand the technical details I thought it resembled my problems a lot. I then just tried to replace the LABEL=CRYPTROOT in /etc/fstab with /dev/mapper/root and ran update-initramfs again which then resulted in a correct initrd.img, so it looks like initramfs-tools does not handle file system labels correctly. did you try to pass a rootdelay=12 bootparam? I did experiment with the rootdelay parameter, but please note that the reason the system would not boot was clearly the missing conf/conf.d/cryptroot file. update-initramfs just failed to pack this file into the initrd.img if the root file system was specified by LABEL=CRYPTROOT in /etc/fstab. The system setup though was obviously ok., I just had to add the file manually to initrd.img and the system would boot up normally. The irony herein is that I would not have used the LABEL=... thing unless the debian docs had advised me to do so, otherwise I might end with an unbootable system ;) Michael just wanted to exclude the nr. 1 trap users fell into, reassigning to cryptsetup which is responsible for it's own hooks and conf/conf.d/cryptroot. anyway nicer then LABEL and recommended is UUID usage, but LABEL should just work too. -- maks -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522041: initramfs-tools: conf/conf.d/cryptroot missing from initrd.img when using file system label
Package: initramfs-tools Version: 0.92o Severity: important After upgrading from etch to lenny the new kernel would not boot, but stop with a message Waiting for root file system. The root file system is on a luks partiton as /dev/mapper/root. As suggested in the debian docs I added a file system label to /etc/fstab to avoid possible /dev/hda - /dev/sda confusions with a new kernel before upgrading, so the line for the root partition in /etc/fstab looked like: LABEL=CRYPTOROOT / ext3defaults,errors=remount-ro 0 1 When I opened the initrd.img with gzip and cpio I found the conf/conf.d/cryptroot was missing; when I added it manually and re-packaged the initrd.img the system would boot up normally. On a web search I found the discussion about bug #507721 and although I was not able to fully understand the technical details I thought it resembled my problems a lot. I then just tried to replace the LABEL=CRYPTROOT in /etc/fstab with /dev/mapper/root and ran update-initramfs again which then resulted in a correct initrd.img, so it looks like initramfs-tools does not handle file system labels correctly. Regards Michael -- Package-specific info: -- /proc/cmdline root=LABEL=CRYPTOROOT ro vga=773 -- /proc/filesystems vfat ext3 fuseblk -- lsmod Module Size Used by xt_TCPMSS 3616 1 pppoe 8672 2 pppox 3116 1 pppoe ppp_generic20028 6 pppoe,pppox slhc5408 1 ppp_generic binfmt_misc 7528 1 rfcomm 28272 2 l2cap 17248 9 rfcomm bluetooth 44900 4 rfcomm,l2cap battery10180 0 ppdev 6468 0 parport_pc 22500 0 lp 8164 0 parport30988 3 ppdev,parport_pc,lp ipv6 235300 22 cpufreq_conservative 5960 0 cpufreq_ondemand6476 0 cpufreq_powersave 1856 0 cpufreq_stats 3776 0 xt_hashlimit9360 0 iptable_raw 2176 0 xt_comment 1664 0 xt_owner2560 0 xt_iprange 2272 0 xt_policy 2848 0 xt_multiport2816 4 ipt_ULOG6820 0 ipt_TTL 1856 0 ipt_ttl 1600 0 ipt_REJECT 2784 4 ipt_REDIRECT1760 0 ipt_recent 6908 0 ipt_NETMAP 1760 0 ipt_MASQUERADE 2592 0 ipt_LOG 5028 12 ipt_ECN 2336 0 ipt_ecn 1888 0 ipt_CLUSTERIP 5956 0 ipt_ah 1664 0 ipt_addrtype2304 0 xt_tcpmss 1984 1 xt_pkttype 1728 4 xt_physdev 2352 0 xt_NFQUEUE 1792 0 xt_MARK 2304 0 xt_mark 1952 0 xt_mac 1728 0 xt_limit2180 0 xt_length 1760 0 xt_helper 2112 0 xt_dccp 2696 0 xt_conntrack3488 3 xt_CONNMARK 2944 0 xt_connmark 2368 0 xt_CLASSIFY 1696 0 xt_tcpudp 2816 21 xt_state2016 20 iptable_nat 4680 0 nf_nat 15576 4 ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 12268 26 iptable_nat,nf_nat nf_conntrack 55508 10 ipt_MASQUERADE,ipt_CLUSTERIP,xt_helper,xt_conntrack,xt_CONNMARK,xt_connmark,xt_state,iptable_nat,nf_nat,nf_conntrack_ipv4 iptable_mangle 2688 1 nfnetlink 3928 0 iptable_filter 2624 1 ip_tables 10160 4 iptable_raw,iptable_nat,iptable_mangle,iptable_filter x_tables 13284 40 xt_TCPMSS,xt_hashlimit,xt_comment,xt_owner,xt_iprange,xt_policy,xt_multiport,ipt_ULOG,ipt_TTL,ipt_ttl,ipt_REJECT,ipt_REDIRECT,ipt_recent,ipt_NETMAP,ipt_MASQUERADE,ipt_LOG,ipt_ECN,ipt_ecn,ipt_CLUSTERIP,ipt_ah,ipt_addrtype,xt_tcpmss,xt_pkttype,xt_physdev,xt_NFQUEUE,xt_MARK,xt_mark,xt_mac,xt_limit,xt_length,xt_helper,xt_dccp,xt_conntrack,xt_CONNMARK,xt_connmark,xt_CLASSIFY,xt_tcpudp,xt_state,iptable_nat,ip_tables fuse 42908 1 dm_snapshot14340 0 dm_mirror 15104 0 dm_log 8452 1 dm_mirror powernow_k812036 0 freq_table 4224 3 cpufreq_ondemand,cpufreq_stats,powernow_k8 cpufreq_userspace 3172 1 snd_fm801 14752 0 snd_ac97_codec 88484 1 snd_fm801 ac97_bus1728 1 snd_ac97_codec snd_pcm_oss32800 0 snd_mixer_oss 12320 1 snd_pcm_oss snd_pcm62596 3 snd_fm801,snd_ac97_codec,snd_pcm_oss snd_page_alloc 7816 1 snd_pcm snd_tea575x_tuner 3264 1 snd_fm801 videodev 27520 1 snd_tea575x_tuner v4l1_compat12260 1
Bug#522041: initramfs-tools: conf/conf.d/cryptroot missing from initrd.img when using file system label
On Tue, Mar 31, 2009 at 11:47:49AM +0200, Michael Lange wrote: Package: initramfs-tools Version: 0.92o Severity: important After upgrading from etch to lenny the new kernel would not boot, but stop with a message Waiting for root file system. The root file system is on a luks partiton as /dev/mapper/root. As suggested in the debian docs I added a file system label to /etc/fstab to avoid possible /dev/hda - /dev/sda confusions with a new kernel before upgrading, so the line for the root partition in /etc/fstab looked like: LABEL=CRYPTOROOT / ext3defaults,errors=remount-ro 0 1 When I opened the initrd.img with gzip and cpio I found the conf/conf.d/cryptroot was missing; when I added it manually and re-packaged the initrd.img the system would boot up normally. On a web search I found the discussion about bug #507721 and although I was not able to fully understand the technical details I thought it resembled my problems a lot. I then just tried to replace the LABEL=CRYPTROOT in /etc/fstab with /dev/mapper/root and ran update-initramfs again which then resulted in a correct initrd.img, so it looks like initramfs-tools does not handle file system labels correctly. did you try to pass a rootdelay=12 bootparam? -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522041: initramfs-tools: conf/conf.d/cryptroot missing from initrd.img when using file system label
On Tue, 31 Mar 2009 14:31:28 +0200 maximilian attems m...@stro.at wrote: On Tue, Mar 31, 2009 at 11:47:49AM +0200, Michael Lange wrote: Package: initramfs-tools Version: 0.92o Severity: important After upgrading from etch to lenny the new kernel would not boot, but stop with a message Waiting for root file system. The root file system is on a luks partiton as /dev/mapper/root. As suggested in the debian docs I added a file system label to /etc/fstab to avoid possible /dev/hda - /dev/sda confusions with a new kernel before upgrading, so the line for the root partition in /etc/fstab looked like: LABEL=CRYPTOROOT / ext3defaults,errors=remount-ro 0 1 When I opened the initrd.img with gzip and cpio I found the conf/conf.d/cryptroot was missing; when I added it manually and re-packaged the initrd.img the system would boot up normally. On a web search I found the discussion about bug #507721 and although I was not able to fully understand the technical details I thought it resembled my problems a lot. I then just tried to replace the LABEL=CRYPTROOT in /etc/fstab with /dev/mapper/root and ran update-initramfs again which then resulted in a correct initrd.img, so it looks like initramfs-tools does not handle file system labels correctly. did you try to pass a rootdelay=12 bootparam? I did experiment with the rootdelay parameter, but please note that the reason the system would not boot was clearly the missing conf/conf.d/cryptroot file. update-initramfs just failed to pack this file into the initrd.img if the root file system was specified by LABEL=CRYPTROOT in /etc/fstab. The system setup though was obviously ok., I just had to add the file manually to initrd.img and the system would boot up normally. The irony herein is that I would not have used the LABEL=... thing unless the debian docs had advised me to do so, otherwise I might end with an unbootable system ;) Michael -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
