3

update-grub failed with an error message

# update-grub
bash: update-grub: command not found

@GAD3R Output of

# [ -d /sys/firmware/efi ] && echo EFI || echo legacy
legacy

Note1 I've installed Debian 10 Buster Alpha 3 release (Xfce) using the amd64 CD iso installer using a default installation (except that I removed the print server and added the ssh server).

Note2 I used the root account (su root).

  • Welcome , please add the output of [ -d /sys/firmware/efi ] && echo EFI || echo legacy – GAD3R Nov 18 '18 at 17:34
  • 2
    Will su - root fix it? – Rui F Ribeiro Nov 18 '18 at 18:22
  • 2
    Try with full path: /usr/sbin/update-grub – Ipor Sircer Nov 18 '18 at 20:40
  • Thanks Rui, this worked. My expectation was that after a successful su, I should be able to call all binaries without extending the PATH. – linux64kb Nov 18 '18 at 20:59
  • Thanks Ipor, I've tried this one, and it worked, but following this way would lead me to modify all scripts I need to run. – linux64kb Nov 18 '18 at 21:04
4

Solutions (best ones first)

  1. su - root instead of su root - nicest solution (thanks to Rui)
  2. extend path of the regular user in /etc/enviroment or ~/.bashrc or similar config file
  3. call commands explicitly; using this solution would require that one modifies all scripts that happens to call another command from sbin (this is not practical, nevertheless there is an example of it in the troubleshooting section)

Findings

This happened because the PATH works in a really strange way (actually works as designed).

  1. regular user login -> environment PATH doesn't contain /usr/sbin => opinion: works as designed, quite logical
  2. su root -> admin rights, but the environment is lacking /usr/sbin:/sbin => 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
  3. su - root -> admin rights, /usr/sbin on the path => opinion: works as designed, quite logical

Some more background

There are two PATH defined in /etc/login.defs, but unless I start su - or su - root, I'm going to get the ENV_PATH. 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/login.defs |grep PATH=
ENV_SUPATH  PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
ENV_PATH    PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

Troubleshooting

I've found that there is an update-grub command in /usr/sbin.

# find / -name update-grub
/usr/sbin/update-grub

Ran it, just to get the next error message.

# /usr/sbin/update-grub
/usr/sbin/update-grub: 4: exec: grub-mkconfig: not found

Searched for grub-mkconfig and found it under /usr/sbin/grub-mkconfig. Then it came to me, let's see how the update-grub script looks like?

#cat /usr/sbin/update-grub |grep grub-mkconfig
exec grub-mkconfig -o /boot/grub/grub.cfg "$@"

Modified /usr/sbin/update-grub in order to call grub-mkconfig by it's explicit path ...

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
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.18.0-2-amd64
Found initrd image: /boot/initrd.img-4.18.0-2-amd64
Found linux image: /boot/vmlinuz-4.16.0-2-amd64
Found initrd image: /boot/initrd.img-4.16.0-2-amd64
done

Conclusion

This must be something about the PATH

  • 1
    Isn't it easier to run export PATH=$PATH:/usr/sbin before running update-grub than editing these files? – Moby04 May 23 at 15:39
  • @Moby04 A nice one! I'm going to check this soon. – linux64kb May 28 at 20:21
  • 2
    Note that according to Debian Wiki, previous versions of Debian used a version of su from the shadow source package, while Buster uses one from the util-linux sources, which won't auto-add the /sbin and /usr/sbin directories to PATH when switching to root. If you need to approximate the old behavior, you can set ALWAYS_SET_PATH yes in /etc/login.defs. – telcoM Jul 6 at 20:23
  • Nice finding and background @telcoM, much appreciated :) I still can't find a logical reason for such defaults ... grumble-mumble ... ;) – linux64kb Jul 9 at 19:57
0

First update your local package list :

sudo apt update && sudo apt upgrade

Find correct boot mode :

[ -d /sys/firmware/efi ] && echo EFI || echo legacy 

then, forced reinstallation of grub package for leagcy grub-legacy package is there and for efi grub-efi ( I'm assuming you boot mode is EFI ):

sudo apt install --reinstall grub-efi
sudo apt install grub-common

If still issue is not resolve, try this on :

sudo grub-mkconfig -o /boot/grub/grub.cfg

update-grub command is just a script which runs the grub-mkconfig tool to generate a grub.cfg file. See the Archlinux GRUB documentation

Ref :

  • Boot mode is legacy. – linux64kb Nov 18 '18 at 19:17
  • Then use this command : sudo apt install --reinstall grub-legacy – finn Nov 18 '18 at 19:25
  • Thanks Vipul, but this failed to resolve the issue too. – linux64kb Nov 18 '18 at 19:35
  • @linux64kb, try this one : sudo grub-mkconfig -o /boot/grub/grub.cfg – finn Nov 18 '18 at 20:45
  • Thanks Vipul, it seeems that the issue lies with the PATH, the grub itself is OK. – linux64kb Nov 18 '18 at 21:13
-2

You can force the reinstallation of grub:

sudo apt-get install --reinstall grub

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.