Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Pages: 1
I upgraded my development machine to Ubuntu Feisty Fawn and now can't build a valid ramdisk image. It is very confusing. Has anybody else run into something like this?
Offline
If you're talking about ramdisk for Ubuntu, be aware that it's using cpio to create ramdisk.
Offline
At least in the case of the DSM-g600, you are mistaken, prior to upgrading my development machine I was building fw images that worked just fine. In fact others have used them.
Offline
remember this is not a standard desktop system...it is not an initrd image.
It fails when trying to upload (using thye web interface) the firmware image. As best as I can tell, the ramdisk image is too big (because the kernel is the same size). I have eliminated my program fwbuild and mkimage which is built from the u-boot sources. It also does not seem to be genext2fs. What is confusing to me, is that using the Build_DSM-0.4 tarball that I used to build the 0.4 firmware used by others, I can no longer build a usable fw image.
If you want to know how I did it, grab the tarball from http://dns323.kood.org/downloads/people … SM-0.4.tgz though I warn you it's a pretty hairy bunch of makefiles.
Offline
Well I don't yet know what it is, but I can confirm that it something in the build environment. I installed Ubuntu Edgy Eft in a vmware virtual machine and I can build 0.4 that loads and runs just find.
hmmmmmm!!! very strange! I suspect a library issue.
Offline
Just offtopic, beattie have you tried Gentoo linux? Its way better than debian (ubuntu). Some year ago I did use debian for all my pc's mainly because of package manager, but more and more I did find myself with some package/library conflicts and absolutle no control over these situations. But now with gentoo not any more
Offline
My first thought was that it might be gcc3 vs gcc4, old tar vs. new tar problem or so, but couldn't find anything in the sources that would support this. Still I don't think, switching to gentoo helps much. I don't like debian, too, but I think this is rather a problem with the toolchain, not depending on who packages the software.
beattie: have you checked (using hexdump) whether the fw-header is correct? I ask because there's no "__packed__" attribute, allowing the compiler to realign fields in the structure...
Offline
The firmware header looks ok, the only thing I see is that the ramdisk image is bigger, in fact I can build a firmware image that works, by stripping things out, so it's not a "bad" image, just the image is too large.
Offline
Pages: 1