On 19.04 I still get my grub.cfg broken by normal updates. Not by kernel updates, and not by running update-grub. But there is some package that whenever that package is updated, part of the update process generates a new grub.cfg, and it's a broken one because it makes a bad assumption somewhere.
I eneded up writing myself a little "check_grub_efi_xfs" script that I run any time I think I saw anything about grub fly by when I run "apt upgrade", or, any time grub gets screwed up I run it after I get myself back in. It's only about 3 lines of code that actually matters, but writes a lot of stuff to the screen just so you don't have ANY worries about it what it did and if your boot files are currently ok before you shut down. Ideally this should run just before shutdown on every single shutdown. Then you'd never have to worry about it. The only way you'd miss an update again is if you had an ungraceful shutdown after an apt upgrade that included a grub packege update. But despite being a unix and linux admin for over 20 years, I have so far utterly failed to get systemd to do such a simple task. If someone can show me exactly how to write a freaking unit file that does that, I'd be pretty grateful. Just to refresh, the issue here is, it's possible to install ubuntu with xfs root fs to a machine that already has a factory Win10 install and boot files in a factory EFI partition, without having to make any special /boot partition. All you really need is to place a copy of xfs.mod onto the EFI partition, which is a FAT filesystem that grub already reads files from at boot. And edit the initial grub.cfg that's in the EFI filesystem so that it loads xfs.mod from there too. Then everything else is fine. The rest of /boot can be in "/", and "/" can be xfs. This allowed me to degfrag and resize the factory Win10 without wiping and reinstalling, install linux in the freed space, with xfs root fs, and no other partition or filesystem changes needed. I can boot back and forth between the original Win10 install or linux with no problem. It didn't break Win10 booting. It's a perfectly valid and "legal" arrangement, and anything that automatically writes grub config files should have to allow for this possibility without breaking it. Screen capture from a run of this fixup script, just after today's apt upgrade which broke my grub.cfg once again. This is today 2019 02 26, so I don't know where the supposed fix is. It's definitely not yet in 19.04 or in grub-* 2.02+dfsg1-5ubuntu11 So this run shows the actions when it detects that it actually has something to do. Most times, it will detect that it doesn't have to do anything, and it will take no action those times. This, and the script itself (attached) should serve as detailed documentation of the admittedly uncommon configuration, and exactly how it gets broken, and exactly how it gets un-broken. ---snip--- root@negre:~# check_grub_efi_xfs Checking for broken grub + efi + xfs config... EFI System Partition ESP_DIR=/boot/efi/EFI/ubuntu total 3488 -rwx------ 1 root root 108 Aug 14 14:47 BOOTX64.CSV -rwx------ 1 root root 141 Jan 25 11:13 emergency.cfg drwx------ 2 root root 4096 Dec 14 2017 fw -rwx------ 1 root root 73565 Jan 17 23:08 fwupx64.efi -rwx------ 1 root root 117 Feb 6 12:57 grub.cfg -rwx------ 1 root root 1105784 Feb 6 12:57 grubx64.efi -rwx------ 1 root root 1153336 Aug 14 14:47 mmx64.efi -rwx------ 1 root root 141 Jan 25 11:13 old.cfg -rwx------ 1 root root 1196736 Aug 14 14:47 shimx64.efi -rwx------ 1 root root 92 Mar 5 2018 static.cfg -rwx------ 1 root root 10416 Jan 25 11:13 xfs.mod Grub-* package's xfs.mod XFS_MOD=/boot/grub/x86_64-efi/xfs.mod -rw-r--r-- 1 root root 10416 Feb 6 12:57 /boot/grub/x86_64-efi/xfs.mod Checking xfs.mod ... /boot/efi/EFI/ubuntu/xfs.mod is present -rw-r--r-- 1 root root 10416 Feb 6 12:57 /boot/grub/x86_64-efi/xfs.mod -rwx------ 1 root root 10416 Jan 25 11:13 /boot/efi/EFI/ubuntu/xfs.mod /boot/efi/EFI/ubuntu/xfs.mod is older than /boot/grub/x86_64-efi/xfs.mod Updating /boot/efi/EFI/ubuntu/xfs.mod '/boot/grub/x86_64-efi/xfs.mod' -> '/boot/efi/EFI/ubuntu/xfs.mod' Checking /boot/efi/EFI/ubuntu/grub.cfg ... /boot/efi/EFI/ubuntu/grub.cfg does not contain insmod xfs (A grub-* package update has generated a new /boot/efi/EFI/ubuntu/grub.cfg incorrectly) emergency.cfg exists Copying current emergency.cfg to old.cfg '/boot/efi/EFI/ubuntu/emergency.cfg' -> '/boot/efi/EFI/ubuntu/old.cfg' Generating a new emergency.cfg by prepending insmod xfs to the new grub.cfg Summary: /boot/efi/EFI/ubuntu/grub.cfg before apt upgrade: insmod $cmdpath/xfs.mod search.fs_uuid 7bd784f6-f235-4b24-bb7b-eb607b1f0515 root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg /boot/efi/EFI/ubuntu/grub.cfg after apt upgrade: search.fs_uuid 7bd784f6-f235-4b24-bb7b-eb607b1f0515 root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg /boot/efi/EFI/ubuntu/emergency.cfg we just generated: insmod $cmdpath/xfs.mod search.fs_uuid 7bd784f6-f235-4b24-bb7b-eb607b1f0515 root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg Copying new emergency.cfg over grub.cfg '/boot/efi/EFI/ubuntu/emergency.cfg' -> '/boot/efi/EFI/ubuntu/grub.cfg' Finished This is the /boot/efi/EFI/ubuntu/grub.cfg currently in effect for the next boot: --- insmod $cmdpath/xfs.mod search.fs_uuid 7bd784f6-f235-4b24-bb7b-eb607b1f0515 root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg --- root@negre:~# ---snip--- ** Attachment added: "check_grub_efi_xfs" https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1652822/+attachment/5236610/+files/check_grub_efi_xfs -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1652822 Title: grub efi doesn't install fs module needed to access root To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1652822/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
