exec /usr/sbin/grub-mkconfig -o /boot/grub/grub.cfg then called update-grub with it's explicit path and tada, it worked! # /usr/sbin/update-grubįound background image: /usr/share/images/desktop-base/desktop-grub.pngįound linux image: /boot/vmlinuz-4.18.0-2-amd64įound initrd image: /boot/initrd.img-4.18.0-2-amd64įound linux image: /boot/vmlinuz-4.16.0-2-amd64įound initrd image: /boot/initrd.img-4.16. Then it came to me, let's see how the update-grub script looks like? #cat /usr/sbin/update-grub |grep grub-mkconfigĮxec grub-mkconfig -o /boot/grub/grub.cfg /usr/sbin/update-grub in order to call grub-mkconfig by it's explicit path. Searched for grub-mkconfig and found it under /usr/sbin/grub-mkconfig. usr/sbin/update-grub: 4: exec: grub-mkconfig: not found Ran it, just to get the next error message. I've found that there is an update-grub command in /usr/sbin. I know that this has been designed this way, to keep the environment of the actual user, but in this single case, it really boggles my mind, why not add automatically /usr/sbin and /sbin to thew path of a "regular user" after a successful su root # cat /etc/fs |grep PATH=ĮNV_SUPATH PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binĮNV_PATH PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games There are two PATH defined in /etc/fs, but unless I start su - or su - root, I'm going to get the ENV_PATH. su - root -> admin rights, /usr/sbin on the path => opinion: works as. => opinion: works as designed, but illogical, because an account with root level of access should be able to execute commands from sbin without adding the path to the binaries manually Then, add your user to the sudo group using: usermod -aG sudo yourusername. On Debian-based systems, enter: apt install sudo.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |