Install hang on dual boot machine - vfat in scsi7 partition #2 (sdb) at /boot/efi

[foo2bar]

Hello everybody

I'm hoping someone can point me in the right direction to fix my problem.
I have been a long time user of ubuntu and have many single and dual boot machines. I was attempting to upgrade a dual boot laptop from vanilla ubuntu 16.04 to 20.10 by replacing 16.04 with 20.10 ubuntuunity (I just don't like gnome - it's way too clunky after having used unity for ages). I know it's not a fully fledged official ubuntu version ... but I'm taking a punt here so please be kind!

As I wanted to preserve the windows10 and the linux /home partition, I chose "something else" when reaching the section on partitioning the disk.

Before installation I had the following setup:

sda1: physical partition; ntfs; system reserved; ~500MB
sda2: physical partition; nrfs; windows os; ~30GB
sda3: extended partition containing

sda5: logical partition; ext4; / (root partition); 18GB

sda6: logical partition; linux swap

sda7: logical partition; ext4; /home; 93GB

sda4: physical partition; ntfs; 69GB

I chose sda5 as the location for the new root partition (with formatting), sda6 as the new location for the swap partition and sda7 as the location for /home (no formatting). For the device location of the boot loader I left it as the default /dev/sda.

Clicking through onto the next page to enter the locale (UK) there as a popup stating

"The attempt to mount a file system with type vfat in scsi7 (0,0,0) partition #2 (sdb) at /boot/efi failed."

I carried on regardless and it just sat there for ages doing nothing in particular. Having a read around, it seems others had a similar problem ages ago (2012) whereby attempting to preserve /home by choosing to not format it was a problem (something about a race condition /home not being unounted in time). I tried the work around (don't target /home in the installation and add in after the installation). That didn't work either.

I then chose to delete sda5, sda6, sda7 and then recreate them. That didn't work either. I then deleted sda5, sda6, sda7 but only recreated sda5 and sda6 - still no good.

I have tried mounting all ntfs partitions on sda manually using disks and gparted - they mount successfully.

The strange thing is that the message refers to "partition #2 (sdb)". sdb is the usb stick and partition 2 is the efi boot partition - all created from the iso I had to write the iso using dd as startupdisk creator didn't recognise it).

This is the state of the machine at the moment.

ubuntu@ubuntu:~$ blkid | grep sda
/dev/sda1: LABEL="System Reserved" BLOCK_SIZE="512" UUID="D464179864177D04" TYPE="ntfs" PARTUUID="7bb10d49-01"
/dev/sda2: LABEL="Windows OS" BLOCK_SIZE="512" UUID="6C96350C9634D7F2" TYPE="ntfs" PARTUUID="7bb10d49-02"
/dev/sda4: LABEL="Shared" BLOCK_SIZE="512" UUID="6DCF9AAF59C48098" TYPE="ntfs" PARTUUID="7bb10d49-04"
/dev/sda5: UUID="a95baff6-3c41-47c4-8ef9-06dbcdc15e1a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="7bb10d49-05"
/dev/sda6: UUID="c2ce3c09-4d65-41f8-839d-43ee599028a3" TYPE="swap" PARTUUID="7bb10d49-06"
ubuntu@ubuntu:~$ blkid | grep sdb
/dev/sdb2: SEC_TYPE="msdos" UUID="6FFF-D6F6" BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="EFI boot partition" PARTUUID="a8da6173-d491-4958-b4c2-6e7bc09402b0"
/dev/sdb3: BLOCK_SIZE="2048" LABEL="ISOIMAGE" TYPE="hfsplus" PARTLABEL="HFSPLUS" PARTUUID="a8da6173-d491-4958-b4c3-6e7bc09402b0"
/dev/sdb5: LABEL="writable" UUID="37896b39-5cf2-4551-a619-7a64cc170e4a" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="36ae7aa9-a693-b84a-9f7c-a758c7f40dd7"

Ideas anyone? (apart from go and ask the ubuntuunity team)

Thanks

[tea for one]

It looks like you have booted the Ubuntu Unity installer in UEFI mode but you do not have an EFI partition.

Possibly the Ubuntu Unity installer is different to the Ubuntu installer?
Which Windows version in your dual boot?
Why do you have extended partitions (sda4 to sda6)?

Windows 10 requires UEFI mode with GPT, which allows more than 4 primary partitions.

I would suggest that you back up all your personal data and re-install both systems using UEFI mode and GPT.
https://help.ubuntu.com/community/UEFI

Have you also opened a thread here https://www.foss.ubuntuunity.org/for...-boot-machine?

[howefield]

Thread moved to the "Ubuntu/Debian BASED" forum for a better fit.

[foo2bar]

It looks like you have booted the Ubuntu Unity installer in UEFI mode but you do not have an EFI partition.

Possibly the Ubuntu Unity installer is different to the Ubuntu installer?
Which Windows version in your dual boot?
Why do you have extended partitions (sda4 to sda6)?

Windows 10 requires UEFI mode with GPT, which allows more than 4 primary partitions.

I would suggest that you back up all your personal data and re-install both systems using UEFI mode and GPT.
https://help.ubuntu.com/community/UEFI

Have you also opened a thread here https://www.foss.ubuntuunity.org/for...-boot-machine?

I don't think I have changed the way that I boot the machine - or rather - I haven't gone into the bios and changed anything. Before I started installation, both windows10 and ubuntu booted fine. I just chose which one I wanted to launch at the grub screen.
The machine boots (or rather it did before it broke) into windows10 or ubuntu 16.04.

I just used the iso from http://linux.darkpenguin.net/distros...u-unity/20.10/ which you get to from https://ubuntuunity.org/download/ and flashed a 4GB usb stick using dd. I did check the md5 hash and it matched the iso.

I can't remember why I used extended partitions - it was such a long time ago that I worked on this machine so I can't remember the rationale - apart from probably because I wanted more than 4 partitions to segment the linux installation. Maybe at the time I didn't realise that GPT didn't limit the number of partitions to 4.

Ideally I would do the backup ... but i'm a bit worried now that I won't be able to restore windows10. I recall that this machine had windows10 as a result of the free upgrade from windows7 to windows10 - so there are no discs etc.

Regarding the duplicate thread - yes - I opened that there not knowing whether the two communities would "talk" to each other so thought I would increase my chance of getting a reply.

gparted does report that the partition table is of type msdos rather than GPT. I've checked the BIOS and UEFI boot support has been disabled - so that matches up with the partition table type being MSDOS.

I've got several machines which are all partitioned in the same way and in which both windows10 and ubuntu co-exist happily.

[foo2bar]

Just thinking about your first response

It looks like you have booted the Ubuntu Unity installer in UEFI mode but you do not have an EFI partition.

Are you saying that the USB stick with ununtuunity (sdb) has been booted as if it's in UEFI mode? I don't see how that is possible given that the BIOS has UEFI mode disabled.
Just had a look at gparted again and sda1 has the boot flag set. All things point to sda being in legacy/BIOS mode - not UEFI.

Do different devices get booted using different schemes? e.g. SDD/hard drives are booted as BIOS/legacy mode but external USBs are booted as UEFI mode?
I did follow the link https://help.ubuntu.com/community/UEFI and it showed the different screens that would show in the boot sequence highlighting the difference between legacy vs UEFI mode. When the USB stick boots, it looks like the screen for UEFI booting.

[oldfred]

If Windows is in BIOS boot mode on MBR drive, you need to install Ubuntu in BIOS boot mode.
But Microsoft has required vendors to install in UEFI mode to gpt drives since 2012.
But upgrades from Windows 7 were usually still BIOS/MBR.

There was some issue with 20.10 where it always wants an ESP - efi system partition.
I might try 20.04 since it is LTS and you do not need newest kernel & drivers for your older hardware.
Or just add a tiny FAT32 partition with esp flag, to make installer happy.

[tea for one]

Legacy bios mode is not ideal for Windows 10 and i still suggest that you back up and install both Windows and Ubuntu Unity in UEFI mode with GPT.

You can download a copy of Windows 10 direct from Microsoft and I would hope that your existing activation key will be OK.
If Windows is your priority, then you should check with Microsoft and/or a Windows forum about activating a Windows 10 installation with a Windows 7 key.

[foo2bar]

Activation key?
I foolishly just went ahead with the installation (thinking it would be fine) without booting into windows to get the product/installation key. I'll not make that mistake again.

[foo2bar]

If Windows is in BIOS boot mode on MBR drive, you need to install Ubuntu in BIOS boot mode.
But Microsoft has required vendors to install in UEFI mode to gpt drives since 2012.
But upgrades from Windows 7 were usually still BIOS/MBR.

There was some issue with 20.10 where it always wants an ESP - efi system partition.
I might try 20.04 since it is LTS and you do not need newest kernel & drivers for your older hardware.
Or just add a tiny FAT32 partition with esp flag, to make installer happy.

Just to rule out whether it is a quirk with ubuntuunity's installer versus regular ubuntu, I am going to try the installation with just ubuntu 20.10 and see if that coughs with the same problem.

If I was going to do the last suggestion

Or just add a tiny FAT32 partition with esp flag, to make installer happy

, could that partition be anywhere?

[foo2bar]

I have just flashed a USB stick with ubuntu 20.10.
On boot I did get a message saying "1 error was found" whilst checking the files. I carried on anyway (!), partitioned the disk as I wanted (sda5=/, sda6=swap, sda7=/home) and was able to progress to the page where you select your locale without any error. To all intents and purposes, the installation was fine until I got the following error:

Executing 'grub-install /dev/sda' failed.
This is a fatal error.

I was so pleased that it had managed to progress without throwing up the previous error (which made me conclude there is a difference between ubuntu's and ubuntuunity's installer) but success was short lived.

I had a look at syslog which reports the following just before the error:

ubuntu grub-installer: info: architecture: amd64/efi
...
ubuntu ubiquity: volume group "sda" not found
ubuntu ubiquity: cannot process volume group sda
...
ubuntu grub-installer: info: identified partition label for /dev/sda5: msdos
ubuntu grub-installer: info: installing rub on '/dev/sda'
...
ubuntu grub-installer: info: Running chroot /target grub-install --force --target x86_64-efi "/dev/sda"
ubuntu grub-installer: info: Installing for x86_64-efi platform
ubuntu grub-installer: grub-install: error: cannot copy '/usr/lib/grub/x86_64-efi-wigned/grubx64.efi.signed' to '/boot/efi/EFI/ubuntu/grubx64.efi': No space left on device
ubuntu grub-installer: error: Running 'grub-install --force --target x86_64-efi "/dev/sda"' failed

I have no idea what's going on here - because the BIOS is in legacy mode and sda is MSDOS not GPT - so why on earth is it trying to install grubx64.efi?

And which partition is it targeting for /boot/efi/EFI/ubuntu/grubx64.efi? sda1 (the windows reserved partition) or sda5 which is meant to be /?