[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#781002: initramfs-tools: no kernel modules are insert into initrd

Could I make a few suggestions while we're at it?
1) I sometimes build an initrd for a kernel I haven't installed yet. Yes, it's a mistake, but it happily succeeds and creates an initrd without any modules which then creates a non booting system.
=> initramfs should abort if its generated /lib/modules/kernel is empty

2) initramfs creates a temporary directory where it puts everything, and then deletes it before you can inspect it for debugging.
=> Add a --debug that leaves that directory behind for inspection.
Right now I have to unpack the initrd image which is more and more of a pain as it becomes a bundled binary of concatenated cpio images and god knows what.

3) document the binwalk method of unpacking initrd to debug if needed (somewhere in the manpage):
Or for the archives:
legolas [mc]# binwalk initrd.img 
pick up the offset of the 2nd initrd image, and unpack like so:
legolas [mc]# cd subdir; dd if=../initrd.img bs=21136 skip=1 | gunzip | cpio -idv

Thanks for your work,

On Mon, Mar 30, 2015 at 4:02 AM, Ian Campbell <ijc@debian.org> wrote:
On Fri, 2015-03-27 at 06:47 -0700, Marc MERLIN wrote:
> On Fri, Mar 27, 2015 at 08:10:31AM +0000, Ian Campbell wrote:
> > Control: retitle -1 initramfs-tools: does not support CONFIG_MODULE_COMPRESS
> >
> > On Fri, 2015-03-27 at 00:31 -0700, Marc MERLIN wrote:
> > > Sure, there you go
> > >
> > >
> > > Now I see the problem. It runs
> > > modprobe --all --set-version=3.19.2-amd64-i915-volpreempt-20141114
> > > --ignore-install --quiet --show-depends multipath.ko
> > > but I have
> > > /lib/modules/3.19.2-amd64-i915-volpreempt-20141114/kernel/drivers/md/multipath.ko.gz
> >
> > > (trailing .gz)
> >
> > Ah, yes. I see this is a new kernel option, CONFIG_MODULE_COMPRESS (with
> > gz and xz variants) which seems to have been introduced in v3.18-rc1.
> >
> > I suppose disabling that in your local builds would work around the
> > issue until initramfs-tools can be taught to cope.
> Yes, it was late last night when I found this, but indeed this was my
> plan :)
> All I needed was the way to run initramfs in debug mode and then it was
> obvious.
> Would you mind adding this in the man page? I could have debugged this a
> while ago had I had the easy way to run it in debug mode.

Adding some sort of --debug-trace option would be nicer than documenting
"run it under sh -x", but yes, it could be made easier/more obvious that
this was a useful debugging technique.


"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems & security ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

Reply to: