patch for Documentation/initrd.txt?

patch for Documentation/initrd.txt?

[Tom Horsley]

[-- Attachment #1: Type: text/plain, Size: 444 bytes --]

I spend hours the other day trying to examine a fedora core 5
initrd file in the mistaken belief that the Documentation/initrd.txt
file might contain relevant information :-). It didn't, but
many web searches later I finally discovered the new key
to decrypting initrd files. Would it be possible to add the
attached patch (or a better one if someone can explain things
in more detail) to the initrd.txt file to avoid future
confusion? Thanks.

[-- Attachment #2: initrd-doc-patch --]
[-- Type: text/plain, Size: 954 bytes --]

--- linux-2.6.17.7/Documentation/initrd.txt	2006-07-27 08:49:30.000000000 -0400
+++ linux-2.6.17.7/Documentation/initrd.txt	2006-07-27 09:02:04.000000000 -0400
@@ -73,6 +73,22 @@
     initrd is mounted as root, and the normal boot procedure is followed,
     with the RAM disk still mounted as root.
 
+Compressed cpio images
+----------------------
+
+Recent kernels have support for populating a ramdisk from a compressed cpio
+archive, on such systems, the creation of a ramdisk image doesn't need to
+involve special block devices or loopbacks, you merely create a directory on
+disk with the desired initrd content, cd to that directory, and run (as an
+example):
+
+find . | cpio --quiet -c -o | gzip -9 -n > /boot/imagefile.img
+
+Examining the contents of an existing image file is just as simple:
+
+mkdir /tmp/imagefile
+cd /tmp/imagefile
+gzip -cd /boot/imagefile.img | cpio -imd --quiet
 
 Installation
 ------------

Re: patch for Documentation/initrd.txt?

[Al Boldi]

Tom Horsley wrote:
>
> I spend hours the other day trying to examine a fedora core 5
> initrd file in the mistaken belief that the Documentation/initrd.txt
> file might contain relevant information :-). It didn't, but
> many web searches later I finally discovered the new key
> to decrypting initrd files. Would it be possible to add the
> attached patch (or a better one if someone can explain things
> in more detail) to the initrd.txt file to avoid future
> confusion? Thanks.
>
> ["initrd-doc-patch" (initrd-doc-patch)]
>
> --- linux-2.6.17.7/Documentation/initrd.txt     2006-07-27
> 08:49:30.000000000 -0400 +++ linux-2.6.17.7/Documentation/initrd.txt    
> 2006-07-27 09:02:04.000000000 -0400 @@ -73,6 +73,22 @@
>      initrd is mounted as root, and the normal boot procedure is followed,
>      with the RAM disk still mounted as root.
>
> +Compressed cpio images
> +----------------------
> +
> +Recent kernels have support for populating a ramdisk from a compressed
> cpio +archive, on such systems, the creation of a ramdisk image doesn't
> need to +involve special block devices or loopbacks, you merely create a
> directory on +disk with the desired initrd content, cd to that directory,
> and run (as an +example):
> +
> +find . | cpio --quiet -c -o | gzip -9 -n > /boot/imagefile.img
> +
> +Examining the contents of an existing image file is just as simple:
> +
> +mkdir /tmp/imagefile
> +cd /tmp/imagefile
> +gzip -cd /boot/imagefile.img | cpio -imd --quiet
>
>  Installation
>  ------------

Thanks for your very useful docPatch!

OT, but your docPatch made me think of another way to init the kernel; via 
tmpfs, i.e. initTmpFS.

Can anybody see how that could be useful?

Thanks!

--
Al

Re: patch for Documentation/initrd.txt?

[H. Peter Anvin]

Al Boldi wrote:
> 
> Thanks for your very useful docPatch!
> 
> OT, but your docPatch made me think of another way to init the kernel; via 
> tmpfs, i.e. initTmpFS.
> 
> Can anybody see how that could be useful?
> 

Useful, yes, but this has turned out to be fairly complex.  tmpfs needs 
a *LOT* more of the system to be fully operational than ramfs, and the 
rootfs is initialized very early on, since one of its purposes is to 
eliminate special cases.

	-hpa

Re: patch for Documentation/initrd.txt?

[Rik van Riel]

Al Boldi wrote:
> Tom Horsley wrote:

>> +Compressed cpio images

> OT, but your docPatch made me think of another way to init the kernel; via 
> tmpfs, i.e. initTmpFS.
> 
> Can anybody see how that could be useful?

That is exactly what Tom describes, except it is called initramfs
and goes into ramfs - which is mostly the same as tmpfs.

-- 
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan

Re: patch for Documentation/initrd.txt?

[Al Boldi]

H. Peter Anvin wrote:
> Al Boldi wrote:
> > Thanks for your very useful docPatch!
> >
> > OT, but your docPatch made me think of another way to init the kernel;
> > via tmpfs, i.e. initTmpFS.
> >
> > Can anybody see how that could be useful?
>
> Useful, yes, but this has turned out to be fairly complex.

Sounds like somebody tried this before?

> tmpfs needs
> a *LOT* more of the system to be fully operational than ramfs, and the
> rootfs is initialized very early on, since one of its purposes is to
> eliminate special cases.

So would it be possible to remap rootfs from ramfs to tmpfs, once tmpfs is 
initialized, without actually doing another cpio?

Thanks!

--
Al

Re: patch for Documentation/initrd.txt?

[H. Peter Anvin]

Al Boldi wrote:
> H. Peter Anvin wrote:
>> Al Boldi wrote:
>>> Thanks for your very useful docPatch!
>>>
>>> OT, but your docPatch made me think of another way to init the kernel;
>>> via tmpfs, i.e. initTmpFS.
>>>
>>> Can anybody see how that could be useful?
>> Useful, yes, but this has turned out to be fairly complex.
> 
> Sounds like somebody tried this before?
> 

Several people, yes.

>> tmpfs needs
>> a *LOT* more of the system to be fully operational than ramfs, and the
>> rootfs is initialized very early on, since one of its purposes is to
>> eliminate special cases.
> 
> So would it be possible to remap rootfs from ramfs to tmpfs, once tmpfs is 
> initialized, without actually doing another cpio?

That sounds nasty.

	-hpa

Re: patch for Documentation/initrd.txt?

[Al Boldi]

H. Peter Anvin wrote:
> Al Boldi wrote:
> > H. Peter Anvin wrote:
> >> Al Boldi wrote:
> >>> Thanks for your very useful docPatch!
> >>>
> >>> OT, but your docPatch made me think of another way to init the kernel;
> >>> via tmpfs, i.e. initTmpFS.
> >>>
> >>> Can anybody see how that could be useful?
> >>
> >> Useful, yes, but this has turned out to be fairly complex.
> >
> > Sounds like somebody tried this before?
>
> Several people, yes.

This http://marc.theaimsgroup.com/?l=linux-kernel&m=107013630212011&w=4 looks 
rather trivial.

What am I missing here?

> >> tmpfs needs
> >> a *LOT* more of the system to be fully operational than ramfs, and the
> >> rootfs is initialized very early on, since one of its purposes is to
> >> eliminate special cases.
> >
> > So would it be possible to remap rootfs from ramfs to tmpfs, once tmpfs
> > is initialized, without actually doing another cpio?
>
> That sounds nasty.

I would call it an obvious hack, if it is necessary at all.  Plus it's only 
to kickstart things.

BTW, your pxebooter is great!

Thanks!

--
Al