This page is just for reference and to explain what happens when you
upgrade grub without grub-install being run afterwards. The alpine
official docs should take precedence over what is listed here. An
official note on this is now up from Alpine itself:
https://wiki.alpinelinux.org/wiki/Release_Notes_for_Alpine_3.20.0#grub_2.12
Don't use these instructions verbatum. Refer to them at your own
risk. Your system is likely configured differently than mine so your
solution will most likely need modifications to be successful and
not cause any data loss. The purpose of this writeup is to give you
an idea of what is necessary, not necessarily the exact process.
What happened: grub updated and now system is un-bootable
I recently upgraded my alpine edge system and due to lack of coffee
didn't notice that grub was updated. Grub was updated from
2.06->2.12 and apk will not automatically run the grub-install
command. This results in unbootable system which isn't a bug, it's
just something you might have to do yourself.
Prior to the update, my system's high level basic config is the
following. EFI boot, no encryption, using ZFS but not for my root
or boot partition so I'm not including those details, they don't
matter in my case:
Filesystem Size Used Avail Use% Mounted on
/dev/nvme1n1p3 464G 65G 376G 15% /
/dev/nvme1n1p1 511M 296K 511M 1% /boot/efi
The fix at a high level is to boot a rescue alpine disk (I use
alpine-extended iso from 3.19).
step1 boot alpine-extended 3.19 iso image from USB to perform rescue
We need to mount _both_ my root (/) and EFI partition
hierarchically under /mnt as such:
localhost# mount -t ext4 -o rw /dev/nvme1n1p3 /mnt
localhost# mount -t vfat -o rw /dev/nvme1n1p1 /mnt/boot/efi
We will eventually chroot into this environment but first we need to
mount some of the in-memory file systems so that commands will work
properly later:
localhost# mount -t proc none /mnt/proc
localhost# mount -t sysfs /sys /mnt/sys
localhost# mount --bind /dev /mnt/dev
localhost# mount --bind /dev/pts /mnt/dev/pts
Now we are going to chroot into /mnt so that we can pretend we can
use the new grub user tools that we accidentally updated to:
localhost# chroot /mnt
These commands are now from the perspective of your un-bootable
system and we will now run the grub-install command as such. You
will need to make sure these paths and arguments match your personal
config:
chroot# grub-install --target=x86_64-efi --bootloader-id=GRUB \
--efi-directory=/boot/efi --no-nvram --removable
Before we are done, also make sure that your /etc/default/grub file
is in the correct state. Specifically the line:
GRUB_CMDLINX_LINUX_DEFAULT="some stuff in here - important"
If the grub update left this file missing that line and your line
had custom settings, they might have been lost, add that line back
if missing/needed. In my case, it specifies modules and other
settings:
modules=sd-mod,usb-storage,ext4,nvme quiet cgroup_no_v1=all rootfstype=ext4
See the docs for grub-mkconfig for more information. Also, if you
are smart, save the contents of /proc/cmdline for your system in
case you ever want to know what is being passed to your kernel at
boot time.
After this, I just type exit from the chroot, umount the file
systems and rebooted.
chroot# exit
localhost# umount /mnt/boot/efi
localhost# umount /mnt
localhost# reboot
Your mileage may vary, but this is the process I use for my system.
Addendum: What does the EFI hierarchy look like when grub-install is
run successfully? On my system it looks like this:
/boot/efi
|- EFI/
|----| alpine/
| |----- grubx64.efi
|----| boot/
|----- bootx64.efi
Also, it's good to know how EFI is setup on your computer, the tool
efibootmgr is usefule for this. Examine the configuration below:
$ efibootmgr
BootCurrent: 000D
Timeout: 1 seconds
BootOrder: 000D,000E,000F,0010
Boot0002 Samsung SSD 960 PRO 512GB BBS(HD,,0x0)0000424f
Boot0005 INTEL SSDPEDMW012T4 BBS(HD,,0x0)0000424f
Boot0006 INTEL SSDPEDMW012T4 BBS(HD,,0x0)0000424f
Boot000B iODD External HDD BBS(HD,,0x0)0000424f
Boot000D* UEFI OS HD(1,GPT,84d302fc-7c77-7245-b630-2248ddc49b30,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
Boot000E* Samsung SSD 960 PRO 512GB BBS(HD,,0x0)0000424f
Boot000F* INTEL SSDPEDMW012T4 BBS(HD,,0x0)0000424f
Boot0010* INTEL SSDPEDMW012T4 BBS(HD,,0x0)0000424f
Note the lines: BootCurrent:, BootOrder: and Boot000D* above. We have:
BootCurrent -> 000D and the Boot000D line tells EFI to use a file
named efi\boot\bootx64.efi:
Verbose output:
$ efibootmgr -v
BootCurrent: 000D
Timeout: 1 seconds
BootOrder: 000D,000E,000F,0010
Boot0002 Samsung SSD 960 PRO 512GB BBS(HD,,0x0)0000424f
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot0005 INTEL SSDPEDMW012T4 BBS(HD,,0x0)0000424f
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot0006 INTEL SSDPEDMW012T4 BBS(HD,,0x0)0000424f
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot000B iODD External HDD BBS(HD,,0x0)0000424f
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot000D* UEFI OS HD(1,GPT,84d302fc-7c77-7245-b630-2248ddc49b30,0x800,0x100000)/File(\EFI\BOOT\BOOTX64.EFI)0000424f
dp: 04 01 2a 00 01 00 00 00 00 08 00 00 00 00 00 00 00 00 10 00 00 00 00 00 fc 02 d3 84 77 7c 45 72 b6 30 22 48 dd c4 9b 30 02 02 / 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot000E* Samsung SSD 960 PRO 512GB BBS(HD,,0x0)0000424f
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot000F* INTEL SSDPEDMW012T4 BBS(HD,,0x0)0000424f
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 00 00 42 4f
Boot0010* INTEL SSDPEDMW012T4 BBS(HD,,0x0)0000424f
dp: 05 01 09 00 02 00 00 00 00 / 7f ff 04 00
data: 00 00 42 4f