You are not logged in.
The type command will show if a wrapper or alias is being used instead of /usr/bin/grub-mkconfig. Sorry if that wasn't clear.
Para todos todo, para nosotros nada
Offline
Ah my bad, I edited my reply after this...
So:
Yes, it shows that
grub-mkconfig is /usr/bin/grub-mkconfig
So there is no wrapper
How can I see where else I'm running a wrapper, where can that be located?
Last edited by linuxghost (2025-01-13 12:46:00)
___________________________o00o_Ꝏ_o00o_______________________
Chaos always wins because it is better organised.
Offline
My suspicion is that;
1 changing the fstab /boot entry into /boot/efi because of this.
2 "cleaning up" the ESP and /boot
3 reinstalling linux and ucode-amd
was not enough or did confuse...something ... else
So I could not grub-install and mkconfig-grub anymore.
BTW
mv .bashrc .bashrc.bak
to eliminate that as a cause also didn't help.
Last edited by linuxghost (2025-01-13 13:15:04)
___________________________o00o_Ꝏ_o00o_______________________
Chaos always wins because it is better organised.
Offline
grub-mkconfig is just a script not a binary - so if it fails this means something within it fails
I'm not sure how to debug this but it could hint to some more severe issues about what's called within it
can you strace it?
sudo strace grub-mkconfig
without -o it should print to stdout - maybe this can give a hint
Offline
grub-mkconfig is just a script not a binary - so if it fails this means something within it fails
I'm not sure how to debug this but it could hint to some more severe issues about what's called within it
can you strace it?sudo strace grub-mkconfig
without -o it should print to stdout - maybe this can give a hint
Ok, thank you for the reply. I have "straced " grub-mkconfig, let it run a couple of seconds, ^C'd it and it produced quite a lot of output.
The data it produced however is way above my paygrade...
You can find the data HERE.
___________________________o00o_Ꝏ_o00o_______________________
Chaos always wins because it is better organised.
Offline
I can't make any sense of that so try this instead (as root):
cp /usr/{,local/}bin/grub-mkconfig
sed -i 's|#! /bin/sh|& -x|' /usr/local/bin/grub-mkconfig
grub-mkconfig # please share this output
rm /usr/local/bin/grub-mkconfig
Reinstalling the grub package should have replaced that flle anyway, or created a .pacnew if it was modified.
Last edited by Head_on_a_Stick (2025-01-13 16:36:06)
Para todos todo, para nosotros nada
Offline
The only thing I can see is that there's a loop somewhere, because the same piece of output is repeated over and over.
See HERE.
___________________________o00o_Ꝏ_o00o_______________________
Chaos always wins because it is better organised.
Offline
Check /etc/default/grub — I might be wrong but I suspect there is a stray command at the end of the file.
Para todos todo, para nosotros nada
Offline
I checked the strace against a run of my system - and it goes wrong when it hits /etc/default/grub - same goes for the output of the command from HoaS
please post your /etc/default/grub - looks like grub-mkconfig keeps calling itself recursively - which would fit the previous shell error message
Offline
You are right!
There was a
grub-mkconfig -o /boot/grub/grub.cfg
in /etc/default/grub!!
How did that get in there?? Must have stuck to the cursor I think.
That explains the loop.
Thank you all for your help!
___________________________o00o_Ꝏ_o00o_______________________
Chaos always wins because it is better organised.
Offline
well - then you should had gotten an info about a .pacnew when reinstalling the grub package as pacman doesn't touch modified files - this already should had gotten a hint that /etc/default/grub has some modifications to be looked at
Offline
well - then you should had gotten an info about a .pacnew when reinstalling the grub package as pacman doesn't touch modified files - this already should had gotten a hint that /etc/default/grub has some modifications to be looked at
There is/was no grub.pacnew under /etc/default.
TBH don't you think that someone who missed pasting a line in an essential file probably could have missed more?
To prevent these stupidities from happening in the future I've switched off "tap-and-drag' from my touchpad.
So let us no further talk about what I "should have" ; a (unproven) quote from Albert Einstein comes to mind.
Thank you for your help.
___________________________o00o_Ꝏ_o00o_______________________
Chaos always wins because it is better organised.
Offline
I wasn't attacking you offensively by blaming you missing some lines - it was just a thought about due to /etc/default/grub being a file installed by a package and not touched if modified reinstalling the package may have lead to a .pacnew file which usually causes an info which might could have been a hint if noticed
your reply shows that I might be wrong about a potential info and that I am wrong about a .pacnew file - ok, lesson learned
how the command ended up in the config - and more important: why it was executed as a command - is something to be debated about by a pint of beer in a pub
however it shows that for some reason /etc/default/grub is not just a simple config that gets read and evaluated but shell code that gets executed - which raises the question what the hell is grub-mkconfig actually doing and why does it get away with it?
a config shoukd nit contain executable code and it should not be run in a way said code can get executed
tldr: weird issues we were able to find and fix - this topic raises far more questions than it answered
Offline
If he didn't reinstall the grub package (which there's little reason to do) then you won't generate a .pacnew. Probably just some mishap when editing /etc/default/grub with the editor and some c'n'p error.
FWIW the point of grub-mkconfig is to run a series of shell scripts which are placed under /etc/grub.d/... and the point of /etc/default/grub is to provide (shell/environment)-variables to said scripts which will influence how the generated grub.cfg looks. so ultimately yes, /etc/default/grub will be sourced by shell scripts and will run commands should they be present there. ¯\_(ツ)_/¯
Offline
I wasn't attacking you offensively by blaming you missing some lines
I never thought you did.
- it was just a thought about due to /etc/default/grub being a file installed by a package and not touched if modified reinstalling the package may have lead to a .pacnew file which usually causes an info which might could have been a hint if noticed
your reply shows that I might be wrong about a potential info and that I am wrong about a .pacnew file - ok, lesson learned
Ahh I might have reinstalled grub more than once.
how the command ended up in the config - and more important: why it was executed as a command - is something to be debated about by a pint of beer in a pub
Now, I totally agree with this!
however it shows that for some reason /etc/default/grub is not just a simple config that gets read and evaluated but shell code that gets executed - which raises the question what the hell is grub-mkconfig actually doing and why does it get away with it?
a config shoukd nit contain executable code and it should not be run in a way said code can get executedtldr: weird issues we were able to find and fix - this topic raises far more questions than it answered
Well, the touchpad setting "tap-and-drag" is AFAIK responsible for the (involuntary, unnoticed) paste, so is now switched off.
As for "the loop"; when a conf file of/for an interpreter contains that interpreter itself the buzzing around starts.
See you around.
Last edited by linuxghost (2025-01-14 15:03:58)
___________________________o00o_Ꝏ_o00o_______________________
Chaos always wins because it is better organised.
Offline