I have followed your protocol for 64k-wheezy and it has worked great for a number of packages, but now I think I have run in to a problem case. I wonder if you might evaluate?
I’m not a guru, but I know libstdc++ is a foundamental core library… I fear that even if you succeed at compiling it, installing on the My Cloud may break something. Why do you need to rebuild it? Are you sure you need?
I agree with you that the conflict might be in the binutils package, but if I remember well a patched binutils is needed for 64k-wheezy to build packages… Maybe rebuilding binutils itself before libstdc++ would make the trick, but, once again, I don’t know if this is going to work once you install packages on the My Cloud…
Agreed, dependencies can be nightmares on the build box, need not mention on the target WDMyCloud. Previously I upgraded some libs and it failed at some point, even simple ls won’t work. I had to open up the NAS, link the HDD to a PC and dump a fresh firmware image.
But if you just wanna try out, I assumed you’re at the failure built point, do below and have a t-break:
cd ~/wdmc-build/64k-wheezy
chroot build
mount -t proc none /proc
mount -t devtmpfs none /dev
mount -t devpts none /dev/pts
export DEBIAN_FRONTEND=noninteractive
export DEBCONF_NONINTERACTIVE_SEEN=true
export LC_ALL=C
export LANGUAGE=C
export LANG=C
export DEB_CFLAGS_APPEND='-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE'
export DEB_BUILD_OPTIONS=nocheck
cd ~/gcc-4.7-4.7.2
dpkg-buildpackage -d -b -uc
Agreed, dependencies can be nightmares on the build box, need not mention on the target WDMyCloud. Previously I upgraded some libs and it failed at some point, even simple ls won’t work. I had to open up the NAS, link the HDD to a PC and dump a fresh firmware image.
Just in case I ever need it… what’s the procedure to “dump” a fresh firmware image from a PC?
Agreed, dependencies can be nightmares on the build box, need not mention on the target WDMyCloud. Previously I upgraded some libs and it failed at some point, even simple ls won’t work. I had to open up the NAS, link the HDD to a PC and dump a fresh firmware image.
Just in case I ever need it… what’s the procedure to “dump” a fresh firmware image from a PC?
I posted this not long ago, 2 days after I got this NAS :
Has anyone tried using https://build.opensuse.org/ ? I know they now have http://en.opensuse.org/Portal:Factory which allows you to build arm7 packages. Might take a little work to get it setup for what we need here but once it is done should be easy to build other packages.
Just to let you know, your suggestion worked. After 1.5 days of rebuilding the libstdc++6 package in a Debian Wheezy VirtualBox, I installed the .deb package on the MyCloud and it is now back to normal. (I had done an apt-get upgrade on my MyCloud before I knew that that was a bad thing to do since the Debian on the MyCloud is nonstandard. libstdc++6 was upgraded and the upgrade broke stuff. Reinstalling the downgrade that I built reverted my MyCloud back to normal.)
Has anyone tried using https://build.opensuse.org/ ? I know they now have http://en.opensuse.org/Portal:Factory which allows you to build arm7 packages. Might take a little work to get it setup for what we need here but once it is done should be easy to build other packages.
I guess that let’s you prepare pacakges for a standard OpenSuse distribution for ARM. The My Cloud uses a customized Debian distribution, so different distribution, different package manager and further customization from WD. This is why rebuilding packages from source is needed.
First of all thank you mauromol for this guide it is very helpfull and works perfectly.
I would like to ask if anyone has succesfully compiled “mc” as for me the compile ends in error, with the following:
make[4]: Entering directory /root/mc-4.8.3/lib/event' CC libmcevent\_la-event.lo cc1plus: warning: command line option '-Wdeclaration-after-statement' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wimplicit' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wmissing-parameter-type' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wnested-externs' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wpointer-sign' is valid for C/ObjC but not for C++ [enabled by default] CC libmcevent\_la-manage.lo cc1plus: warning: command line option '-Wdeclaration-after-statement' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wimplicit' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wmissing-parameter-type' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wmissing-prototypes' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wnested-externs' is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option '-Wpointer-sign' is valid for C/ObjC but not for C++ [enabled by default] manage.c: In function 'mc\_event\_callback\_t\* mc\_event\_is\_callback\_in\_array(GPtrArray\*, mc\_event\_callback\_func\_t, gpointer)': manage.c:217:35: error: invalid conversion from 'gpointer {aka void\*}' to 'mc\_event\_callback\_t\* {aka mc\_event\_callback\_struct\*}' [-fpermissive] make[4]: \*\*\* [libmcevent\_la-manage.lo] Error 1 make[4]: Leaving directory /root/mc-4.8.3/lib/event’
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory /root/mc-4.8.3/lib' make[2]: \*\*\* [all-recursive] Error 1 make[2]: Leaving directory /root/mc-4.8.3’
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/mc-4.8.3’
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
Build command ‘cd mc-4.8.3 && dpkg-buildpackage -b -uc’ failed.
E: Child process failed
From the messages i guess it is something with the compiler or a missing depency.
I have also tried with the optional step of an updated C++ compiler but still no luck.
Have you updated the QEMU package? If you did and still having issues, means you’re out of luck. Then you’ll need to cross-compile, see my guide from the 1st page. Me too have difficulties trying to build java, postfix and dovecot.
I’ve successfully built mc from wheezy suite. Are you trying to build it from jessie?
Anyway, meanwhile I’ve patched myself a couple of scripts provided by WD in order to make the build process work better. Also, I had to rebuild binutils which in turn is needed to successfully build other packages from the jessie repository, otherwise a newer non-patched version will be downloaded and used, causing the built package to fail once on the device. When I have some time, I will update this guide.
Until now, there are also two packages I was not able to build:
spidermonkey-bin from wheezy suite: apart from the fact that the build process requires GBs of disk and RAM (it needs to compile the whole IceWeasel package), QEMU segfaults at a certain point
transmission-daemon from jessie: again. QEMU segfaults
Talking to the QEMU guys, it seems like there are use cases in which the QEMU emulation does not work appropriately and causes segmentation faults.Unforunately, these cases are well known and should be related to the use of multi-threading. There won’t be improvements in the near future on this area… The alternative would be to prepare the My Cloud device itself for building, but it’s too much work.
Fortunately anyway, apart from these two packages, all the other ones I tried were built successfully (including all the direct and indirect dependencies): transmission-daemon (from wheezy suite), amule, ddclient, htop, inadyn, iperf, mc (from wheezy suite), mldonkey, pyload dependencies (including the optional ones, except for the JS engine), rsync (from jessie), sabnzbdplus (including Python 2.6), unrar.
I’m fairly new with Linux, but comfortable using the command line and have noodled around a bit with the v3 firmware installed, having installed CrashPlan, Hamachi, and one or two other small packages successfully. My main interests–CrashPlan and Hamachi–came with drawbacks that weren’t worth it (CrashPlan transfer speeds to its cloud servers too slow; Hamachi worked great as an easy-to-install off-the-shelf VPN, but it rendered my Time Machine volume inaccessible by making the My Cloud’s hostname unresolvable for Time Machine, even after I added a line to the /etc/hosts list.) So I threw in the towel, decided those packages weren’t worth it, and updated to v4 firmware. wdmcserverd and wdphotodbmergerd are disabled, and everything’s running smoothly.
Here’s my issue: As a Mac user, I’ve found that mounting my shares using AFP (as old as it is) works really well. From what I can tell, the netatalk package that comes pre-installed on the My Cloud does a good job of managing this. As long as it’s databases aren’t corrupt (and they’re very easy to rebuild), and as long as I stick to AFP and not move/delete/rename files while using SMB or SSH, then netatalk keeps transfer speeds fast. And best of all it does a good job of preserving Mac file metadata. It’s worked great for me.
But the default netatalk installation is the outdated v3.0.3, and things get even better with the more recent 3.1.x, which introduced Spotlight integration. (Some Mac users find Spotlight really irritating; others like me love it, and in fact CrashPlan depends on it for real-time tracking of changes in the file system.) What I want to know is if it’s worth working with this guide to build/update netatalk to v3.1, or can I know ahead of time if this will lead to a dead end before I invest my time and patience in it. I’ve installed VirtualBox, got the VM all set up, and will try first building htop and maybe one or two other small things (hopefully useful ones–any suggestions?) to get my feet wet. I’ve got all my data fully backed up in so many places it’s hard to track, so I’m not worried about that. I’m aware of the warranty issues, etc.
I guess what I want to know specifically is whether, since netatalk is one of the WD-installed packages, there’s some WD mechanism in place that would actually make a rebuild/update of that package impossible, even if I took all the right steps. Have WD somehow locked in their default packages, or are they just being very loud and clear in their disclaimer when it comes to tinkering with their software? netatalk v3.1 has a lot of dependencies, most if not all of which I imagine I’d need to rebuild too. So this will take some time and work. I just want to know if you guys can see a dead end down the road that’s unavoidable. If that’s the case, it would save me a lot of grief if I knew ahead of time.
Thanks so much for this *terrific* guide and for any advice you can lend!
I don’t know netatalk and I don’t know how much “critical” is to the system health. Generally speaking, I would follow this path:
look at debian.packages.org and search for netatalk package: is your needed version available for wheezy or wheezy-backports? If so, it’s better to take it from there rather than from jessie, which is a newer system version than the Debian Wheezy installed in the My Cloud (packages from jessie may be harder to build/install)
how many “critical” dependencies does it have? For “critical” I mean dependencies towards important packages like libc or low-level tools/libraries that, once replaced, may lead the system to instability (in case WD made some customizations…). And, if you find “critical” dependencies, do the versions installed in WD satisfy the dependency needs? If so, it’s not necessary to rebuild them and hence there’s more chance replacing netatalk won’t hurt
if you want to risk, search for a guide to revive the My Cloud, in case anything goes really wrong (i.e.: the system does not boot anymore)
What I can say is:
I replaced rsync (although it came built-in by WD) to update it (building from jessie) and I had no problems, but rsync is not a “critical” package and does have few dependencies (which I had not to rebuild)
by re-flashing the firmware you will lose all your installed packages and customizations to /etc configs or such, so re-flashing the firmware is always a good option to restore the drive to its “factory defaults” if something breaks on the My Cloud, but this is doable only if the drive can boot
I would say: are the benefits really worth the effort? If so, you may try this path, otherwise I would make do with what the unit already has. Maybe one day WD will itself upgrade the built-in netatalk package
By the way, it seems like the netatalk package is just at version 2.2.x in both wheezy and jessie, how is you’re talking about 3.0.x and 3.1.x?
Thank you very much for taking the time to write up these tips in detail!
I’ll first check on the criticality by taking a closer look at the dependencies–thanks.
Would it be worth it…? So far netatalk seems a decent implementation of the Apple Filing Prototcol, which noticeably speeds things up for me and should reliably preserve OS X’s extended attributes. If v3.1 can be installed successfully, it could well be worth the effort if the the Spotlight integration works as advertised. (And the fact that the package is maintained as actively as it is puts me on the optimistic side.) OS X won’t index NAS volumes by default, and the methods suggested to enable that via the command line have proven unreliable for me and difficult to evaluate. So on balance, given that my multiple on and offsite data backpus are solid, I think it would be worth it. Plus I kind of want to see if I could just actually do it…
By the way, it seems like the netatalk package is just at version 2.2.x in both wheezy and jessie, how is you’re talking about 3.0.x and 3.1.x?
Interesting question! After I had experimented with a couple other packages on v3, I decided to “apt-get install netatalk” to see if it would just upgrade to 3.1. Weirdly, it downgraded it to 2.2! Fortunately I had checked the factory installed version before I did that, so I re-flashed the firmware to get 3.0.3 back. My guess is that the Debian repository stopped updating versions of netatalk, so it just installed what it had, which was 2.2. I’d think there’d be a check against accidentally downgrading, but I guess not. Anyways, after I switched over to v4 (since I wasn’t having any luck with the packages I wanted anyway), I’m taking care not to do that again. Netatalk’s installation instructions just direct you to their SourceForge page for the latest version, with a side suggestion to check out the usual suspects for for various distributions. Whether the fact that 3.1.x is not on the Debian packages list makes things more complicated for me, I don’t know yet.
Thanks again. If I’m successful I’ll note it on this thread. Yesterday I did post a request to include the latest in a future FW update on the “New Ideas” board; hopefully someone at WD pays it some attention…
So maybe WD has compiled and included a newer version of netatalk compared to what Debian is currently offering. In this case I think you’d need to build the newer version by yourself, ignoring (almost) completely this guide, which tells you how to download and build packages from the official Debian repositories. Unless the developers of netatalk maintain a source repository to add to /etc/apt/sources.list, in which case you may still follow this guide, but you’ll have to add the aforementioned repository URL in /etc/apt/sources.list of the chrooted guest system.
I’m not sure what’s so unclear about my target package, I’m trying to build imagemagick 8:6.8.9.6-4 at jessie into 64k size, so I commanded ‘./build.sh imagemagick’. What I REALLY need is libmagickcore-6.q16-2 and libmagickwand-6.q16-2, but trying to build them results in building imagemagick so it’s the same.
As for error logs, I don’t know how to save the whole log, so I’ll just paste what came out after all was over:
dpkg: dependency problems prevent configuration of php5-imagick:
php5-imagick depends on libgomp1 (>= 4.2.1); however:
Package libgomp1 is not installed.
php5-imagick depends on libmagickcore-6.q16-2 (>= 8:6.8.8.2); however:
Package libmagickcore-6.q16-2 is not installed.
php5-imagick depends on libmagickwand-6.q16-2 (>= 8:6.8.8.2); however:
Package libmagickwand-6.q16-2 is not installed.
so building from wheezy can’t help me…thanks for regards, but not much of a help here.
:
