I am not stating or implying anything about you giving instructions regarding grub.cfg. I am describing my work around because I couldn't access grub.d as some guide sets I had reviewed instructed to before you offered assistance.
At the time I posted my last response, I ran into the same permission denied when I went to execute your instructions but I did not try sudo in that instance as I got sidetracked on a separate line of inquiry; I thought I hit another lockout like grub.d and chased a second line of thought open in another browser window.
My last paragraph was simply a rehash of the guides I was reading. I wondered at how the system worked and where others were placing the command you list above (as it is not the first time I have run into it, only that either the location is unmentioned or people were editing a file in grub.d). As usual, texts ran mostly on the side of too little detail and file paths than too much, though the texts with too much manage to make the material obtuse to the point of frustration. What I learned from this is that, by in large, the world's education systems still have difficulty producing graduates who understand the fundamentals of producing good technical writing, specifically in composition and audience awareness.http://www.qubes-os.org/doc/vm-sudo
This link explains why I have been confused with my observations on root, sudo, permissions, and the lack of log ins anywhere. I had not gotten to really dig in to the matter since Sunday or have a fresh try at your solution until now.
I have trialed the fix above using sudo and successfully wrote the the command into the grub file via nano. It seems to function as the grub.cfg edit did. No changes.
Given the information in the vm-sudo, I see no point in a root account at the moment.
I understand your analogy but it seems more than a bit off in its comparison.
Now to try track down the every once in a great while sudden reboot.