NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Solved
Problem getting Intel microcode to load early on my Frankenstein NAS
So... After running multiple legacy ReadyNAS boxes on OS4 for 5+ years, I've decided to upgrade to OS6. I wish I knew who made the decision to include software support for legacy devices in OS6 (and also, btw, to ship a security update for OS4 after the "final" 4.2.28 release), because that person is awesome.
Anyway, here's my situation: The upgraded E6600 CPUs in my 6-bay boxes want microcode updates that Intel first made available on 9/30/2010, but they can't get the microcode in the usual way -- from the BIOS -- because the latest BIOS for those boxes is dated 7/26/2010.
Fortunately, Linux has a solution: There's a set of packages -- iucode-tools and intel-microcode -- that can load microcode updates into the CPU at boot time (or anytime afterward, although obviously it's best to load the updates as early in the boot process as possible). Unfortunately, those packages require support from the kernel, and OS 6.6.1's kernel was built without that support (probably because the current-production ReadyNAS devices are still getting BIOS updates).
Ok, so I fired up Google and learned how to build the Linux kernel. Compiled it with built-in support for microcode updates, then copied it to the internal flash as an additional boot-menu option (thanks to IcyK's genius post for that idea) and it booted up just fine. I installed the Debian microcode packages and used the tool to update the CPU microcode from the command line; that worked fine, too.
But here's the problem: Updating the CPU's microcode after it's already executed a few billion instructions isn't very safe. To get the kernel to update the microcode at the safest time (i.e., as early as possible, right at the start of the boot sequence), all the instructions on the web say that the microcode update must be added to the initramfs. But those instructions also all say that the initramfs file is in the /boot directory, and on my machine there's nothing in that directory at all.
There's an initrd.gz file on the internal flash, but the update-initramfs tool doesn't recognize it. Maybe I'm misusing the tool (I probably am), but I don't even know whether that initrd.gz file is used by OS6 or is just a vestigial artifact from my box's original OS4. I have no idea how a new (RN516, etc.) box's boot flash compares to mine, and I don't have a new box to look at. Plus I don't really understand my box's boot flash, anyway.
So three things:
1. If anyone's modified the initramfs on a legacy NAS running OS6, I'd love to know how to do it.
2. If there's a way to get the early-microcode hook compiled directly into the kernel, I'd love to know how to do that, too. My microcode updates are from 6+ years ago; there aren't going to be any newer ones for these CPUs, so hard-coding them into the kernel would be fine.
3. If anyone from Netgear sees this... So long as you're releasing unsupported code for legacy devices anyway, I hope you'll consider adding some even less-supported features to future builds -- specifically, kernel options that would benefit those of us who love our old ReadyNAS boxes so much that we've installed not only a new OS but also a new CPU. Things like this early microcode-update support, explicit Intel Core2 support, any optimizations for compatible CPUs newer than the original legacy E2160 but older than the currently shipping Corei5 (or whatever), etc.
Ok, I've answered my own question. It is NOT necessary to lzma-compress the initramfs file on the boot flash.
As described in my previous post, I created a cpio archive just like the one inside initrd.gz, except that it also contains the /kernel/x86/microcode/GenuineIntel.bin file with my CPU's microcode update. Copied it to the boot flash without lzma-compressing it first (called it "initrduc"), edited SYSLINUX.CFG to load it along with my new kernel ("k4-1-30.uc") as a boot-menu option, and boom:
root@NAS3:~# dmesg | head [ 0.000000] microcode: CPU0 microcode updated early to revision 0xd0, date = 2010-09-30 [ 0.000000] Initializing cgroup subsys cpuset [ 0.000000] Initializing cgroup subsys cpu [ 0.000000] Initializing cgroup subsys cpuacct [ 0.000000] Linux version 4.1.30.x86_64.1 (root@NAS3) (gcc version 4.9.2 (Debian 4.9.2-10) ) #2 SMP Tue Jan 17 01:33:26 PST 2017 [ 0.000000] Command line: initrd=initrduc reason=normal BOOT_IMAGE=k4-1-30.uc [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] Disabled fast string operations [ 0.000000] e820: BIOS-provided physical RAM map:
Now my NAS not only has a CPU updated to the latest microcode, it's also running a kernel built specifically for its hardware (Core2 Duo CPU, Yukon2 Ethernet chip) and with a few other optimizations for that hardware.
If everything's still running fine a few days from now, I'll make this kernel/initramfs combo the default, and make the original combo a boot-menu option. Then I'll run through the process again for my main NAS, and maybe also for the Atom D525 in my little Ultra 2 Plus.
11 Replies
1. Modifying that would require building your own /init for it as well, I think
2. I think it would be unlikely that that would happen. The number of users that would benefit would be quite small. Unsupported unit for OS6 with an unsupported CPU upgradeThanks, mdgm.
Your comment helped me to find what I think is a way to do what I want, and it's actually super-easy. I'll try it after lunch and post an update here.
And, yeah, I agree that it's unlikely that OS6 will include kernel features not only for products no longer supported by Netgear, but also for products that were NEVER supported by Netgear... But I made the suggestion anyway, under the basic principle of "It can't hurt to ask".
There is a BIOS update that runs on OS 4.2.x that lets other CPU's run OS6. I have the E6600 on two of my units and an E7500 on one. I've seen instructions for updating by extracting the update from the .bin package and using Linux toold to update, but downgrading back to 4.2.x and using the .bin package could be easier. Just put in a small spare drive to downgrade, update BIOS, and go back to OS6. I'm afraid I don't have a pointer to the package, but it's called BIOS_Update_Package_0.5-x86.bin, so try a search.
There were some very early Pro BE and Pioneer units that have a different revision motherboard, and you are out of luck if you have one of those. But I don't think that one ran the E6600 even on OS4.2.x.
Take a look at bios_ver.log in the logs download .zip. If it says 10/03/2008 FLAME6-MB V1.6, as most of the Pro BE/Pioneer units did, you are in luck. The update will move you up to 07/26/2010 FLAME6-MB V2.0, which has the required microcode. If it says something else, you are on your own. But the package seems to be pretty good at recognizing your system and only updating when it can.
The system is already running the 07/26/2010 BIOS as stated in the opening post of the thread.
Hmmm. I missed that.
Maybe he mistakenly got the Pentium E6600 instead of the Core 2 Duo E6600. The Pentium does need additional microcode over the Core 2 Duo. I have two that are running the Core 2 Duo E6600 and they need no microcode mods, even with the previous BIOS version. I have no idea what Intel was thinking re-using the E6600 moniker,
Besides the microcode issue, the BIOS may not select the proper frequency multiplier for that Pentium chip. The Core 2 Duo E7500 is definately a better choice than the Pentium E6600 for a ReadyNAS. Similar performance with full support in the BIOS (provided you have the latest update). They're under $5 on eBay these days. I got the E6600's when the E7500 was a lot more. The E7500 is a huge step up from the Pentium E2160 in the original Pro BE/Pioneer. Not as much from the Pentium E5300 of the Pro6/Ultra6Plus. The Core 2 Duo E6600 is still a sizable step up from the E2160, but negligable from the E5300.
FWIW, the datasheet on the E5000/E6000 says "The Intel® Pentium® dual-core processor E5000 series operates at a 800 MHz FSB frequency (selected by a 200 MHz BCLK[1:0] frequency). The Intel® Pentium® dualcore processor E6000 series operates at a 1066 MHz FSB frequency (selected by a 266 MHz BCLK[1:0] frequency). Individual processors will only operate at their specified FSB frequency."
That last statement differs from the usual "Individual processors operate only at or below the rated frequency." (which is what's in the E7500 spec sheet.) Perhaps Netgear chose an E5000 series for the newer systems over an E6000 because the motherbord won't do a 266MHz BCLK needed for the 1033MHz FSB.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
