I try to do due diligence before upgrading between releases, especially when I know it is a big one. Over the years, I have had few problems and hardly ever have to bring out the emergency box to replace the main system.
Today I thought I was prepared because I had done my backups and even did a trial upgrade on my old pc that serves as my backup emergency system.
However, when I upgraded this morning I was met with silence after rebooting. So, after hauling out monitor and keyboard, I discover that my HP T-730 is stuck with a grub shim lock error. After some twenty years of dealing with grub, I have been fortunate enough to escape having this happen to me with IPFire.
I whipped out my trusty SuperGrub2 usb and managed to get the system booted. I then realized that I did not recall how to reinstall grub on IPFire.
A little frantic searching pointed me to /usr/bin/install-bootloader.
I am happy to report that it worked and the system now boots normally.
Have you checked the upgrade log in /opt/pakfire/logs/ if there are more details what happens here.
In line 180 of the upgrade script it calls the mentioned
/usr/bin/install-bootloader
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=config/rootfiles/core/183/update.sh;h=6d1e1fd2538a5d4115787cacb3dcbd14e4c28911;hb=ee4c8d28e493862cb630e79b7ffadd6807b465fa
So normal it should do the same as you have doneā¦
Here are the last 6 lines of the log:
dracut: *** Creating image file ā/boot/initramfs-6.6.15-ipfire.imgā ***
dracut: *** Creating initramfs image file ā/boot/initramfs-6.6.15-ipfire.imgā done ***
Found bootloader device: /dev/sda
Updating configurationā¦
Installing GRUB on /dev/sdaā¦
Could not install GRUB on /dev/sda
This is strange because you have used the same script to revive the systemā¦
Yeah! It puzzled me too.
I am just glad that I was able to get it to boot again.
I just got hit by this: a system stopped pakfire at āInstalling GRUB on /dev/sdaā¦ā. Does someone want me to collect more info on this (still running) system in some way?
All the last lines in the update log here:
dracut: *** Hardlinking files done ***
dracut: Could not find āstripā. Not stripping the initramfs.
dracut: *** Generating early-microcode cpio image ***
dracut: *** Constructing AuthenticAMD.bin ***
dracut: *** Constructing GenuineIntel.bin ***
dracut: *** Store current command line parameters ***
dracut: *** Creating image file ā/boot/initramfs-6.6.15-ipfire.imgā ***
dracut: *** Creating initramfs image file ā/boot/initramfs-6.6.15-ipfire.imgā done ***
Found bootloader device: /dev/sda
Updating configurationā¦
Installing GRUB on /dev/sdaā¦
This update log looks correct. āInstalling GRUB on /dev/sdaā¦ā is the last line of a correct update.
Hm, OK. The update was never marked as finished however and the web UI didnāt restartā¦ thatās why I thought it had failed. Guessing I have to reboot it ans see what happens, thenā¦
Fingers crossed!
I am curious to know the hardware you are using. My machine is a HP T730 with AMD CPU. Hope you have a SuperGrub2 handy, just in case.
Itās actually a converted laptop, a Dell e7240 with an Intel CPU. If any problems crop up it will be swiftly reinstalledā¦ I can access it via SSH, so the backup is already salvaged.
I had backups and could reinstall. It was just simpler to fix the grub.
Would be nice, if logfiles in /var/log/pakfire begin with a line like
starting update to core *** now.
and end with a line
finished update to core *** successfully.
There is in the message log. Is that not good?
Look for:
Feb 4 13:45:51 ipfire4 pakfire: CORE UPGR: Upgrading from release 180 to 182
. . .
Feb 4 14:00:57 ipfire4 pakfire: PAKFIRE UPGR: core-upgrade-182: Finished.
I know, but /var/log/messages is full of other messages and slightly older messages are logrotated away in gz-files, while log files in /var/log/pakfire stay foreverā¦ and are a good source for trouble shooting concerning the update routine.
/var/log/messages is hold for 52 weeks ( one year ).
All files are text files and therefore searchable with grep.
gz-files must be decompressed with gzip -d.
This is the way the WebGUI differentiates the several topics and goes back in history.
This is what I use when troubleshooting:
for logf in $(ls -1tr /var/log/messages*) ; \
do zgrep --color --fixed-string --text \
-e "CORE UPGR: Upgrading from release" \
-e "PAKFIRE UPGR: core-upgrade" $logf ; done
It takes about 20 seconds to go through 52 weeks of logs:
Use zgrep. It avoids needing to unzip the file first.
Sorry. I was beaten to it because of dinner.
I know. 
I just wanted to describe the whole process. @jon has given a nice solution.
I am happy to say that the upgrade from 183 to 184 worked without issue!