### Howto: Dreambox Image Manipulation & Remote Filesystem ###

beady

Inactive User
Joined
Jun 30, 2007
Messages
722
Reaction score
32
Location
Back in the Toon
Introduction
This is the first part, and is about setting up the required server(s). A second part will follow, discussing how to actually get the filesystem from a dreambox image onto your server for booting, and then actually booting it.

First of all, you should have a bit of linux experience (or be willing to learn), and be prepared for this to take a while. It's impossible to provide a tutorial suitable for everyone, due to the different hardware and software available to each of us. So the code I show is fairly specific to my set up. Please don't expect things to work as-is on your system. It's supposed to provide examples of a working system, and show what you'll need to set up for your system. This is certainly not 'plug and play'. Good luck :) It's really not too hard once you understand things.

Acknowledgements
First of all, I must point out that this tutorial is heavily based on the work of other people. I got the original idea after reading an old thread by yrdel. He's talking about the dbox2, but the principles are the same. Also, have a look at this page, which discusses the dreambox, and contains some useful hints.


Dreambox Boot Process
As I understand it, the boot procedure of a dreambox has the following steps:
- Immediately after power on, a hardware bios gets control, initializes some hardware and then loads and runs whatever is contained in the bootloader partition of the flash chip.
- The bootloader code (OpenBios) runs some more initialization, then looks for a linux kernel to load. This is the first point at which we can influence the dreambox externally. If you've ever had to get a boot log through hyperterminal, you stop the boot process towards the end of the boot loader code, just before it passes control of the kernel.
There are three options available for the bootloader. By default it will look on the flash for a CramFS block containing a valid kernel. If it can't find that, it'll send out 'bootp' requests over the network interface to see if anything is going to send it a kernel, and finally, there is the option to recieve a kernel over a serial port. It's the serial port method that's used by dreamup when you reflash with a null modem cable. Once it's got a kernel, it proceeds to unpack, then trandfers control over to it.
- From here on, the bootprocess is standard linux. The kernel does things like initializing hardware, mounting the root filesystem, and starting the various high level programs that run on the dreambox like enigma or neutrino.

What we need to do for network booting is set up a system to send answers to the dreambox's bootp requests.

What you need
Hardware:
You need a linux based machine to run the various servers, and also somewhere to store the kernel(s) and root filesystem(s). In my case, I've got a Linksys WRT54GS which acts as my main router, and which runs dnsmasq (see below), and an Asus WL-500g router with a 256mb usb stick attached to act as both the file server for the dreambox, and a wireless bridge to the rest of the network. Both routers are running OpenWRT

Software:
- A BOOTP server to reply to the OpenBIOS requests.
- A DHCP server sending out ip addresses to the local LAN. On most home networks, this'll be your router.
- A TFTP server to supply the kernel to the dreambox. TFTP is the protocol that OpenBIOS uses to download the kernel.
- An NFS server which exports the remote filesystem to the dreambox. For those that don't know, NFS can be thought of as the equivalent of a 'Shared Folder' in windows.
While technically you need all the above, many programs support more than one function. For instance, the dnsmasq program commonly used in embedded routers can act as both a DHCP, BOOTP and TFTP server (as well as being a DNS server as well!). In the case I'll discuss in detail, I've got the following programs running:
- dnsmasq: Acting as the DHCP and BOOTP server.
- atftpd: A TFTP server supplying the kernel.
- nfsd and support programs: This is the standard linux nfs server.

Installation
The guide for installing the various requirements is going to be sparse, and solely based on my machines. I know that OpenWRT can be a bit scary for some, since it's command line only. I'm sure you can do exactly the same things with DD-WRT or other open source firmware, but I've never tried. Feel free to ask questions about them though.
Okay, the installation procedure for the above on an OpenWRT router is as follows:
dnsmasq is the default dhcp and dns server in OpenWRT, so it's installed already. Installing the tftp server is easy
Code:
You don't have permission to view the code content. Log in or register now.
. The xinetd above is used because I didn't want to have tftpd running all the time. So I installed xinetd (which is basically a server which starts other servers as required) as well. Since I've also got ftp and ssh servers running, both starting through xinetd, it save memory when things aren't in use. If you're just testing, don't bother with xinetd. Anyway, I digress.To install nfsd, just type
Code:
You don't have permission to view the code content. Log in or register now.
.

Configuration
dnsmasq
Here's a copy of my /etc/dnsmasq.conf configuration file:
Code:
You don't have permission to view the code content. Log in or register now.
For the most part, it's the same as the default configuration that OpenWRT installs. You can safely ignore the dhcp-script line, (since that's just my way of setting up custom port forwarding rule). The important lines for our purpose are the last three. Firstly, the 'dhcp-host=' line tells dnsmasq that I want the device with MAC address 00:09:34:25:01:41 to be called dreambox, and to always assign it an ip address of 192.168.1.105. So you should change this line to reflect you dreambox's MAC address, what you want to call it, and what i.p. you want it to get.
The dhcp-boot line tells dnsmasq about the kernel we're going to supply via TFTP.'net:dreambox' identifies which device we're talking about (you can send different kernels to different devices by defining more lines like this).Next, 'root/platform/kernel/os' defines the path to the kernel on the tftp server, while 'asus,192.168.1.137' identifies the name and address of the tftp server.
The last line, 'dhcp-option=' is a little confusing, but it basically identifies an extra option (in this case number 17), detailing what to send the client for the mount line for the nfs server. You want to replace the '192.168.1.137:/mnt/storage/.....' with the ip and path of the nfs mount. The nolock after the comma is the options to the mount command. I recommend using nolock, since some nfs clients and servers will take a VERY long time to mount without it.

Configuring the nfs server is easy, simply select a directory to share and add it to your /etc/exports file. Mine only has one line
Code:
You don't have permission to view the code content. Log in or register now.
/mnt/storage/dreambox is the path to my usb mounted storage directory I want to share, * shows I want to share it with everyone (bad idea in a insecure environment, but not really a problem at a home LAN, provided you've got a firewall), and the last bit specifies mount options. rw for read/write support, while sync slows things down a bit but makes things a bit safer, and no_root_squash allows root clients to have root status on the server. This is needed for exported clients.

Finally, configuring atftpd is different depending on whether you're using xinetd. If not, you can simply type 'aftfpd --daemon --port 69 <path to kernel storage area>'. This'll kick off atftpd in daemon mode (i.e. in the background) and start accepting requests (for some reason this only works properly if you specify port 69. Go figure?).

Okay, now I think we need a specific example to test atftpd with. The following session shows a successful test. First I create a directory, populate it with a file, then start up the tftp server. Then, from another machine, I grab that file via tftp.
On the server:
Code:
You don't have permission to view the code content. Log in or register now.
Now to test it,
Code:
You don't have permission to view the code content. Log in or register now.
If you want it to start at boot, create a file in /etc/rc.d that looks like:
Code:
You don't have permission to view the code content. Log in or register now.
Don't forget to chmod +x it so it's executable.

I won't go into how to get xinetd to start atftpd. You can find the info on various places on the web, and I don't think may will use it anyway.

Closing remarks
I think that's about enough for now. I'd like to make sure at least one person trying this can get this far before specifying how to add the required dreambox files (in fact I've written a script for stripping an image file, so it's dead easy).

Good luck everyone. Please add comments and questions. I'm sure there'll be loads :).
 
Last edited by a moderator:
Excellent tut m8. Will try this when I get my network rearranged but won't be for a couple weeks probably.

Just to clarify: you have dnsmasq running on your GS and atftpd/nfsd running on your 500g?
 
Last edited:
Just to clarify: you have dnsmasq running on your GS and atftpd/nfsd running on your 500g?
Yes, that's right, although most won't want things set up like me. The reasons for my configuaration are that:
- Only the Asus has usb, so I've got to have the nfs server on that.
- My WRT acts as my main router (the one connected to my modem), so it's a LOT easier to leave dnsmasq as a dhcp and dns server on that.
- I've put the tftp server on the asus (rather than using dnsmasq on the linksys) to save having to mount an nfs share on the linksys then 'export it back' as tftp. Doing it my way is a little more complicated (I have to configure atftpd, but I don't have to mount nfs on the WRT. Six and two threes really.

I would have thought some of you will want to run this from a NAS drive and a router. To do this, the following changes to the tutorial need to be (assuming your NAS doesn't have a tftp server, but is able to export via NFS):

-Create a directory on the NAS and export it via nfs. Let's say you've called it dreambox. Create sub directories called 'kernel' and 'rootfs' which we'll populate late with the required files).
-Install the nfs client module on your router:
Code:
You don't have permission to view the code content. Log in or register now.
-Create a mountpoint on the router, and mount the NAS using a command like:
Code:
You don't have permission to view the code content. Log in or register now.
-No need for a tftp server. Use the feature in dnsmasq instead. The important bits of the dnsmasq.conf file will look like:
Code:
You don't have permission to view the code content. Log in or register now.

As I've said before, please don't think this is the only way to do it. If you've got a different set of hardware you want to try, post below with questions. Chances are that if it runs linux you can get it working. I bet you could even use another dreambox.
 
Yeah I'll be running it with a router (WRT54GSv4 w/ tomato) and a NAS (MyBook World 1TB).

I'll probably go with the first config (atftpd on NAS). I'm leaning towards installing xinetd so some tips on configuration would be helpful.

Also how difficult would it be to set up serving different filesystems to multiple boxes? I have a 500c and 2x dbox2.
 
Last edited:
Installing for multiple devices shouldn't be any more difficult than installing for one. You just have to add extra lines in the dnsmasq.conf for each device, telling it which kernel and rootfs to download.

Does your NAS have some third party firmware on it? At the moment I'm playing around to see if we can use a non-NFS NAS to hold the filesystem. My idea is to mount an NTFS smb share from the NAS on the router, the re-export this as an NFS share to the dreambox. I'm pretty sure that FAT32 wouldn't work, since it doesn't support user permissions etc, but I think the NTFS drivers in linux should be able to 'fake' the unix permissions on this filesystem. I'll post back if I get anywhere. This'd open up a lot more NAS devices to being suitable for network booting.
 
Nah, standard firmware. ssh and nfs already installed just need a few mods to activate them.

NAS should be here in a few days so I will let you know my progress.

Another quick question tho. Would there be an easy way to switch between multiple filesystems on the same device? eg standard setup for watching tv and a dev setup for playing with cvs.
 
I was just wondering how you were going to put a tftp daemon on it. I guess it's there already.

As for changing images. I've got mine so that I swap 2 symlinks on my WRT54GS, then reboot the dreambox. Job done. I haven't got round to it yet, but I'll probably put a script accessible from a dreambox menu, so you can do it at the touch of a button. As it is, takes about 3 seconds to switch between images (not counting reboot time, which is a bit slower than with a flashed image).

I'm going to post the second part of the howto later tonight, not a lot of point in waiting.
 
Cool. I'm thinking of getting back into dbox/dream dev a bit and this will make my life a hell of a lot easier.

Look forward to reading it.
 
NFS Remote Filesystem: Part 2

...Continued
Okay, at his point, you should have working NFS, TFTP and BOOTP/DHCP servers on your network. We're now going to see how to extract the filesystem and kernel from an image, edit them slightly and then start network booting. Most of this is handled by the script attached at the bottom of this post, so it's fairly easy to get running. For a specific example, I'll show how to install the latest Digital Worldz image, DW2.

Structure of the image file
A .img file is simply a CRAMFS kernel structure, with a SQUASHFS root partition appended on the end. While it's easy to extract these two sections, it's harder to get the files we need out of them (i.e. the actual kernel, and the actual directory structure). In order to do this, we actually use the dreambox itself. Linux has the ability to mount a file exactly like a disk drive or flash partition. So we can 'mount' the two sub-images (cramfs and squashfs) and use them exactly as if they were normal disks (well, read-only disks, but that's not a problem).
Of course, things are never that easy. There's two complications. Firstly, the CRAMFS partition is big-endian. In simple terms, this means that the bytes representing numbers in big endian systems are in the opposite order to those on little endian machines. Most current intel based computers are little endian. Unfortunately, it's so far not possible to mount CRAMFS images on a machine with different 'endianness' to the one which it was designed for. So We need a big-endian machine to get at the kernel. So we use the dreambox itself to mount the CRAMFS and then copoy the kernel out.
The second complication is that the SQUASHFS partition containing the root filesystem (/sbin, /bin, /var_init etc) is created using a patched version of the kernel squashfs, which provides greater compression, but means that we need to use a similarly patched kernel if we hope to mount it. It's certainly possible to recompile the kernel for your linux machine with the required patches, but it's a lot easier to let the dreambox do the job for us again.

What you need
You will need your servers set up in part one, and also a linux machine with an editor to change the unpack script. A VMWare machine will do fine, or you could even (like me) run it all within a router. It's up to you. It's also ESSENTIAL you run the script as the root user. You need to be able to do things like mount devices, which usually only root can do.

The Extract Script

The script below simply automates the procedure for splitting up the raw image (say dw.img), copies the CRAMFS and SQUASHFS sections over to the dreambox, mounts them using the dreambox, and then copies the files back out onto the NFS share ready for use. At the end, there's a few changes made to the files (e.g. the kernel) to allow network booting. So now I'll try to explain what's going on in the script. It's heavily commented, so hopefully you will be able to follow it.You WILL have to edit the top of the script, so I recommend reading the rest of the tutorial at least once before attempting this.
To start the script, copy it to the same directory as the image you want to boot, and type
Code:
You don't have permission to view the code content. Log in or register now.
You will probably need to chmod +x it first to make it executable.

Initialization section
The top part of the script simply sets up some variables determining the local network and exports. It should be fairly self-explanatory, and you'll need to change the settings according to your environment.
Code:
You don't have permission to view the code content. Log in or register now.
NAMESERVER_IP is the ip of the machine running dnsmasq (or alternative), NFSSERVER_IP is the machine that's going to hold the filesystem, NFSEXPORT_PATH is the remote path to the NFS share and NFSLOCAL_PATH is your local mount path for the NFS export you're going to do work in. You also need to set the CURRENT ip of the dreambox, since we need to be able to telnet into it and run the commands.
After this, the script creates the sub-directories kernelfiles and rootfiles to store the extracted files.

Base Image Splitting
Code:
You don't have permission to view the code content. Log in or register now.
The above mounts our cramfs.img as a 'loopback' device, so that if we change into /tmp/loopmountpoint, we can see the contents of the image. The script then copies the required files out to the NFS share, and essentially does the same with our squashfs.img. One thing to note is that you can't just 'copy' the root filesystem, since doing so messes up the symlinks in the image. We've got to mount it, zip it up into a tar archive, and then copy this to the NFS share. We can then extract the files again, and the symlinks will have been preserved.

The work on the dreambox takes a long time (up to 5 minutes), and it will probably look like it's crashed. Hopefully it hasn't. You've just got to be patient. Have a look at the LEDs on your router or NAS.They should be showing activity. If it appears to hang, don't type anything and give it 5 minutes.

Making the filesystem bootable
The last section of the script automatically edits some of the files we've extracted to make them suitable for booting. First of all, the kernel binary contains a line specifying how the kernel should boot, we need to change that. The following line replaces the default with what we need for a network boot. Doing this saves us from having to use a null modem cable to intercept the boot process each time we reboot.
Code:
You don't have permission to view the code content. Log in or register now.
I'm not going to explain how the above works, suffice to say that it does. If anyone does want to know, I'll try and explain it. The best thing to do though would be to google 'sed'. You'll get an idea about what we're doing.

The next thing to edit is the enigma or neutrino configuration file. When the dreambox boots, it runs either enigma or neutrino, which on all the images I've seen tries to re-detect network settings. This is disastrous for a network boot, since in the process it shuts off the network. Once the network interface is down, we can no longer see the filesystem, so we can't run any programs, including the programs to bring the network back up. The dreambox hangs. So we use the code below to see what type of image we have, and then edit the relevant config file to disable setting up the network again. After all, all (or most) of the parameters have been set already earlier on by BOOTP.
Code:
You don't have permission to view the code content. Log in or register now.

The last bit we can do automatically is add a nameserver to the resolv.conf file. This is (as far as I can tell) the only thing we miss by not being able to re-run a dhcp request. It's trivial to solve though:
Code:
You don't have permission to view the code content. Log in or register now.

That's the end of the script. There's one more thing we need to do, edit /etc/init.d/rcS, and while I tried to implement it in the script, it was buggy, and didn't work well between images. /etc/init.d/rcS is a script that is called very early on in the boot process, soon after the kernel has set itself up. It does things like mount filesystems, create device nodes, and other important tasks. What we need to do is change the file so that it doesn't try to mount the flash, since it'd defeat the point of the network boot. Here's the rcS from the latest DW image, and the points you need to edit (marked with *'s and CAPITALS).
Code:
You don't have permission to view the code content. Log in or register now.

Finishing off
Hopefully you've now got a nice directory structure on you NFS containing all your extracted files. You might need to alter your settings in dnsmasq.conf to reflect your structure. For the single image we've just installed, I'd have:
Code:
You don't have permission to view the code content. Log in or register now.
Your's may differ depending on your choices at the top of the script.

Now you want to make sure you can get the kernel with tftp. Do this from both a remote machine. I would start my atftpd with the line:
Code:
You don't have permission to view the code content. Log in or register now.
and test with
Code:
You don't have permission to view the code content. Log in or register now.
You need to make sure that whatever path you've got in dnsmasq.conf is able to retrieve the kernel. If it doesn't work, the chances are that you've got you're directory structure mixed up. Try again till you suceed. Finally check that typing
Code:
You don't have permission to view the code content. Log in or register now.
will mount your rootfs correctly. you should be able to change into the <some temporary mount point>, and see bin, var, sbin and etc directories.

Doing the network boot
Once you're happy that everything is set up properly (I can almost guarantee it won't be, but you won't know till you try), plug a null modem cable into your dreambox and fire up hyperterminal. Power off the dreambox, wait a bit then power it up.When you see the 'DM 500' appear, press return a few times, and you should enter the openbios boot menu. From here, press '2' to choose boot devices, then press '2' again to enable the network boot. Press enter, and you're back at the main screen. Now's the moment of truth. When you press '0' now, the bootloader is going to skip trying to load the flash and go straight to network booting. So press '0' and pray :).
If everything is set up right, you'll see 'BOOTP request sent' in hyperterminal followed by something about 'transfering image'. It's now loading the kernel from your tftp server. If it just keeps sending bootp requests (I think it sends five before it gives up), then it can't contact your dhcp/bootp server. If the bootp requests stop, but it doesn't seem to be transfering a file, then for some reason your tftp server isn't set up correctly (or your dnsmasq.conf file is wrong).
Assuming the kernel is transfered correctly, the next thing you'll see is a line with 'console=ttyS0 .....', and then the kernel will uncompress and try to mount your nfs root filesystem. Errors about 'unable to find init' mean that the nfs mount didn't work properly. Check your paths. If you get this far, then get hundreds of errors about missing programs ('no such file or directory'), then you've missed something in a config file somewhere and the network is trying to restart itself.One final thing to check is to see if you've mounted any flash along the way. Telnet into the dreambox and type 'mount'. This will display all the currently mounted devices. If there's anything about mtd, then you've missed something in the /etc/init.d/rcS script. Go back and take a look at it.

If you get past all the above pitfalls, then you've got a network mounted dreambox. Congratulations.

Concluding remarks
- Don't expect this to work first time. It took me a good few hours to get this working nicely, and I do this sort of thing for a living.
- I don't pretend to know very much about dreamboxes, so I'm sure that there are things that I've missed.Also, this is almost certainly an 'ugly hacky' way to get this working. I welcome input from others as to how to improve the tutorial, script etc.
- Once you're happy that things are working right in your new 'diskless' dreambox, you can make it default to network booting all the time, so you don't need to hyperterminal it at each reboot. If you corrupt the CRAMFS partition on flash, the bootloader will then start throwing out bootp requests for a kernel, which is what we want. Telnet into the dreambox and type 'dd if=/dev/zero of=/dev/mtdblock/0 bs=1 count=512'. This'll blank out the first 512 bytes of your cramfs, so OpenBIOS fails to read it, and starts bootp'ing. Don't worry, it's completely recoverable with dreamup. Just make sure, as always, don't go near /dev/mtdblock/2 or you'll overwrite OpenBIOS and kill the dreambox for good.

Hope this helps and good luck. It's nice having all the games and addons available on the same image :)
 
Last edited:
Something to play with at the weekend!

Obviously a few changes will be needed for dbox images - no cramfs for a start.

Can you post your method/script for switching between images. Cheers.
 
Can you post your method/script for switching between images. Cheers.
It's nothing special. Just a changes a few symlinks. But here goes (I've cleaned it up a bit):
Code:
You don't have permission to view the code content. Log in or register now.

In my dnsmasq.conf I've got:
Code:
You don't have permission to view the code content. Log in or register now.
and atftpd is started with:
Code:
You don't have permission to view the code content. Log in or register now.

So I run the script with the image name as an argument (eg dw, gemini or cvs), and it sorts out the symlinks for me. The main script above puts everything in the right directories.

Hope this gives you the idea.
 
Cheers.

No doubt I'll have a million questions after I get started. Prepare yourself!
 
Extracting the /var partition from an image: Howto

This is a followup to the NFS mounted root filesystem threads. In those, I described how to extract the contents of both the cramfs and squashfs partitions in an image. The final section in some images in a final JFFS2 section tacked onto the end for the /var. You'll get such an image if you backup your current flash.

Why would you want to do this? Well, I'll give one example where this is useful. There's a thread in the Satellite section concerning an image with an unknown password. The password was originally set by a trader, to prevent the buyer from messing around, and to make sure they could charge $$$ to 'fix' problems (such as changing keys), instead of allowing the buyer to learn a bit and do it themselves. Not very sporting if you ask me.

Unfortunately, you can't mount a JFFS2 image as a loopback device (like I showed for the cramfs and squashfs in the NFS howto). This is due to JFFS2 being designed for flash chips, not standard block devices (hard drives etc). But we can get around this by simulating a flash chip in memory, copying the image into it, then mounting it from there.

First things first. To extract the JFFS2 image requires a little work. You'll need a linux machine (or virtual machine) to do this bit, the rest will be done on the dreambox itself. It's a little awkward finding the position of the JFFS2 partition in the complete image. The standard header for JFFS2 is identified by bytes with hex values '85' and '19'. This occurs fairly often in an image, so you might have to try a few positions. To find the potential 'join' points, run:
Code:
You don't have permission to view the code content. Log in or register now.
You'll get output like (taken from the TeZeTo.img from the satellite post)
Code:
You don't have permission to view the code content. Log in or register now.
The output above has been truncated, there's lots more matches than those shown (since 8519 is simply the header for a section in a JFFS2 filesystem. If there's loads of files, there'll be loads of matches). The first column in the output above shows the position (in hex) at which the bytes occurred. So going from top to bottom, we can see that the first match (at 0287840) probably isn't the start of the JFFS2 section. It's not on a large memory boundary (most partitions split on high kilobyte or even megabyte boundaries, so there should be a few zeros at the right of the position. Secondly, the position in the file is far too early. Don't forget that before the JFFS2 section, there are cramfs and squashfs sections. There's no way these would fit this early.

So the next match (500000) looks like a possibility. In all the images I've seen so far, the split has to occur on a 100000 (hex) boundary, so 500000 is the correct point in this case. It may well be a different position for each image. For instance, DW 2.0 splits at 0x600000.

To split the file at this point, work out the decimal offset from its reported hex value (for instance, 500000 in hex is 5242880 in decimal) run:
Code:
You don't have permission to view the code content. Log in or register now.
Now you've got the jffs2 image, ftp it to /tmp directory on the dreambox.

Next, we need to set up the simulated flash chip. This is done in the kernel using an external module. It's not compiled by default for the dreambox, but I've attached the module to this post. It should work with any recent image (kernel 2.6.9, I tested with DW v2 and a Gemini image). Unzip mtdram.ko and copy it to your dreambox by ftp. Next, telnet into you dreambox and :
Code:
You don't have permission to view the code content. Log in or register now.
Provided everything works, you should see something like:
Code:
You don't have permission to view the code content. Log in or register now.
You can see that a new device has been created, mtd7, which is our simulated flash. The next step is to copy the image into it:
Code:
You don't have permission to view the code content. Log in or register now.
DO NOT DO ANYTHING WITH mtd2 OR mtd4. YOU COULD KILL YOUR DREAMBOX!!!
Finally, you can mount the image with:
Code:
You don't have permission to view the code content. Log in or register now.

Once this is done, you can change whatever you want within the mountpoint/ directory. To change the password, you need to alter the /tmp/mountpoint/etc/passwd and replace the hashed password for root with whatever you want (google around to find out about the file format).

Once you're finished making your changes, change out of the directory and unmount it:
Code:
You don't have permission to view the code content. Log in or register now.
Next, copy the changed partition back out to a file:
Code:
You don't have permission to view the code content. Log in or register now.
FTP this file back to your main PC, and copy the full, unmodified image as, e.g. change-full.img. Finally, to re-create your full image (cramfs+squashfs+jffs2), but with your newly changed jffs2, do the following:
Code:
You don't have permission to view the code content. Log in or register now.

That's it, you've got your modified image ready for flashing. I know the above looks complicated, but with a bit of practice and experience, you can do it fairly quickly. And in some cases (such as the password problem mentioned), it's the only way (I know of)to fix an image.

On a side note, I know that if your image is passworded, you won't be able to telnet into the dreambox to do the above. However, if you're wanting to use the above method for changing the password, you can backup the image (with e.g. dreamup or other), then flash another image (e.g. DW2), make the changes to the backup image, then reflash with the newly modified image. A bit awkward but it'd get the job done.

To be honest I don't expect many people to do this, but I think it's worth sharing the knowledge. Afterall, I've seen at least two threads asking for password changes on locked boxes, and there must be many other reasons why you might want access to the /var jffs2 section in an image, but you don't want to flash it to a box.

Have fun.
 
Last edited:
Hi mate

Just got round to giving this a bash.

Got everything set up but can't seem to get it to contact the tftp server.

Code:
You don't have permission to view the code content. Log in or register now.

My dnsmasq settings:

Code:
You don't have permission to view the code content. Log in or register now.

Any bright ideas?
 
Have you checked that tftp is working? For the boot to work, in your case you must be able to:
Code:
You don't have permission to view the code content. Log in or register now.

The error is that it's not getting the kernel. Check the logs on the tftp server (using weither logread or dmesg). It should have something about recieving the request).

edit: misread your config, and put the wrong IP in. Should be right now.
 
Last edited:
tftp server is fine as I can grab the u-boot from my windows box using tftpd32.

Code:
You don't have permission to view the code content. Log in or register now.

but no request gets recieved from the dbox?

dnsmasq log:

Code:
You don't have permission to view the code content. Log in or register now.
 
Strange. I've had the same error with 'no space left in packet' before. It didn't seem to matter. Maybe you could try removing the nfs root option, just for now to see if you can grab the kernel.

So do you get nothing at all in the logs of Mybook when you boot the dbox? What tftpd are you using? Can you turn on verbose logging? And is it definately listening on the default port 69?

As you know, I've never done this with a dbox. I'll have a look around.

edit:
Those debug messages shouldn't be a problem. The first looks like it doesn't understand the netmask setting, the other two are name server and gateway addresses. Can you install a network sniffer? What router have you got? MAybe you could install tcpdump on it. The we can have a look at what's going in and out. Same goes for the MyBook (which might be more useful, but I don't know if it's possible)
 
Last edited:
For some reason the edit button has disappeared, so I've got to post a new message. One more thing to try might be to use a different tftp server. You mention you've got tftpd32, so it might be worth pointing your dnsmasq at your windows machine and trying it that way.

edit: That's strange, I can edit this post, but not the one above.
 
im having a go at this and cant seem to find mtdram.ko, anywhere. Can any 1 upload it please
 
Back
Top