I updated to 6.4.10-200.fc38 and then after I entered my passphrase, grub boot loader started and before finishing stage2, grub outputs on screen 5 errors that alternate between “syntax error” and “Incorrect command” errors. I enter edit mode with hitting the “e” key, then I delete the “{extra_cmdline}” text and hit Ctrl + x to reboot. I then enter the OS. It is a bit annoying to do the edit each and every time to start the OS. What caused the problem and how can I correct this problem of having to edit on each boot of stage2 of grub.
Problem started after I installed updates to System Updated, Firefox, NVIDIA Graphics Drivers Control Panel, and NVIDIA Linux Graphics Driver.
What repos are you using?
Please show the output of dnf repolist
How did you do the updates you listed?
For nvidia installation and updates the only thing needed is to enable the 3rd party repos under the gnome software app then install the nvidia drivers. If you used another method we need to know before we can answer.
Please also show the output of dnf list installed \*nvidia\* and inxi -Fzxx
Thank you Jeff. Attached is the screenshot of the 3 commands. For inxi, I just took a partial screenshot to just show the graphics information of my machine.
I used the GNOME Project “Software” to update. I did an additional update from 6.4.10-200.fc38 to 6.4.11-200.fc38. The odd thing is that before my update to 6.4.10, grub would just start my os without I needing to edit out the “{extra_cmdline}” text in the grub editor for 6.4.10-200.fc38.
I should add that the text in the edit mode of the 6.4.10-200.fc38 os has linux instead of linuxefi for the UEFI-based machine. I do not think it matters since I am able to boot into the os after I delete {extra_cmdline} and reboot with Ctrl + x
So there is actually {extra_cmdline} in the kernel argument command line?
That’s just a menu title if you’re referring to the Grub menu, so technically you could call it whatever you want just as long as it points to the correct locate.
When you’re in edit mode at the grub prompt it would be nice to know the entire kernel argument so we can remove that offending argument. Using the tool for it … Grubby … like sudo grubby --remove-args=String
It would be much nicer and allow someone to search if you were to actually post data from your screen with copy & paste of the text into the post. The formatting as seen on screen would be retained if you were to use triple back-quotes [```] on the line preceding the text and on the line following the text (or use the </> button on the tool bar after highlighting the pasted text, which does the same)
As noted above, and what you said, there seems an error in the kernel command line.
Please post the output of cat /proc/cmdline and cat /etc/default/grub
Yes, I think the problem is in the kernel command line. I just do not know how to fix. Attached is the screenshot. Somehow, the {extra_cmdline} that I always need to delete to boot the OS is not anywhere in the screenshot. The only culprit I can think of is the GRUB_CMDLINE_LINUX line. When I edit out the {extra_cmdline}, it is always before “rd.driver” and after “rhgb quiet”
Thanks Joe for the advice. I gave the command and saw that the {extra_cmdline} was in the output. How do I get it out safely? Stephen suggested I sudo grubby --remove-args=String
@Jeff, Thanks for the advice about copy & paste. I will use that method next time I write.
The extra_cmdline is somewhat related to SUSE_BTRFS_SNAPSHOT_BOOTING, so if anyone is familiar with this, that is who could help. It is, however, more difficult to help when you black out certain important information which could be a clue to the cause of the problem.
Thank you Villy. Yes, if anyone needs to see the blacked out content to better help, then let me know and I will release another text screenshot of the output.
If from grub booting list you can boot by removing ${extra_cmdline}, the easiest way to remove it is by edit file /etc/default/grub (since removing with grubby --remove-args... will bit difficult because it contain character $, {, and }).
BEFORE you edit the grub file, please make a backup (e.g. by running sudo cp /etc/default/grub /etc/default/grub.bak).
Run first sudo grubby --info ALL then make the record of the result to your text editor (for comparison later).
Edit the file /etc/default/grub with your favorite editor—also need sudo. Find line GRUB_CMDLINE_LINUX=... then remove ${extra_cmdline} then save.
After that run sudo grub2-mkconfig --output /etc/grub2-efi.cfg.
Check with sudo grubby --info ALL in line args=... for the changes. Then compare it with the result from same command before. Make sure all still same except the new one didn’t have ${extra_cmdline} argument.
Sorry, but it wouldn’t work. Check message no 7 and see that the text “extra_cmdline” does not occur in “/etc/default/grub”, and therefor can’t be removed.
The text " ${extra_cmdline}" is inserted by grub2-mkconfig because of the following snippets from /etc/grub.d/10_linux
if [ "x${SUSE_BTRFS_SNAPSHOT_BOOTING}" = "xtrue" ]; then
GRUB_CMDLINE_LINUX="${GRUB_CMDLINE_LINUX} \${extra_cmdline}"
else
rootsubvol="`make_system_path_relative_to_its_root /`"
rootsubvol="${rootsubvol#/}"
if [ "x${rootsubvol}" != x ]; then
GRUB_CMDLINE_LINUX="rootflags=subvol=${rootsubvol} ${GRUB_CMDLINE_LINUX}"
fi
fi;;
So, does anyone know what SUSE_BTRFS_SNAPSHOT_BOOTING is about and what it is supposed to do and why it was added to /etc/default/grub?
I search around in the internet, look like it related with snapper configuration (source). This app have same purpose as timeshift that make possible to make BTRFS snapshot and rollback version.
My suggestion still same by edit /etc/default/grub but only edit from SUSE_BTRFS_SNAPSHOT_BOOTING="true" to SUSE_BTRFS_SNAPSHOT_BOOTING="false" file since from grub boot list, the system still be able to boot by removing ${extra_cmdline}. After that run sudo grub2-mkconfig --output /etc/grub2-efi.cfg.
@jakfrost No dual boot, just Fedora. I remember when I did install my stystem, I also installed snapper. I need to look at how I installed it at that time.
Before when I would update my Fedora Workstation, I would not have this problem. It is a little peculiar that all of a sudden I have this problem. I have in the past updated from 35 to 36 to 37 to now 38.
