I have a dual boot system with windows10 and manjaro linux on different SSD’s. A few months ago my Windows10 activation failed and I could not re-activate. I test installed a Win8.1 on another disk, activated it, ran for a few days and booted back to Manjaro, when I returned to the Win8.1 - deactivated due to key used on another PC!! (well it was really the same PC with a different BIOS UUID). I have found that when manjaro powers down (not sleep) it generates a new UUID in the SMBIOS. Of course this breaks the Windows activation as it thinks the motherboard has changed.
I cannot for the life of me work out how this happens. I had another old test manjaro on another partition, and it doesn’t do it. Initially I thought it might be something with the BIOS-GPT boot I was using, but I changed it to UEFI-GPT and still have the problem. Does anyone have any idea about what service could even do this? I have compared all of /etc/*,systemd files, udev rules between the 2 manjaro systems and cannot find anything that looks out of place. I read the system uuid using “dmidecode | grep UUID” or “demidecode --string system-uuid” and redirect to file. If I poweroff with hard press button restart, then UUID is the same after bootup, or if I boot to windows and check, or another linux, it stays the same, but if I restart the SMBIOS UUID will change. I had even thought maybe it had some VirtualBox code running that made it think it was a guest OS, and it was changing the real SMBIOS not the simulated VBox one, and uninstalled it, but no change. Yes I was desperate at this point.
Manjaro: Cinnamon rolling release 20.2.1
kernel: 5.10.15-1-MANJARO (have tested 5.4 kernel with same result)
MB: Gigabyte H77M-D3H
Bios: F14 (have downgraded to F12 but no change)
System: i7 2600 + 16GB
Has anyone else experienced this problem? It wouldn’t be obvious unless you duel boot to windows and find that its deactivated.
I have read about bad EFI implementations especially boards with early intel versions.
Usually from Win8 and onwards the Microsoft activation key is stored in the firmware. Only installations done by hand will create an identifier based on hashed values from system components.
Just an update after further testing. I reset the cmos by doing the short circuit pins method, and as soon as I rebooted, set BIOS to defaults, and booted to windows10 it immediately activated itself. Whoopee!! This fixed a couple of issues for me, I could now pull out the original registration key, and I didn’t have to find the root cause of why the Manjaro instal causes this. I had the original UUID read from an onld dmidecode dump and thought I would have to somehow get that back into the BIOS\NVRAM to make windows register again. But clearing the CMOS fixes it everytime.
I still don’t know what it is inside Manjaro that does it, but I should be able to reinstall, and then copy all config and home from backup (Vorta and borg), and hopefully the problem will be gone. My other test Manjaro works fine, but has a lot less software installed.
In my original fault description above I believed the problem was triggered at exit\reboot of manjaro, but that isn’t true, I believe the cmos\nvram corruption actually happens during the startup when the kernel is reading the cmos and nvram and mapping them to /dev/mem, dev/nvram, /sys/firmware/acpi/tables/ and /sys/firmware/dmi/tables/ . If I do a dmidecode|grep UUID at that point it will be the same UUID as previously recorded by windows, but that value is what was originally read into memory after bootup, the actual cmos is actually corrupted at that point. If I press button restart at this point, next reboot will show a different UUID.
During lots of reading about CMOS and NVRAM, there were warnings about writing to those memory locations and to make sure only one read occurs at a time, iI think it was from the documents at flashrom_org (but don’t quote me !!).
I have tried multiple kernels at manjaro bootup, so its not exactly the kernel which maybe causing but maybe some other common driver might be corrupted.
I’ll report if my full re-install makes or breaks.
Update - I captured all of the existing explicitly installed software from manjaro and AUR, and then re-installed manjaro on a new ssd, I partitioned the disk manually prior to install to use uefi. Then copied all of the existing /home partition to the new home partition. Installed from iso, and then re-installed all of the previously explicitly installed software so that booting from the old ssd or the new ssd were identical.
The new ssd install did not corrupt\modify the smbios, and windows stayed activated between reboots.
So in the final analysis I have absolutely no idea what causes the problem.
I repartitioned the old disk to look the same as the new disk, and cloned all of the partitons onto the original ssd, modified the partition uuid’s fixed fstab, re-installed the uefi and mbr, and it all worked on the original (Samsung) ssd too. No errors with the windows install.
There was one thing I discovered during the rebuild, but was too late to verify the orginal configuration, and that was to view\modify the smbios boot sequence using ‘sudo efibootmgr’ , I didn’t realise this existed until I had to solve a problem booting the 2 SSD’s after the cloning, due to the same uuid’s the efi bios setting would boot the wrong ssd. It maybe that there was a corruption of the smbios at some point of the linux bootup, but I will never know now as I edited and deleted entries to get the boot sequence to work correctly.