Comment 2 for bug 1898022

I was looking around and found this:

$ df -h
Filesystem Size Used Avail Use% Mounted on
udev 3,8G 0 3,8G 0% /dev
tmpfs 786M 3,5M 783M 1% /run
/dev/sda8 28G 18G 9,0G 66% /
tmpfs 3,9G 277M 3,6G 8% /dev/shm
tmpfs 5,0M 4,0K 5,0M 1% /run/lock
tmpfs 3,9G 0 3,9G 0% /sys/fs/cgroup
/dev/loop1 56M 56M 0 100% /snap/core18/1885
/dev/loop0 240M 240M 0 100% /snap/chromium/1328
/dev/loop3 31M 31M 0 100% /snap/snapd/9279
/dev/loop2 63M 63M 0 100% /snap/gtk-common-themes/1506
/dev/sda6 453M 173M 253M 41% /boot
/dev/sda9 93G 73G 16G 83% /home
/dev/sda2 993M 33M 960M 4% /boot/efi
tmpfs 786M 20K 786M 1% /run/user/1000

Maybe; but I wouldn't be too sure that it was like that before, with the /boot/efi.

It was strange though, that after having added *buntu to W10 some two years ago, though without a hitch, I had found two W10 boot partitions in grub, I think sda2 and sda3. Both had booted properly, whichever I selected. Never understood that; and never really bothered.
Maybe, only maybe, this helps explaining the misbehaviour encountered at upgrade?
Btw. sda3 is now fat32, with the label SYSTEM_DRV.