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 <max@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 / ext3 defaults,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
Reply to: