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?
Trying 2 understand vmlinuz and initrd.gz files!
- Krishnamurti Naskar
- Posts: 82
- Joined: Fri 20 Apr 2012, 10:16
- Location: Calcutta
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
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
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.
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.
Close the Windows, and open your eyes, to a whole new world
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!
Puppy since 2.15CE...
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!
Puppy since 2.15CE...
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..
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..
Close the Windows, and open your eyes, to a whole new world
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!
Puppy since 2.15CE...
I am Lead Dog of the
Puppy Linux Users Group on Facebook
Join us!
Puppy since 2.15CE...
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 .
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 .