I recently installed Ubuntu 18.04 from a USB. I did everything the same way I’d done when upgrading from 14 to 16, and 16 to 17, and it worked every time until now. I selected “erase ubuntu 17 and install ubuntu 18” while running 18 from a USB image. Here is my issue: Grub2 loads, but seems to be using the wrong config file in the wrong partition. In order to run ubuntu I have to set the root dir to /dev/sda8 and set the proper linux and initrd files which live in /dev/sda8/boot(this is also where the grub.cfg file I want to use lives). I can see there is a grub.cfg file on dev/sda1/EFI/ubuntu/grub.cfg that just points to /dev/sda5 which is the BIOS partition. My question is, how can I get grub to use the config file I have updated from ubuntu (the one at /dev/sda8/boot)? I am worried that if I change the one on /dev/sda1, I will seriously break something, but if not, would it suffice to use the contents of the cfg file on sda8?
Here is the terminal output of fdisk -l for reference:
Device Start End Sectors Size Type
/dev/sda1 2048 206847 204800 100M EFI System
/dev/sda2 206848 468991 262144 128M Microsoft reserved
/dev/sda3 468992 816990982 816521991 389.4G Microsoft basic data
/dev/sda4 816992256 818726911 1734656 847M Windows recovery environment
/dev/sda5 818726912 818728959 2048 1M BIOS boot
/dev/sda6 935913472 939819007 3905536 1.9G Linux swap
/dev/sda7 942651392 976773119 34121728 16.3G Microsoft basic data
/dev/sda8 818728960 935913471 117184512 55.9G Linux filesystemThe file /dev/sda1/EFI/ubuntu/grub.cfg has the following contents, note that (hd0,5) is the BIOS partition:
search.fs_uuid 7e076866-97b4-4d3c-b864-491137212645 root hd0,gpt5
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfgI’m a bit confused by your question. If your system is EFI (as it seems to be), why do you need a second grub.cfg on /dev/sda8? Why can’t you just configure the one on /dev/sda1 to boot everything? What else are you booting on the machine, besides Ubuntu?
– Time4TeaJun 20, 2018 at 18:47
I did not put the grub.cfg on /dev/sda8, the command sudo update-grub2 did. Also, part of my question was whether I could just put the contents of the config file on dev/sda8 into the one in the EFI partition without breaking anything. I am dual booting Windows 10. Perhaps I can tell config-grub2 to update the file on sda1?
– ThisGuyCantEvenJun 20, 2018 at 18:52
Ok. Was the live USB definitely created and booted in EFI mode, not ‘legacy BIOS’ mode? I believe ‘update-grub2’ needs to be run from a system in the same boot mode as the one it is trying to update.
– Time4TeaJun 20, 2018 at 18:58
Of this I am uncertain. It was made on windows with rufus. I assume I would have to go into the firmware to check what mode it booted in? or could I possibly infer this from the config file on sda8?
– ThisGuyCantEvenJun 20, 2018 at 19:00
This page might help you determine if the live USB is booting in EFI or legacy mode: askubuntu.com/questions/162564/…
– Time4TeaJun 20, 2018 at 19:02
For those who find this question in the future, and use cloud-init on their server (either dedicated servers e.g. via MAAS, or virtual servers (VPS’s) via any virtualisation software or “cloud” providers), there’s a very easy fix.
How I ran into this issue
I migrated the rootfs on one of my VMs from it’s original root partition, to a new disk – and I found that update-grub would keep using the PARTUUID of the original rootfs. First I assumed it was just an issue related to running it within a chroot, so I manually corrected the UUIDs in /boot/grub/grub.cfg and rebooted.
After booting into the new rootfs partition, I ran update-grub, hoping that running it from the real system running on the new disk, it would now use the correct UUIDs – unfortunately not.
I searched the internet and came to this StackExchange question, one answer advised checking /boot/efi for any potential extra config files that might be contributing. Sure enough, I found /boot/efi/boot/grub/grub.cfg which appeared to contain a hard coded FS UUID:
root@host ~ # cat /boot/efi/boot/grub/grub.cfg
# CLOUD_IMG: This file was created/modified by the Cloud Image build process
search.fs_uuid 897a358a-acba-4b07-867c-33d1ca3b28dc root hd0,gpt1
set prefix=($root)'/boot/grub'
configfile $prefix/grub.cfg
I corrected the fs_uuid, but this still didn’t completely fix update-grub setting the wrong PARTUUID in /boot/grub/grub.cfg.
However, I eventually noticed a suspicious config file in the logs of the update-grub command:
root@host ~ # update-grub
Sourcing file `/etc/default/grub'
Sourcing file `/etc/default/grub.d/40-force-partuuid.cfg'
Sourcing file `/etc/default/grub.d/50-cloudimg-settings.cfg'
Sourcing file `/etc/default/grub.d/init-select.cfg'
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-5.4.0-71-generic
Found initrd image: /boot/initrd.img-5.4.0-71-generic
Found linux image: /boot/vmlinuz-5.4.0-24-generic
Found initrd image: /boot/initrd.img-5.4.0-24-generic
doneThe final fix for the issue
Hm… Sourcing file '/etc/default/grub.d/40-force-partuuid.cfg' – force partuuid? Looked to be the culprit.
root@host ~ # cat /etc/default/grub.d/40-force-partuuid.cfg
GRUB_FORCE_PARTUUID=897a358a-acba-4b07-867c-33d1ca3b28dc
Sure enough, it contained the partition UUID that kept being set in the GRUB config, despite being incorrect.
After changing GRUB_FORCE_PARTUUID to be the PARTUUID of my rootfs partition, and re-running update-grub, it finally used the correct PARTUUID in the grub.cfg 🙂
Summary
To fix this issue on systems which use cloud-init, first you’ll need to note down both the filesystem UUID (UUID=) and the partition UUID (PARTUUID=) for your root filesystem (and/or possibly your boot partition if you have a separate one) from the blkid command:
root@host ~ # blkid
/dev/sda1: UUID="wcrpSm-QCZu-VN3A-I503-sQqQ-5xfw-76r5bd" TYPE="LVM2_member" PARTUUID="bec389fc-4274-5245-babb-7d90674f1662"
/dev/sdb2: LABEL_FATBOOT="UEFI" LABEL="UEFI" UUID="072E-C819" TYPE="vfat" PARTUUID="78730ead-03d3-e14d-b4fe-ee0abf4f0ad5"
/dev/sdb3: UUID="6cea6786-510a-4fba-871b-7811b63b3453" TYPE="xfs" PARTUUID="530c353b-0be8-e34e-affb-bd5c2332abc7"In my case, /dev/sdb3 is both the rootfs and boot partition.
So now, open up /boot/efi/boot/grub/grub.cfg with the editor of your choice (e.g. nano or vim), and replace the UUID part of fs_uuid XXXX-XXXX with your filesystem UUID, for example, in my case, it is 6cea6786-510a-4fba-871b-7811b63b3453
Next, open up /etc/default/grub.d/40-force-partuuid.cfg and replace the UUID value of GRUB_FORCE_PARTUUID= with your PARTITION UUID (PARTUUID), which in my case is 530c353b-0be8-e34e-affb-bd5c2332abc7.
Finally, run update-grub – and then check /boot/grub/grub.cfg and confirm that it now uses the correct FS UUID + PARTUUID.
You should now be able to update your GRUB config, and reboot in peace, without getting stuck in an initramfs due to invalid UUIDs 🙂
- OMG thank you. Sooooo many rabbitholes. You win the Internet today. – Kyle Jan 24, 2022 at 3:00
Had this exact same problem with an Ubuntu 20.04 VM created via Hyper-V’s Quick Create option, same 40-force-partuuid.cfg. Ran sudo blkid and was able to fix this right up, thank you.
– Chris MagnusonMar 6, 2022 at 18:06
Ah, maybe that’s why even the PARTUUID in the grub is correct, mine still fail. I didn’t check the fs_uuid part.
As I mentioned in the comments, I’m confused about what the ‘BIOS boot’ partition is for, and why you have several different grub.cfg files spread across different partitions. I think all you should need is one grub.cfg file, from which should be able to boot up both Linux and Windows.
Another thing is to make absolutely sure that the live USB you are updating from was created and booted in EFI mode, not legacy BIOS boot mode. An easy way to check this is to boot up from the USB and check to see if the file /sys/firmware/efi exists. If it doesn’t, then it wasn’t booted in EFI mode.
I have a fairly similar dual-boot system with Windows/Linux. I have checked it and there is only one grub.cfg file, on the Linux system root partition in the /boot/grub folder. The EFI system partition is being mounted at /boot/efi during boot.
With regards to your question about modifying the grub.cfg on the EFI partition: there shouldn’t be any harm in doing that. In fact, if you do need multiple grub.cfg files for some reason, it would probably be best to maintain the files yourself anyway (rather than hoping the auto update tool will handle it correctly). I would back-up the auto-created file first, and you can also test out boot commands on the grub command line, before modifying the file. The worst that would likely happen if you do mess something up is that you’ll get dumped into a GRUB command prompt, where you’ll have to enter the boot commands manually. If you don’t know how to do that, then you might have to boot via a live USB and fix/restore the file.
The other thing is though, that if you do make changes to grub.cfg manually, they might get overwritten the next time GRUB does an auto-update (in that case, I would probably disable the update-grub command in your linux distribution).
Thanks to @Time4Tea for helping me along. As it turns out, there was a VERY VERY SIMPLE fix for this. The grub.cfg file I posted earlier that lived at (hd0,1)/EFI/ubuntu/grub.cfg aka /dev/sda1/EFI/ubuntu/grub.cfg just needed to have the prefix changed from (hd0,gpt5) to (hd0,8), which is where the grub.cfg file that I created with sudo update-grub2 was located. I overwrote it with nano and saved it by mounting /dev/sda1/ from ubuntu (after manually using grub terminal to boot into ubuntu). Below is the new file with the one small change:
search.fs_uuid 7e076866-97b4-4d3c-b864-491137212645 root hd0,gpt5
set prefix=(hd0,8)'/boot/grub'
configfile $prefix/grub.cfgI never had a problem cloning disks until ubuntu 20.04. Then
I would clone and on boot grub would complain about not finding ‘disk c871cf8d21f6a1ce’ or some such. then I worked out the fix.
SOURCE DISK
My source disk is laid out like:
fdisk -l /dev/sda
Device Start End Sectors Size Type
/dev/sda1 2048 1026047 1024000 500M EFI System
/dev/sda2 1026048 19900415 18874368 9G Linux swap
/dev/sda3 19900416 488397133 468496718 223.4G Linux filesystem
The fs_uuid of the source disk is, of course:
grub-probe -t fs_uuid -d /dev/sda1
c871cf8d21f6a1ce
In the /boot directory there is
find /BACKUP/blesbok-daily/boot/efi/ | grep grub.cfg
/BACKUP/blesbok-daily/boot/efi/EFI/ubuntu/grub.cfg
cat /boot/efi/EFI/ubuntu/grug.cfg
search.fs_uuid c871cf8d21f6a1ce root hd0,gpt3
set prefix=($root)’/ROOT/blesbok@/boot/grub’
configfile $prefix/grub.cfg
NOTE –>Your system ~may~ have other ‘grub.cfg’ under other /boot/efi. You
will have to change all of them as directed, below. <– NOTE
The relevent parts of ‘/boot/grub/grub.cfg’ are:
…
set root=’cryptouuid/c03cff716cab4e93843db1f16b8ba5a8′
if [ x$feature_platform_search_hint = xy ]; then
search –no-floppy –fs-uuid –set=root –hint=’cryptouuid/c03cff716cab4e93843db1f16b8ba5a8′ c871cf8d21f6a1ce
else
search –no-floppy –fs-uuid –set=root c871cf8d21f6a1ce
…
set root=’hd1,gpt3′
if [ x$feature_platform_search_hint = xy ]; then
search –no-floppy –fs-uuid –set=root –hint-bios=hd1,gpt3 –hint-efi=hd1,gpt3 –hint-baremetal=ahci1,gpt3
There are, of course, many references to ‘hd1,gpt3’ and ‘c871cf8d21f6a1ce’ in ‘/etc/default/grub.cfg’
CLONE DISK
Say I have a different partition scheme for the clone as:
fdisk -l /dev/sdc
Device Start End Sectors Size Id Type
/dev/sdc1 2048 1026047 1024000 500M EFI System
/dev/sdc2 1024000 1115686911 1048576000 500G 83 Linux
and
grub-probe -t fs_uuid -d /dev/sdc1
927ccf30-88b7
I mount all partitions and clone per usual with ‘rsync’. I chroot with:
cd /mnt ; mkdir dev sys proc run ; cd /
mount --bind /run /mnt/run
mount --bind /dev /mnt/dev
mount --bind /sys /mnt/sys
mount --bind /proc /mnt/proc
chroot /mnt/ PROBLEM: We have to install grub on the clone but ‘update-grub’ appears to read
from the disk that booted the computer to make the clone (may not be the source disk) and make a grub.cfg that will not boot the clone disk. In chroot we have to install grub (for either UEFI or BIOS), put back the original source grub.cfg files from source to clone and edit, putting in the clone’s ‘gptX’ and fs_uuid.
FOR EFI SYSTEMS (in chroot)
apt-get install –reinstall grub-efi-amd64 ; grub-install –target=x86_64-efi –efi-directory=/boot/efi –bootloader-id=arch_grub –recheck –debug ; efibootmgr -c –disk /dev/sdc –part 1
(NOTE that the clone in my example is 'sdc'. I also find that I sometimes have
to run this TWICE to properly install grub) FOR BIOS SYSTEMS (in chroot)
grub-install /dev/sdX
IN EITHER SYSTEM – the magic
If you or your install script ran ‘uodate-grub’ or ‘grub-mkconfig’ any ‘grub.cfg’ reflect the source disk. GET RID OF THEM! Replace them AGAIN with those from the source as they reflect the boot environment of the source disk. You now have to edit those files to refer to the clone disk.
In all ‘grub.cfg’ under /boot
- Replace ‘c871cf8d21f6a1ce’ (fs_uuid of the source disk) with ‘927ccf30-88b7’ (fs_uuid of the clone disk)
- replace ‘gpt3’ with ‘gpt2’ since the root partition of the clone disk is ‘sdc2’ and the root of the source was /dev/sda3,
IMPORTANT: also replace any instance of ‘hdX’ with ‘hd0’
/boot/efi/EFI/ubuntu/grug.cfg
search.fs_uuid 927ccf30-88b7 root hd0,gpt2
set prefix=($root)’/ROOT/blesbok@/boot/grub’
configfile $prefix/grub.cfg
/boot/grub/grub.cfg’
…
set root=’cryptouuid/c03cff716cab4e93843db1f16b8ba5a8′
if [ x$feature_platform_search_hint = xy ]; then
search –no-floppy –fs-uuid –set=root –hint=’cryptouuid/c03cff716cab4e93843db1f16b8ba5a8′ 927ccf30-88b7
else
search –no-floppy –fs-uuid –set=root 927ccf30-88b7
…
set root=’hd0,gpt2′
if [ x$feature_platform_search_hint = xy ]; then
search –no-floppy –fs-uuid –set=root –hint-bios=hd0,gpt2 –hint-efi=hd0,gpt2 –hint-baremetal=ahci1,gpt2
Please remember to replace ALL occurances of these in the entire ‘/boot/grub/grub.cfg’
DO NOT RUN ‘update-grub’ IN CHROOT!!
That’s it.
Remember to fix up fstab and any other files if you’re using LUKS. ‘umount’
everything and reboot. From then on running ‘update-grub’ will make the
correct grub.cfg files.
_END
If you came here after a very long search trying to get Ubuntu cloud image working on Virt-manager, because you are getting the “GRUB_FORCE_PARTUUID attempting initrdless boot” error see here: https://askubuntu.com/questions/1375589/what-are-the-different-versions-available-as-ubuntu-cloud-images
Commenting out this line in the file /etc/default/grub.d/40-force-partuuid.cfg (as mentioned above) along with moving the other two files seems to have worked after using update-grub.
this source from : https://unix.stackexchange.com/questions/450946/grub2-using-wrong-boot-partition/645259#645259