Mtk Nvram Tool

[Hildegard Mccauley]

OnMac OS X there is a tool called nvram to get and set EFI properties. As I am now deploying GNU/Linux on Apple hardware, I'd like to have a similar tool that is able to talk to Apple's EFI implementation.

I run Archlinux from a portable disk which I can use on my workstation, laptop, etc. I want to write an entry containing a number (or if possible a string) which allows my portable system to detect the computer it is being booted on, to for example load different configurations (e.g. graphics driver or multi monitor setup). I want the identification to be based on the mainboard.

In UEFI systems, there is a general-purpose NVRAM which is accessible through "EFI variables", which Linux exposes through /sys/firmware/efi/efivars. You can create custom EFI variables and some programs already do so, e.g. you'll find a few variables created by systemd-boot. It might be better to use the efivar tool if you want to do this (there's also efibootmgr specifically for the Boot#### variables).

Im running a Netgear r7800 and finally moved from kong dd-wrt to Openwrt. I have been experimenting with the different builds, Kong and Hnyman including the trunk versions. I have been only doing a "perform reset" in between these builds but have noticed residual packages still floating around in the filesystem. Matter of fact, when I enabled https in Hnyman build, the cert showed CN=Kong? In dd-wrt, I would do a erase nvram command, will this work on the openwrt partition? I have seen other topics mention sysupgrade-n or firstboot but are those just another variation of perform reset?

thxs

jffs2reset is part of the fstools package (you have to install this probably). after this all additional installed packages and taken settings should be purged. jffs2 partition is recreated during reboot.

There is no nvram tool for OpenWrt available. It is a DD-Wrt only tool.

Basically both tools erasing the flash space where the permanent settings are stored. Maybe that nvram has more functions. If you want to know more ask or search about the flash layout of this device:

So I ran the commands...after the jffs2reset I got a /dev/ubi0_1 is not mounted

/dev/ubi0_1 will be erased on next mount

writing /dev/ubi0_1 failed bad file descriptor.

reboot and nothing changed

Any ideas?

I had Windows 10 on it but when i have reinstalled Windows on it, nothing worked (sound, touchscreen, Wi-Fi and Bluetooth) and i have tried Zorin 17.1 Core on this device. It boots and runs great on live USB key but when i try to install it shows an error: Execution of "grub-install /dev/mmcbik1" has failed.

I have read some topics about this error and they suggest me to live boot on Zorin 17.1 and try to repair the boot with the boot repair tool what i have done but this tool shows me an error too "Locked NVram detected". This device is disabled on secure boot and this is the only option available in the BIOS.

I don't know how to have Zorin 17.1 Core on this device when with Zorin 16 Core i have not any problem even with the automatic partitionning.

I must have Zorin 17 Core because of the tablet style menu, i have not this option on Zorin 16 Core and Zorin 16 Pro shows error for disc full even on lite pro version.

I thank you in advance for the help you can provide me.

An engineer here on these forums suggested I try a iP recovery tool which I did. It could not find the nvram to even try. I understand what nvram does but not much more. I was upgrading HDDs just before that and I nuked those too. When I tried to re-install the OS, it couldn't find any drivers. I swapped back to the old drives and everything seems to run fine.

If there's one person who will push their hardware to the limit, it's me. In early 2015, I purchased a Lenovo Ideapad G50-70 machine, which I've wholly dedicated to software testing,including many a Linux distro. Fast forward two and a half years, things have changed.

So what happened? The way I always do, I downloaded a fresh distro ISO, wrote it onto a thumb drive and thencycled the laptop, so it would boot from the external device. Only this did not happen. The device wasn'trecognized. What. Me no likely. Thinking there was a problem with a particular version of Etcher, the software of choice for the data writing task, I tried an older version of theprogram, with the same result. Tried a different thumb drive. Nope. Tried three different distributions, two ofwhich are actually installed on the box, nothing.

The plot thickens. I cannot recall the full sequence of thoughts and ideas that transpired, but I decided tofocus on the software side of things first, before doing any further hardware-related troubleshooting.

At the moment, the distro in control of the complex multi-boot setup that I have on the machine is openSUSE Leap 42.3. I recalled that, during the installation, it actually asked me ifI wanted to enable Secure Boot support, and if this could perhaps be the reason why the system is refusing anynew boot devices. That does not really sound like it, because there are other distros with valid, signedimages, but still. I changed the setting, rebooted, nothing.

All right, well, I decided to actually set up Kubuntu Zesty as the distro incharge of the laptop's multi-boot environment, just to make sure it is not openSUSE that is wonking the wholedeal. I already had a feeling it would not help, but you must work slowly and patiently, so that you do notmiss anything. Right. Now, as I've already shown you in my GRUB & EFIrecovery tutorial, there are many ways you can go about restoring the bootloader, and then, while doing it,I saw this:

Not good. I also tried using the efibootmgr directly, and got the same error message. At this point, I wentonline, and found a few references to this issue. Strangely, or not, a bunch of openSUSE users were complainingabout this very same thing, and how they were unable to make changes to their UEFI setup, resulting in similarfrustration to mine. But not exclusively. Arch, Debian, Fedora, you name it.

I then tried to make any which change in the UEFI menu, to see if that would make any difference. Predictably,no matter what I did, the change would not stick after the reboot. It looked like the NVRAM had gone read only.

Well, I tried a few minor hardware tricks - remove the battery, hold the power button pressed, those types ofinnocent games. I also tried to re-flash UEFI, unfortunately the BIOS versions matched, and the Lenovo utilitywould not let me do that. I even contacted their support, asking for additional diagnostic tools that I mightuse, but all they did was provide KB articles that are already public and download links to stuff you can getyourself.

I managed to find an older version of the BIOS tool - even though it was tricky business searching for that,but again, the utility refused to flash a version that's older than the current one. I haven't found a way toforce the process. It's a no go.

So at the moment, I have a fully functional laptop with a fixed configuration. This means that I cannot use it for new distro testing - I can use itfor in-vivo upgrade tests, and of course, a range of software-related tutorials and topics. Actually, I can,but this is a topic for a separate article, and it's quite dangerous. More about that later. Anyway, the setupremains as it currently is, and it includes, in the partition order:

So I have a very interesting eight-boot setup. Not something most people will ever do or configure. And I'veprobably installed about 200-300 distro instances over thepast two and a half years. Add to that occasional bootloader updates, bootloader order changes, plus the factdata is flashed into NVRAM in multiple chunks, each of which introduces tear to the little strip of memory.We're talking roughly a thousand flashes or more. So I've probably worn the semi-conductor band naked, andthere are no more electrons left.

Most techies (ordinary folk just use whatever is there) will probably submit their laptops, over their typicallifetime of about three to five years, to a tiny handful of installations. Not more than ten. I have exceededthis number by about two orders of magnitude. We're talking 300-500 laptop years of UEFI abuse, and that's thelikely reason for this little fiasco.

This also means - for the time being - until I decide whether to buy a fresh new test machine, I will beperforming new distro testing on my older LG RD510 machine, as you'vealready seen with Antergos and some others. It's only going to be dual bootwith an aging processor, but maybe slightly more interesting due to the performance constraints and thepresence of an Nvidia card. I will still do all the cool bits and pieces. No UEFI and probably no hardwareproblems with the network. But I shall endeavor to give you thorough, detailed and honest reviews. Also I amsure going to buy some new hardware, and then we will be back to pain and bugs and drama.

One other thing - my writing queue is very long. We're talking about three months worth of articles alreadywritten. Some of them have been completed while the little G50 was working well, so bear that in mind. Itshould be interesting. And fun.

While writing this article, I had a thought. Maybe, if one is conducting a copious amount of testing with lotsof firmware flashing, using the Legacy mode might be helpful. It means no UEFI mode, but perhaps that's notthat bad. In general, the whole flashy thingie also applies to routers. Every time you change a config, a celldies. Remember that. Anyway, G50 becomes a special test case, and the oldster LG returns with a bang. Until aworthy successor to the throne is found. Tux Vivat!

3a8082e126