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...
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.
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.
Thanks, Sandshark. I guess I should have been clearer about my setup: My 6-bay ReadyNAS devices have been running on Core2 Duo E6600 SL9ZL CPUs with the 07/26/2010 BIOS since early 2013. They're functional, but the BIOS only brings them up to update "cb" while Intel's microcode-update package will bing them to "d0".
More news on my progress:
I now know just enough about initramfs and the syslinux loader to be really dangerous. Yesterday I discovered that syslinux since version 3.71 has had the ability to load multiple initramfs files specified in the SYSLINUX.CFG file, so I planned to use that facility. Unfortunately, I later discovered that syslinux on my boot flash is only version 3.31:
root@NAS3:/media/INT_FLASH# strings ./LDLINUX.SYS SYSLINUX 3.31 v1.07 Tue Feb 15 11:31:02 PST 2011 fBf9 Load error - Debug Serial Port Enabled ....
So that idea's a non-starter.
My current plan is to modify a copy of the existing initrd.gz to include kernel/x86/microcode/GenuineIntel.bin so everything can be loaded at once, in the single file that syslinux 3.31 supports. I've unpacked the existing LZMA-compressed initrd.gz into a cpio achive, unpacked that into the initramfs directory tree, added the kernel directory, and repacked the tree into a cpio archive. But now I'm stuck because lzma has a ton of options and I haven't found the right ones to replicate what Netgear used for their initrd.gz.
So I have two new questions:
1. Executing "file" on Netgear's original initrd.gz produces "initrd.gz: LZMA compressed data, streamed", and 7-Zip identifies the compression method as "LZMA:26". Does anyone know what lzma options will produce that format?
2. Alternatively, does the initramfs file on the boot flash even need to be compressed with lzma, or will syslinux load a raw cpio archive?
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.
If you want to use this modification you're going to have to redo this work for every firmware update you wish to install.
The reason we compress the initrd cpio archive using lzma rather than gzip is to keep the size of the download as small as we can. It also allows for more potential growth in the size of the firmware over time whilst still being able to fit it on the internal flash.
Devices that shipped with OS6 have a newer syslinux bootloader.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
