I understand the fact that the foreign grub.cfg is used as a source; but if the UUIDs for the other non kernel command line items are changed why not changing the command line itself, if the UUID matches? I understand that some menuentry may be special and have very weird kernel command lines but by matching the UUID value all shold be good.
Changing the original grub.cfg can not be done with grub tools; chroot and then run grub-mkconfig fails due to lack of a valid /dev and possibly other missing proc entries. Reverting to manually modify it can be done on the grub.cfg in the new partition. ________________________________ From: Pascal Hambourg <[email protected]> Sent: September 4, 2020 5:46 PM To: Claude Robitaille <[email protected]>; [email protected] <[email protected]> Subject: Re: grub-mkconfig os-prober did not update UUID Hello, Le 04/09/2020 à 18:00, Claude Robitaille a écrit : > > I am copying a root FS on a different partition, hence the UUID needed to > boot from that new partition is different. I am running grub-mkconfig on the > main partition (with os-prober installed and the new partition mounted). > > The resulting /boot/grub/grub.cfg is perfect; the new partition menuentry is > created as expected in the /etc/grub.d/30_os-prober section. Except for one > glitch: every UUID referenced in that menuentry were updated EXCEPT the most > important one; the linux kernel command line argument root= still has the > original UUID. Manually updating it prove that the menuentry is otherwise Ok > (by booting using it). grub-mkconfig gets the kernel command line parameters from the foreign grub.cfg when it exists. You must update it with the new UUID when moving a system.
