When performing a system update (initiated the GUI way), I got caught in an infinite loop during update of grub-pc. See details below.
The system on which the problem arises and how it was set up
My computer is a dual boot Windows 10 / Xubuntu 18.04 one. It has 7 partitions on a DOS-partitioned SSD and it uses the EFI-mechanism during boot:
NAME LABEL FSTYPE MOUNTPOINT
sda
├─sda1 System-reserviert ntfs
├─sda2 SSD-Windows-Sys ntfs
├─sda3 SSD-EFI vfat /boot/efi
├─sda4
├─sda5 SSD-Linux-Home ext4 /home
├─sda6 SSD-Windows-Home ntfs
└─sda7 SSD-Linux-Sys ext4 /
When I got the computer some years ago, it only had Windows 10 plus the system reserved partition which now has become /dev/sda1. After I had resized partitions and created a separate partition for Windows home, I installed Xubuntu 16.04 and when doing so, I created a Linux System partition, a Swap partition plus a Linux-Home partition. I discarded the Linux Swap partition when I cloned everything to the SSD which was to replace the HDD which I had before (after intemediate steps to repair the not working boot setup).
When upgrading the system to Xubuntu 18.04 I got into much trouble: I was not offered the option to install it alongside Windows. I had to use the "something else" way during installation.
The result was a computer which either did not boot at all, or it booted only to Windows or it booted only to Linux. But /dev/sda7 looked to me like a system partition.
Probably with Xubuntu 16.04 the System-reserved partition also worked as ESP although it is formatted as ntfs. Its current content (possibly including leftover from the previous dual boot installation working with Xubuntu 16.04) is like this:
$ tree -L 3 /media/verwalter/System-reserviert/
/media/v/System-reserviert/
├── Boot
│ ├── BCD
│ ├── BCD.LOG
│ ├── BCD.LOG1
│ ├── BCD.LOG2
│ ├── bg-BG
│ │ └── bootmgr.exe.mui
│ ├── BOOTSTAT.DAT
│ ├── bootuwf.dll
│ ├── bootvhd.dll
│ ├── cs-CZ
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── da-DK
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── de-DE
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── el-GR
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── en-GB
│ │ └── bootmgr.exe.mui
│ ├── en-US
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── es-ES
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── es-MX
│ │ └── bootmgr.exe.mui
│ ├── et-EE
│ │ └── bootmgr.exe.mui
│ ├── fi-FI
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── Fonts
│ │ ├── chs_boot.ttf
│ │ ├── cht_boot.ttf
│ │ ├── jpn_boot.ttf
│ │ ├── kor_boot.ttf
│ │ ├── malgun_boot.ttf
│ │ ├── malgunn_boot.ttf
│ │ ├── meiryo_boot.ttf
│ │ ├── meiryon_boot.ttf
│ │ ├── msjh_boot.ttf
│ │ ├── msjhn_boot.ttf
│ │ ├── msyh_boot.ttf
│ │ ├── msyhn_boot.ttf
│ │ ├── segmono_boot.ttf
│ │ ├── segoen_slboot.ttf
│ │ ├── segoe_slboot.ttf
│ │ └── wgl4_boot.ttf
│ ├── fr-CA
│ │ └── bootmgr.exe.mui
│ ├── fr-FR
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── hr-HR
│ │ └── bootmgr.exe.mui
│ ├── hu-HU
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── it-IT
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── ja-JP
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── ko-KR
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── lt-LT
│ │ └── bootmgr.exe.mui
│ ├── lv-LV
│ │ └── bootmgr.exe.mui
│ ├── memtest.exe
│ ├── nb-NO
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── nl-NL
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── pl-PL
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── pt-BR
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── pt-PT
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── qps-ploc
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── qps-plocm
│ │ └── bootmgr.exe.mui
│ ├── Resources
│ │ ├── bootres.dll
│ │ └── de-DE
│ ├── ro-RO
│ │ └── bootmgr.exe.mui
│ ├── ru-RU
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── sk-SK
│ │ └── bootmgr.exe.mui
│ ├── sl-SI
│ │ └── bootmgr.exe.mui
│ ├── sr-Latn-CS
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── sr-Latn-RS
│ │ └── bootmgr.exe.mui
│ ├── sv-SE
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── tr-TR
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── uk-UA
│ │ └── bootmgr.exe.mui
│ ├── zh-CN
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ ├── zh-HK
│ │ ├── bootmgr.exe.mui
│ │ └── memtest.exe.mui
│ └── zh-TW
│ ├── bootmgr.exe.mui
│ └── memtest.exe.mui
├── bootmgr
├── BOOTNXT
├── BOOTSECT.BAK
├── EFI
│ ├── Boot
│ │ ├── bkpbootx64.efi
│ │ └── bootx64.efi
│ ├── Microsoft
│ │ ├── Boot
│ │ └── Recovery
│ └── ubuntu
│ └── shimx64.efi
├── Recovery
│ └── Logs
├── $RECYCLE.BIN
│ ├── S-1-5-21-1255711166-3792583174-1275079413-1008
│ │ └── desktop.ini
│ └── S-1-5-21-1255711166-3792583174-1275079413-1009
│ └── desktop.ini
├── System Volume Information
│ ├── Chkdsk
│ │ ├── Chkdsk20190923203942.log
│ │ └── Chkdsk20190923204533.log
│ ├── IndexerVolumeGuid
│ ├── tracking.log
│ └── WPSettings.dat
├── $WINRE_BACKUP_PARTITION.MARKER
└── WinSich
└── W530
58 directories, 103 files
Most probably the installation process (ubiquity) did not recognize this as EFI System Partition (ESP) and consequently it created not proper booting installation.
Finally I manually created an ESP, formatted as VFAT. During my last install process I manually marked this partition /dev/sda3/ in the GpartEd like part as “Use as EFI System partition”. This gave it the esp flag. The boot flag is to /dev/sda1 (what’s on that has been shown above).
But despite these settings, the system did not boot properly letting me choose in Grub-menu which system to boot. The Grub-bootloader was missing in the EFI partition.
I finally got this resolved by using the ISO image installation stick from which I had installed Xubuntu 18.04 onto /dev/sda7. There I did this (following the hint from How can I reinstall GRUB to the EFI partition?):
sudo mount /dev/sda7 /mnt
sudo mount /dev/sda3 /mnt/boot/efi
for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i;
mount
sudo chroot /mnt
grub-install /dev/sda
update-grub
exit
Finally I got a system which first shows me a Grub menu and lets me select the operating system to boot.
The Infinite Loop during System Update
I did a normal system update using the GUI way. This one included among others Linux-firmware, grub-efi-amd64.bin, grub-pc.bin. There this menu came up
dialogue devices for grub installation
When I let the mouse rest on the right sub window with the two check boxes, an explanation came up explaining that an upgrade of grub-pc was made. I should select for which devices grub-install should be done automatically. In most cases it would be reasonable to let it run automatically, so avoiding that the installed GRUB image does not fit to the Grub-modules or to grub.cfg. If I were unsure which device the BIOS uses to boot, it would be best to install GRUB in all devices. There also was a hint about the possibility to install GRUB into boot blocks of partitions. Some appropriate partitions were told to be offered here. This however would force GRUB to use a blocklist mechanism which were less reliable and therefore it was not recommended.
I in the first turn I checked both checkmarks because of my installation procedure (see above). But then I got this error message:
i-386-pc wird für Ihre Plattform installiert grub-install: Fehler: Für /, konnte kein GRUB-Laufwerk gefunden werden. Überprüfen Sie Ihre device-map.
accompanied with this dialogue telling me that Grub could not be written to the boot device and askint me wether I would continue. It was accompanied with a check box.
The help function explained that GRUB could not be installed in /. If I would continue, the computer possibly would not boot properly. Therefore I did not check the box in front of the question.
This returned me to the first dialogue asking for devices for GRUB-installation.
After I had checked both boxes last time, I first removed the checkmark from the first one. This led me again to the subsequent dialogue (see above). I did not check the checkmark in front of the question, as before which returnet me to where I always had been before.
This time I did mny choice exactly the other way around which in turn brought me to the same second dialogue (see above). So I am caught in an infinite loop unless I take the potentially harmful way out selecting none of the two offered partitions and checking the box in “Configure grub-pc”.
So, what shall I do? I don't want to get my system back to not booting at all or not letting me select which system to boot.
I let the computer run for four days without switching it off. Finally I had to do power it down anyway.
On the next reboot, I came through GRUB menu and could choose whether to boot Xubuntu or Windows 10. So in this case, the threat the computer possibly would not boot properly, was wrong. I am happy about that!
I looked at the GRUB version of the installed Xubuntu: It is 2.02-2ubuntu8.14. On an USB stick, onto which I had installed Xubuntu 18.04 before from the same ISO image, I have grub-common 2.02-2ubuntu8.13. Apparently this has changed on my SSD.
I also looked at the file dates of files and directories on the the ntfs-formatted partition /dev/sda1 which is labelled "System-reserviert": /media/username/System-reserviert/Boot/bg-BG and the other language specific files have timestamps of the day when I shut down the system. But looking closer at them and at /var/log/kern*.log to see when I finally shut down the computer, it shows me that at least two more Xubuntu boot events had happened before these time stamps were made. I am sure that I had also booted the computer into Windows before those timestamps were made.
Looking at /boot/efi/EFI/ubuntu/ (which is the mounted ESP partition /dev/sda3) I see that the more recent timestamps are from the day when I shut down the system (but from before this event). /boot/efi/EFI/ubuntu/grub.cfg also carries this timestamp (one from before shutting down the system). All files in /boot/EFI/ubuntu actually have time stamps from before shutting down after the upgrade which was causing this question.
One more strange thing: There is an empty directory /boot/efi/EFI/microsoft/boot. The file date of this direectory is of 2019-11-11, so it was there before this update. What's this directory good for? Is there something missing in it?
On one hand I am lucky that I did not get into booting trouble. On the other hand there must be a bug in the setting up of GRUB, at least in the installation procedure ubiquity which did not offer me tha option to install Xubuntu alongside the existing Windows 10. Further it would be worth looking at why I needed a special VFAT formatted Efi System partition (esp) and why the ntfs-formatted ntfs partition "System-reserved" can not serve this purpose any longer under Xubuntu 18.04. Apparently this was possible with Xubuntu 16.04.