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

Re: Problems packaging a kernel using cdbs



On 3/19/07, Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> wrote:
"Luis R. Rodriguez" <mcgrof@gmail.com> writes:

> On 3/16/07, Roberto C. Sanchez <roberto@connexer.com> wrote:
>> On Fri, Mar 16, 2007 at 01:50:14PM -0400, Luis R. Rodriguez wrote:
>> > I've seen some posts on debian-devel from a while back which indicates
>> > some of you (Robert Millan) you've build a kernel using cdbs. I'm
>>
>> Perhaps I misunderstand, but can't you use kernel-package?
>
> My goal is to actually generate a debian package which will have a
> very small x86 kernel and a very very custom initramfs (bundles of
> software) for a PXE boot environment. Kernel-package lets me build a
> debian package out of the kernel source tree, but I want to do
> something a bit different. I just looked into kernel-package's support
> for generating custom initramfs cpio archives but it really lacks
> documentation even on the source. I then checked out initramfs-tools
> but just installing this package makes it spin an generate an
> initramfs for me on /boot/ without even consulting...; then I read the
> man page for mkinitramfs and I see this:
>
> ---
>       At  boot  time, the kernel unpacks that archive into RAM disk,
> mounts and uses it as initial root file system. All finding of the
> root device hap-
>       pens in this early userspace.
> --
>
> initramfs is not an archive that gets put into a RAM disk, the ramdisk
> is only used by initrd... the new design of initramfs replaces that
> whole mess and takes advantage of the new tmpfs filesystem. The fact
> that the man page has it wrong doesn't make me want to touch that in
> any way.

Actualyl I think the manpage is right. The archive gets put into the
"ramdisk" as that is how the bootloader passes the data along.

The initramfs code then checks for the achive signature in the
"ramdisk", unpacks it to tmpfs and frees the ramdisk.

That is similar to the initrd code looking at the "ramdisk", finding the
gzip signature and uncompressing it into the actual rmadisk.

Nope, its very wrong. You do not need ramdisk support to support
initramfs at all, we don't use ramdisk in any way. By default, meaning
its supported without regard to your .config, the cpio archive gets
packed into the kernel and later always extracted into rootfs. In fact
the entire block layer can be removed, which is required by ramdisk
support, and you will still get initramfs support, even if you want
external initramfs support (ie, grub initrd line). I have a patch
that'll allow you to get external initramfs support even if you do not
want the block layer, currently it doesn't because of the layout of
Kconfig, but its supposed to though, it works and I have tested it.

> Anyway -- I just tried to use "make-kpkg build" as the build commands
> for my "kernel" target and still run into the same problem. Running
> "make-kpkg build" manually works though. So there is something about
> using cdbs that is not letting me build the kernel right. The include
> path gets (./include) is getting ignored completely for some reason.
>
>  Luis

Please do use make-kpkg. If you need something in kernel-package to
change for your use case (like building the initrd during compile)
then please talk to the maintainer to support this. It is a bad Idea
to duplicate the kernel building and packaging. It is bad enough
linux-2.6 source has started to do that.

It does not do what I want it to right now and I need to move on
quick. I've adopted my own debian/rules instead of cdbs as well.
Perhaps if I have time I'll hack on make-kpkg.

Thanks,

 Luis



Reply to: