Score:0

Ubuntu installer attempts to mount an untargeted partition

in flag

I have a machine with two disks. Both were LVM and encrypted. I wanted to install Kubuntu 20.04 on /dev/sdb and formatted it and created a GPT partition table and the necessary partitions. When I run the installer and set the partitions up for the installation I make sure that all partitions from /dev/nvme0n are set to "do not use". However, the installer keeps trying to mount /dev/nvme0n1p1 which is the EPS of that drive. But it was set to "do not use". Luckily the mounting fails to due the encryption I think. Otherwise, the installer might possibly have overwritten my data on some of the /dev/nvme0n1p1 partitions. Ok, what do I need to do to get the installer to not attempt mounting that partition so I can install the OS on /dev/sdb?

Here are some outputs and screenshots:

btw. clicking "Continue" does not help. The installation process is stuck at 33%.

kubuntu@kubuntu:~$ sudo fdisk -l
Disk /dev/loop0: 1.75 GiB, 1858924544 bytes, 3630712 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/nvme0n1: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 970 EVO Plus 1TB            
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 6AF63064-BC79-4242-98B0-F2F47E638A21

Device           Start        End    Sectors  Size Type
/dev/nvme0n1p1    2048    2099199    2097152    1G EFI System
/dev/nvme0n1p2 2099200    3147775    1048576  512M Microsoft basic data
/dev/nvme0n1p3 3147776 1953523711 1950375936  930G Linux filesystem


Disk /dev/sda: 232.91 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 860 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 380EEC9B-8432-3048-B0AD-D19964B52D70

Device        Start       End   Sectors   Size Type
/dev/sda1      2048   2099199   2097152     1G EFI System
/dev/sda2   2099200  18876415  16777216     8G Linux swap
/dev/sda3  18876416  20973567   2097152     1G Linux filesystem
/dev/sda4  20973568  99098623  78125056  37.3G Linux filesystem
/dev/sda5  99098624 488394751 389296128 185.6G Linux filesystem


Disk /dev/sdb: 57.31 GiB, 61530439680 bytes, 120176640 sectors
Disk model: Ultra           
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x5a83b7c0

Device     Boot   Start       End   Sectors  Size Id Type
/dev/sdb1  *          0   5162175   5162176  2.5G  0 Empty
/dev/sdb2       5123264   5131263      8000  3.9M ef EFI (FAT-12/16/32)
/dev/sdb3       5165056 120176639 115011584 54.9G 83 Linux
kubuntu@kubuntu:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
loop0         7:0    0   1.7G  1 loop /rofs
sda           8:0    0 232.9G  0 disk 
├─sda1        8:1    0     1G  0 part 
├─sda2        8:2    0     8G  0 part [SWAP]
├─sda3        8:3    0     1G  0 part /target/boot
├─sda4        8:4    0  37.3G  0 part /target
└─sda5        8:5    0 185.6G  0 part 
sdb           8:16   1  57.3G  0 disk 
├─sdb1        8:17   1   2.5G  0 part /cdrom
├─sdb2        8:18   1   3.9M  0 part 
└─sdb3        8:19   1  54.9G  0 part /var/crash
nvme0n1     259:0    0 931.5G  0 disk 
├─nvme0n1p1 259:4    0     1G  0 part 
├─nvme0n1p2 259:5    0   512M  0 part 
└─nvme0n1p3 259:6    0   930G  0 part 

enter image description here

enter image description here

enter image description here

cc flag
Sounds like launchpad bug 1396379. Disconnect the disk or make unavailable in firmware settings.
lo tolmencre avatar
in flag
Thanks. Might indeed be that. Taking out the other drive of course solved it... even if it was a different reason.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.