|
|
Krister's Blog
krister at hallergard dot com
| Last Updated:
2018-08-09 Newer version
|
Grub2 - Command Line Parameters
In the beginning of 2017 I realized that "update-grub" in Kubuntu and Linux Mint created new /boot/grub.cfg files that had not picked up the command line parameters for openSUSE and Fedora (Linux Mint is on a MBR disk,
whereas the others are on a GPT disk). Fedora and openSUSE would not even complete booting from the Kubuntu menu, unless the "iommu=soft" command line parameter had been added
(I had also installed a WiFi-card, which did not like the default motherboard setting of IOMMU Controler to Disabled either - and similarly a new USB Combo keyboard/mouse did not work with the Disabled setting).
Solution 1:
For Kubuntu and Linux Mint I added the openSUSE and Fedora kernel command lines to /etc/grub.d/40_Custom, where I had already chosen to add experimental distros like Android_x86 and PhoenixOS.
But every time there was a kernel update for openSUSE or Fedora I had to edit the 40_Custom files, which was less than ideal.
Recently I upgraded Fedora 27 to Fedora 28, but "update-grub" would no longer pick up the openSUSE command line parameters. Had to add another 40_Customs for Fedora 28.
|
/etc/grub.d/40_Custom on Kubuntu and Linux Mint
|
Kubuntu bootmenu Last 4 lines manually added
|
Solution 2:
/etc/default/grub on openSUSE
|
I changed the openSUSE kernel commands from linuxefi and initrdefi to linux and initrd by putting a hash in front of the line:
#GRUB_USE_LINUXEFI="true" in /etc/default/grub, and I was pleased to find that "update-grub" with Fedora 28, Kubuntu and Linux Mint now picked up the full command line
of openSUSE.
I was not able to replicate this for Fedora though - and I have yet to find a way to change away from linuxefi and initrdefi. Well, I did replace them manually, and yes,
Kubuntu and Linux Mint could then pick up the full command lines of Fedora. But after a Fedora kernel update with "update-grub" the Fedora commands changed
back to linuxefi and initrdefi - so I would have to keep editing Fedoras /boot/grub2/grub.cfg manually after every kernel update.
|
Solution 3 ?:
What was I doing wrong?? Should I maybe use the proper Secure Boot (shim.efi) for all three distros on the GPT disk? After doing those installations I realized that openSUSE
would not boot, unless I removed the hash mentioned above for Solution 2, which meant that the other distros would no longer pick up the openSUSE parameters.
So, went back to using grubx64.efi as before.
Conclusion:
With solution 2 the bootmenus of openSUSE and Fedora are OK, and I am leaning towards leaving the remaining problem unresolved (Kubuntu and Linux Mint not picking up the
Fedora command line), not bothering about manually replacing linuxefi/initrdefi with linux/initrd in grub.cfg after each new kernel installation for Fedora.
And I plan to change the default bootmenu from Kubuntu to openSUSE and forget about the unsolved problems.
It is not clear to me where the os_prober picks up the information about other systems, and in which way this is dependent on other grub settings. Your help would be appreciated!
SOLUTION:
With the help of Marcin82 - thanks! I found a solution to my problem, though in a rather different way than I had envisaged. Reverting back to Solution 1, but instead
of specifiying the kernels and command lines in the respective 40_Custom, replacing them with the line configfile /boot/grub2/grub.cfg, which picks up all the up-to-date
kernels with its parameters, when doing "update-grub" (this is what I had expected the os_prober to do!)
The resulting bootmenu will have the functioning entries at the bottom, but above the nonfunctioning entries will also show. These can be skipped by adding this line in /etc/default/grub: GRUB_OS_PROBER_SKIP_LIST=UUID@/dev/sdxy, in my case for Kubuntu and Linux Mint:
GRUB_OS_PROBER_SKIP_LIST='0e48f2bf-ba78-42d7-b31c-7e708f01e51d@/dev/sdb7 11ea3046-6a4e-4b4a-930c-0083dd7fad29@/dev/sdb8'
|
Addendum 2018-08-11
|
New /etc/grub.d/40_Custom on Kubuntu and Linux Mint
|
IOMMU=soft
AMD IOMMU is chipset component which filters or redirects memory reads/writes performed by other devices.
In the language of Intel this is called VT-d.
I bought my present PC (spec) in April 2016 - and only towards the end of the year did I realize the importance of handling the IOMMU properly for Linux.
The default motherboard setting for the IOMMU Controller was Disabled, but I had set it to Enabled to get Ethernet to function better with Linux.
But then I bought a USB3 flash drive, which would not work in Linux.
I googled, and found that the solution was to go back to Disabled and add "iommu=soft" to the Grub2 command line
(in /etc/default/grub add GRUB_CMDLINE_LINUX="iommu=soft") for all my Linux distros. Also some of the Linux installation media required editing of the command line with this addition before installation.
|
IOMMU Controller Gigabyte GA-970A-DS3p
|
|