General NAS-Central Forums

Welcome to the NAS community
It is currently Tue Oct 17, 2017 3:53 am

All times are UTC




Post new topic Reply to topic  [ 6 posts ] 
Author Message
PostPosted: Thu May 09, 2013 6:30 am 
Offline

Joined: Mon Jun 16, 2008 10:45 am
Posts: 6047
Actually the box is already running Debian. The only problem is that large parts of the filetree are readonly due to the way the rootfs is build.

If you want to boot a 'clean' Debian system, that can be done relatively easy. The box has a bootloader in flash, which loads the kernel and initramfs from harddisk (yes, sector 2048 and 8192). The initramfs contains a simple rootfs which assembles the 'real' rootfs from files and filesystems on the harddisk, and then pivot_root's into it.
If you just put a clean Debian rootfs on the first partition, and exchange the script in initramfs by one which only mounts partition 1, and pivot_root's into it, you've got a real Debian system.


Top
 Profile  
 
PostPosted: Thu May 09, 2013 4:02 pm 
Offline

Joined: Tue Mar 26, 2013 2:21 pm
Posts: 11
elmo22 wrote:
congratulations kgr1969 !...

it is good to know that the procedure and the recovery file provided by Mijzelf have work one more time...

omarcvd:
I am also new to NAS and Linux, I don't know if it will be possible to install another Operating System in the iomega EZ NAS...

the ones with a better understanding of these systems are Mijzelf and seidler2547... let's hope they read your question and post their answer...

p.s. please don't call me "Dear"...
I understand that english is not your primary language and in spanish the word you used denotes respect but in english it is use mostly for loved ones...
just use the user's name instead...


ok elmo22, thanks for the clarification. :D

Mijzelf wrote:
Actually the box is already running Debian. The only problem is that large parts of the filetree are readonly due to the way the rootfs is build.

If you want to boot a 'clean' Debian system, that can be done relatively easy. The box has a bootloader in flash, which loads the kernel and initramfs from harddisk (yes, sector 2048 and 8192). The initramfs contains a simple rootfs which assembles the 'real' rootfs from files and filesystems on the harddisk, and then pivot_root's into it.
If you just put a clean Debian rootfs on the first partition, and exchange the script in initramfs by one which only mounts partition 1, and pivot_root's into it, you've got a real Debian system.


Mijzelf, I understand but I'm not sure how to do it, could you help me with that?
where I find some "rootfs" clean for debian? and this is a script "initramfs"?
And what are these? "pivot_root's"

Greetings!


Top
 Profile  
 
PostPosted: Sat May 11, 2013 10:06 am 
Offline

Joined: Mon Jun 16, 2008 10:45 am
Posts: 6047
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).
This init 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:
Code:
tail -c +65 initrd | gzip -d >initrd.bare
mkdir initrd.d
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:
Code:
mkdir /new_root
mount /dev/sda1 /new_root
cd /new_root
mkdir old_root
/sbin/pivot_root . old_root
exec /sbin/init

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.
Code:
rm -rf /old_rootfs/*
umount /old_rootfs


Top
 Profile  
 
PostPosted: Tue May 21, 2013 2:18 am 
Offline

Joined: Fri Mar 08, 2013 1:58 am
Posts: 8
Thanks Mijzelf for the detailed explanation...

but I so Noob with this that I am going to have to read it many times to understand it...

thanks again...


Top
 Profile  
 
PostPosted: Wed Dec 31, 2014 1:00 pm 
Offline

Joined: Thu May 08, 2014 7:25 pm
Posts: 13
I'm having the biggest trouble extracting the initrd image. I've tried

dd if=/dev/sda skip=$((8192*8+1)) bs=64 count=65536 | zcat > initrd

But this doesn't give a valid gzip file. Doing the same but starting at sector 8191 and piping it to cat and using hexdump I see the following:

Code:
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
0000200 0527 5619 4cc7 6d3d bd53 226d 2d00 6730
0000210 0000 0000 0000 0000 fbd9 4273 0205 0203
0000220 0000 0000 0000 0000 0000 0000 0000 0000
*
0000240 5a42 3968 4131 2659 5953 8ace 6eb8 0200
0000250 ffd9 ffff ffff ffff ffff ffff ffff ffff
0000260 ffff ffff ffff ffff ffff ffff ffff ffff
0000270 ffff e6ff a2db 797c 85c6 00f4 bb07 4012
0000280 9515 010d d3e7 40be f701 00c0 0000 0400
0000290 0040 00a0 a000 0000 0000 a00d 0060 0034
00002a0 0000 0000 4d00 58b3 ca02 5b98 73ec f270
00002b0 62be 6bb3 b366 b325 aa63 0264 45a9 0a55
00002c0 0055 aa50 860d 63aa 9755 aad3 56b6 7720
00002d0 a762 ad6d e04e 8143 581f c6f2 77bc 0980
00002e0 50ef a7f6 8077 6e06 8187 0da4 cb3b 010c
00002f0 dc65 e106 0e80 bcdb 5cf3 cf03 a55a 0008
0000300 0e00 6a5e 28d5 9ea2 79ef 78e3 28df 0248


No where in here are the magic-bytes (0x1f8b) for the gzip format. Any ideas what's going on? Have the recent updates encrypted the initrd or something?

[edit] 5a42 is the BZIP format header. I used bzcat instead of zcat and it works.. problem solved! But for future information, the uimage appears to be bzipped these days


Top
 Profile  
 
PostPosted: Thu Jan 22, 2015 12:43 am 
Offline

Joined: Wed Jul 10, 2013 3:18 pm
Posts: 18
wbdsgnr wrote:
I'm having the biggest trouble extracting the initrd image. I've tried
Code:
dd if=/dev/sda skip=$((8192*8+1)) bs=64 count=65536 | zcat > initrd

[edit] 5a42 is the BZIP format header. I used bzcat instead of zcat and it works.. problem solved! But for future information, the uimage appears to be bzipped these days

So, just to be clear, the following works:
Code:
dd if=/dev/sda skip=$((8192*8+1)) bs=64 count=65536 | bzcat > initrd

The "8192*8+1" wasn't clear to me. So for others, I've explained it as follows:
* disk blocks are 512 bytes
* the "dd" blocking size is set to 64 for convenience because that's the size of the header
* so there are 8 blocks per sector (8*64=512)
* the header starts at sector 8192
* we want to skip 8192 sectors at 8 blocks per sector -> (8192*8) blocks
* and we want to skip an extra 1 (64 byte) block for the header -> (+1)

The same can be achieved with the following, which makes more sense to me:
Code:
sudo dd if=/dev/sda bs=512 skip=8192 count=8192 | dd bs=64 skip=1 | bzcat > initrd

I don't know what the size of the image is (my "count=8192", your "count=65536") but I'm guessing it's in the header. By over-estimating, we're letting bzcat find the end of the compressed image and discard the rest.
[edit]
Yep, it's a standard u-boot uImage header. Looks like offset 0xC (12dec) has a 4-byte field showing the size of the (compressed) image. Running "file" on the header decodes this all for us:
Code:
# dd if=/dev/sda bs=512 skip=8192 count=1 2>/dev/null | file -
/dev/stdin: u-boot legacy uImage, , Linux/ARM, RAMDisk Image (bzip2), 2981277 bytes, Wed Nov 26 07:05:46 2014, Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0x77C88C37, Data CRC: 0xA8510754

So we can use the "2981277" bytes from here, to calculate the size of the compressed image: 2981277 / 512 = 5822 -> rounding up to 5823.
Code:
dd if=/dev/sda bs=512 skip=8192 count=5823 | dd bs=64 skip=1 | bzcat > initrd


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 6 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group