NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
6.9.5 GPL not posted.
OOM-9
https://kb.netgear.com/2649/NETGEAR-Open-Source-Code-for-Programmers-GPL has a link to 6.9.5 GPL, but the zip itself hasn't been posted yet. https://www.downloads.netgear.com/files/GPL/R...
Hi StephenB,
The 6.9.5 GPL zip file has been posted already. You should now be able to download the file.
Regards,
Hello,
can you share the command to install the Kernel ?
"make install" is it enaugh ?
Unfortunately it isn't as easy as a simple "make install". Basically you'd need to make the normally invisible USB flash drive (that's where the kernel of the ReadyNAS is stored) accessible from the OS. Then you have to manually copy the newly built kernel over the original one, adjust some checksums, then unmount the flash drive, reboot and pray that it works - otherwise you may have either to recover from USB or even have bricked your NAS.
That's also why you'd have to take utmost care when building the kernel. A good idea would be to NOT have anything built right into the kernel but using modules wherever possible. But even then you're not 100% safe since some modules silently enable other kernel settings which as a result may leave you with a disfunctional kernel.
In essence: To prevent users without the proper knowledge from accidentially bricking their system by trying things they don't fully understand I won't post a list of commands here. I'd rather prefer to make the new environment work so everyone can safely build kernel modules without the risk of creating a 2-6 disk paperweight.
-Stefan
This obstruction to building modules is not a small issue for customers who need support for a particular device or want to add features to their machines. For 6.10.x, Netgear needs to make a bold notice to let potential upgraders know that there currently is no easy path to customizing modules or the kernel at this time, and no easy path to downgrade from 6.10.
Will the build environment to make this work be downloadable or redistributable?
I'm sure Stefan can come up with a reasonable process to compile with the tools he's been given, but there's no need to make users jump through hoops to customize their gear. I'm also sure this mess is to prevent tampering with the kernel or encrypt and sign some proprietary pieces of software or some blustery nonsense like that, but like all DRM, it only serves to place barriers and traps for legitimate use.
In any case, I'm eager to either see your results or figure out a safe procedure to do this myself, because I rather like having VirtualBox installed, and there's no reason I shouldn't be able to compile some GPL drivers for this GPL kernel, GPL it!
Unsurprisingly, there's very little information as to how to mount the flash memory from a running system. Maybe it's visible from BusyBox, but I usually had other concerns if I was using that mode.
Then, like you're saying, you have to trust that there are no errors in the .config and that you can produce an identical kernel to the one shipped with the OS with no loss of reliability or function. However, if we're going by history and the mistakes and inconsistencies with source archives in the past, that does not instill confidence in the procedure for the future. One should not have to put their NAS at risk to compile a module that works.
Maybe we should drop RMS a note explaining the situation...
Sorry for the long delay but I was caught up in work. Important things first: I got the new build environment to work and was able to build a kernel and modules. Unfortunately, even with the new build environment, the result stays the same - modules created that way can't be inserted in the running kernel.
I tried to get more information and also the
.configfile actually used for building the kernel shipped with firmware 6.9.5 but unfortunately the guy from NTGR I was in contact with stopped responding.That said, I don't think this change (and the resulting problems for developers) were made intentionally. I can see that the new build environment is based on Debian "buster" and from NTGR's perspective it makes perfect sense to use that one to get the latest compilers and better support for newer ARM processors (do I hear speculations about new models? ;)). However, NTGR also should keep in mind that at least a percentage of users is picking the ReadyNAS over the competition exactly because of it's open and easy to extend architecture based on Debian as well as the consistent hardware line-up. I know of no other brand where you can morph your NAS into an automated VCR that easily, add VirtualBox or other stuff. Even app development is a lot easier on the ReadyNAS compared to other offerings and I know of a lot of businesses where those apps are in production use.
Until now one could even attach special hardware to the NAS by just building the needed kernel modules without having to fear one would break something because either the module could be loaded into the running kernel or not - but there was no chance to break the kernel or the NAS by having to replace the kernel. With the current change this is no longer a given.
Since I still believe the problem lies with the
.configfile shipping with the GPL my suggestion would be:- ship the next versions of the firmware with the
configs.komodule either included in theroot.tgzor compiled in to the kernel. The support for the/proc/config.gzcopy of the kernel config file is enabled in the firmware since ages anyway, so why not provide the tools to read it? - provide a consistent method along with descriptions and how-tos for building kernel modules and maybe .deb packages based on the build environment
- allow for downloading the current build environment by interested external developers
itachi2 I don't think this has anything to do with DRM or other dark schemes either, since to my knowledge nothing on the ReadyNAS is signed / encrypted in any way beyond what's already done in a standard Debian environment. Even less since you don't even need to sign packages (although I do) to have them installed on the NAS. I don't think that the problem we're currently facing was created intentionally. Rather NTGR didin't think that anyone would use the ReadyNAS beyond the use cases they and their marketing figured it could be used for ;)
-Stefan
Thanks a lot for the spent time to investigate this. This is a big issue now because that means I have to stay an 6.9.4 on all our devices. Being able to compile custom kernel modules is crucial and was the main reason to go with a Netgear device.
I can only hope Netgear will fix this problem in the future.
- ship the next versions of the firmware with the
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
