20.10 Installer crashes with partitions being written but unable to inform kernel of the change

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1897173

This bug also occurred on daily xubuntu daily iso 20.10 20200924
on my Dell [Optiplex] 7010 ( i5-3470 , 16 GB, Intel Graphics 2500, Intel 82579LM GB Ethernet ,1TB hd) box and crashed my hard disk which became unbootable. The machine was set to boot in UEFI with secure boot mode.

Status changed to 'Confirmed' because the bug affects multiple users.

Confirmed.

Log mentions partman:parted_server.

I think that `partprobe` is the real reason, it is a part of `parted` package. Mark it as affected package.

Issue still occurring on 20200925 Ubuntu MATE daily.

And I can confirm the issue still occurring on 20200925 Xubuntu daily as well.

Xubuntu daily install on (setup for BIOS/legacy boot)
dell [optiplex] 990 (i7-2600, 16gb, nvidia geforce gt 6600 gt)

error reflected in pictures of comment #2 or #6 occurred
I continued installation, it stopped unable to write boot loader.
My attempts to select ssd repeatedly failed, I accepted it may not boot and completed installation.

On reboot "No boot device found. Press any key to reboot"

Currently all testcases about UM installation fail with symptoms:

GUI:

```
ERROR!!! (as superuser)

Partition(s) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.

[Ignore] [Cancel]
```

/var/log/partman , using QuickEMU

```
artman:parted_server: OUT: yes
partman:parted_server: Closing infifo and outfifo
partman:parted_server: main_loop: iteration 146
partman:parted_server: Opening infifo
partman:/lib/partman/commit.d/30parted: IN: COMMIT =dev=vda
partman:parted_server: Read command: COMMIT
partman:parted_server: command_commit()
partman:parted_server: Opening outfifo
partman:parted_server: command_commit: wiping superblocks from /dev/vda
partman:parted_server: do_wipe open(/dev/vda), 6
partman:parted_server: wiping superblocks from /dev/vda succeeded
partman:parted_server: OUT: Error
partman:/lib/partman/commit.d/30parted: error_handler: exception with type Error
partman:/lib/partman/commit.d/30parted: error_handler: reading message
partman:parted_server: OUT: Partition(s) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128 on /dev/vda have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes.
partman:parted_server: OUT:
partman:parted_server: OUT: Ignore
partman:parted_server: OUT: Cancel
partman:parted_server: OUT:

```

Using VirtualBox changes `/dev/vda` to `/dev/sda` and fails in the same way.

Just had this issue on Ubuntu daily with a "Install alongside" on
hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

The issue occurred on Xubuntu daily/beta iso 20.10 20200926

on 2 machines
1. Acer [Aspire] E3-111-P60S UEFI+secure boot
2. Dell [Optiplex] 7010 UEFI+secure boot

Still occurring on Ubuntu MATE 20200928 daily.

I just re-tried Xubuntu groovy daily (20200928); full disk install

uEFI failure on
- dell [optiplex] 990 (i7-2600, 16gb, nvidia geforce gt 6600 gt)

BIOS failure on
- hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

Attempt to install Ubuntu groovy daily (20200928); full disk install on two boxes I tried Xubuntu with, it's unusable on d990 due different (graphics) issue, however

It won't let me CANCEL or IGNORE the "ERROR!!! Partition(s) 4, 5, 6, 7 ...." message; it just remains locked at that window on either IGNORE or CANCEL. Whichever button I click is briefly COLORED/shaded as if click is recognized, but nothing else occurs; it remains stuck at the ERROR!!! popup.

Comment #15 was attempted install on
hp dc7700 (c2d-e6320, 5gb, nvidia quadro nvs 290)

I completed (comment #15, safe graphics, 20200929) Erase disk & install of Ubuntu (groovy) desktop on
- dell [optiplex] 990 (i7-2600, 16gb, nvidia geforce gt 6600 gt)

and despite getting the "ERROR! Partition(s) 4, 5, 6, 7, ...." message the install did complete & install booted.

Ubuntu Budgie Beta is affected by this issue.

Ubuntu MATE 20200930 beta is surprisingly no more affected by this bug.
Tested on QuickEMU legacy and EFI; and also on VirtualBox - both legacy and EFI.

@Bill (franksmcb), can you please confirm?

Latest iso spin 20200930 resolves this on Ubuntu MATE 20.10

xubuntu daily still fails to install on
dell [optiplex] 990 (i7-2600, 16gb, nvidia geforce gt 6600 gt)

but no appearance of the error message key to this bug. It's a bootloader issue I mentioned in comment #9 so I've started a new bug
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1897991

kubuntu daily however succeeded on
dell [optiplex] 990 (i7-2600, 16gb, nvidia geforce gt 6600 gt)

fixed in beta