Normally a the bootloader loads the kernel in memory, provides it a cmdline and some other information, and than passes execution to the kernel. Bootloader exit.
The kernel detects&initializes the hardware, and finally tries to mount the rootfs on /, as specified in the cmdline (root=/dev/sda, or something like that). When the rootfs is mounted, the kernel run the executable /sbin/init (or /init. (or something else, if specified in the cmdline).
is responsible for launching the whole userspace environment. On a Debian box it runs scripts from in /etc/init.d/ to do so.
Sometimes (actually: often) the rootfs isn't simple to mount. It could be a raid array, an nfs share, an encrypted disk, a logical volume, ..., or a combination. In that case an initrd (or initramfs) is used. It's a rootfs which it loaded in memory (ramdrive) by the bootloader, and the address is also provided to the kernel. The kernel will use it as rootfs then, and execute /init or /sbin/init from it. This init is in most cases a script, which assembles/mounts the actual rootfs, and then tells the kernel to switch rootfs, by execution of pivot_root.
On your EZMedia such an initrd is used. You have written it yourself to sector 8192. This initrd is actually a gzipped ext2 filesystem with a 64 byte header, which tells u-boot (the bootloader) where to load it in memory.
You can easily extract and mount the filesystem:
tail -c +65 initrd | gzip -d >initrd.bare
mount -o loop initrd.bare initrd.d
The 'tail' outputs all bytes starting from byte 65, which is piped through 'gzip -d' to ungzip it, and written to a file. That file is loop mounted. Now you can look at the init script. which is quite complex. The rootfs of an EzMedia is build from several loopmounted files, which are stored in a logical volume. And actually the initrd itself is also part of the final rootfs.
You can change the initscript in:
mount /dev/sda1 /new_root
/sbin/pivot_root . old_root
echo "Panic! Not supposed to be here!"
The pivot_root exchanges the rootfs by ., and puts the old rootfs in old_root. The last line is 'exec /sbin/init' which passes execution to /sbin/init in the new rootfs
You can gzip the changed initrd, (first unmount it), and then use mkimage to give it a uImage header. (Unfortunately you can't just reuse the old header, as it contains a checksum)
BTW, the new init could do the same trick again (and again, ..). Most Lacie NASses do so, the initrd assembles a raidarray from several disks, which is mounted, and pivot_root, and the new init assembles a unionfs filesystem, mounts it, and pivot_root again.
BTW2, in this case you could also change the u-boot environment. If the initrd is just omitted, and 'root=/dev/sda1' is added to the cmdline, the kernel would mount /dev/sda1 itself, and execute /sbin/init. But then you'll need a serial cable. (That serial cable is always convenient of course. Installing Debian blindly can be frustrating)
The new rootfs is supposed to contain a Debian filetree. This can be made using cdebootstrap
. When you search the Iomega forums you'll find that it's possible to get apt-get working on a EMC LifeLine device (like yours), and maybe you have enough room to install cdebootstrap, and perform the opererations on your box. That has as advantage that you can chroot the new filesystem to finalize it.
(install an ssh daemon, configure the network, ...). De fs can be created from any Debian system, also from a PC, but in that case you'll really need a serial cable, as the bare rootfs doesn't have any daemons running, so the only way to get them is over (serial) console.
You can also use the pre-build rootfs from this wiki entry
, which is old, (Lenny) but should run fine.
BTW, after running pivot_root the old rootfs is mounted on /old_rootfs. You can delete the contents and unmount it to free up the memory space.
rm -rf /old_rootfs/*