Trying 2 understand vmlinuz and initrd.gz files!

[Krishnamurti Naskar]

We all know that
vmlinuz= The Kernel itself!
initrd.gz(/.tz)=Initial RAM Disk!

are needed to load distros into memory and run.

So what will happen if,for example,take these 2(generic ones compiled by pemasu/any other members)
files from one distro (eg. slacko) and use those to run another distro(eg. macpup),why things don't seem
to go in right way?
Can any1 care 2 expalin it 2 us?

[amigo]

Because of the different content of the intrd, the cations that that content takes before mounting the real root, and differences with what happens when init is finally run in the real root after mounting it. Also, many implementations use kernel features which are not commonly used elsewhere.

[mikeb]

In addition to those things (it could cludge its way through and some have done so with a matching vmlinuz) the biggest problem is that kernel specific modules are needed to be loaded at boot time to find and create the union file system...each initrd has to match the kernel for this reason above all others. One way around this is to build a kernel with the initrd modules built in which would make the initrd a bit more portable.

If you do use a vmlinuz and initrd pair from another puppy the biggest problem would be the absense of kernel modules for everything else (eg the mouse may not work) unless again you used the same kernel as the main system sfs.

There is a good thread on kernel transplanting in the HOW TO section if you have an interest in such things.

mike

[puppyluvr]

Hello,
The initrd calls the .sfs by name, specifically.
So the initrd looking for the lupu .sfs cannot find it in a slacko pup.
So it will "file not found" you.
I goofed during a woof, using just Puppy.
I had to rename the .sfs cause the initrd wanted
"puppy_pup_5362.sfs" .

PS..
If you mismatch vmlinuz and initrd
You get:
Kernel Panic.

[puppyluvr]

Hello,
Its layers, each called by the one below, starting with "bios"


depmod, busybox, x, savefile layer, wm, alsa, rox, etc.
switch root... make the filesystem root, or " home"
mount .sfs.. mount the virtual filesystem
Initrd.. the initial ramdisk
vmlinuz.. the kernel
bootloader..
bios..

[mikeb]

If you mismatch vmlinuz and initrd
You get:
Kernel Panic.

Yeah and the hard shutdown needed after that..a bit mean...modify the error message to go to a prompt on an error if chosen to to avoid that and a 60 second wait (hint)

mike

[Karl Godt]

The initrd.gz contains a ./DISTRO_SPECS file , that should be the same as /etc/DISTRO_SPECS in the puppy_whatever-number.sfs .

Otherwise as said by the others before, it would not find the wanted .sfs .

Initrd.gz doesn't know much about the current system but only the kernel `uname` at ite beginning of its ./init .

If `uname -r` does not match any directories in /lib/modules/ directory both in the initrd.gz and the puppy_name-nr.sfs , that would result in not loading any modular compiled hardware drivers at all .

The ./init script inside must detect everything "newborne" each time like partitions, drives, filesystems and wanted files by searching for files containing needed values or searching for explicit named files like

find /mnt/data -maxdepth 2 -xdev -type f -name ${DISTRO_FILE_PREFIX}-${DISTRO_VERSION}.sfs

and
DISTRO_FILE_PREFIX
is set in the ./DISTRO_SPECS file inside the initrd.gz . It does not mount any found .sfs and reads the values from /etc/DISTRO_SPECS in them - it uses it's DISTRO_SPECS to find the one and only .sfs that it was created for .


But of course it could be adjusted to ask to load which .sfs ,just like it asks to load which .2fs save-file when found more than one save-file.2fs .