** Attachment added: "6glf.png"
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+attachment/5760735/+files/6glf.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
** Attachment added: "5glf.jpg"
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+attachment/5760734/+files/5glf.jpg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
** Attachment added: "4glf.jpg"
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+attachment/5760733/+files/4glf.jpg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
** Attachment added: "3glf.jpg"
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+attachment/5760732/+files/3glf.jpg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
** Attachment added: "2glf.jpg"
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1396379/+attachment/5760731/+files/2glf.jpg
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
Hello,
This is an old issue but it still happens today and this is a big issue
as Ubuntu (and derivates like Kubuntu, Mint or Zorin) are often a
recommendation for beginners.
According to different tests made on GLF side (thanks Cammi), it seems
it occurs everytime with this schema:
1. You have
Vlad the installer is modifying the wrong EFI partition.
On Fri, May 20, 2022 at 5:00 PM Vlad Tudorache <1396...@bugs.launchpad.net>
wrote:
> I've encountered this bug today (2022-05-20) on Debian 11 and Ubuntu
> 22.04. Configuration:
> Samsung SSD 500 GB as /dev/sda
> - EFI System Partition
> -
I've encountered this bug today (2022-05-20) on Debian 11 and Ubuntu 22.04.
Configuration:
Samsung SSD 500 GB as /dev/sda
- EFI System Partition
- MSR
- NTFS (C:)
- Recovery
Toshiba HDD 2 TB as /dev/sdb
- 1,9 TB NTFS (D:)
- 512 MB (/dev/sdb2 -> /boot/efi)
- 2 GB swap (/dev/sdb3)
- 64 GB ext4
The bug also affects grub-efi-amd64-signed and grub-efi-amd64-bin
So if you follow the above workarounds you still get effected by the bug
eventually when one of these packages update.
** Also affects: grub-efi-amd64-signed (Ubuntu)
Importance: Undecided
Status: New
--
You received
I encountered this last week installing Ubuntu 22.04. I booted from USB
install media and installed to a second attached USB storage device. I
created an EFI system partition on the install target device, and
specifically selected this EFI system partition in the GUI as the place
to install the
Still unfixed in May 2022, just came up with Zorin OS 16.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
** Tags added: desktop-lts-wishlist
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
To manage
Ubiquity invokes the grub-installer bash script to perform the actual
boot loader install stuff - it reads the the grub-installer/bootdev
debconf value to know where to install the bootloader.
There is some logic in there to find a default boot device which I
suspect is how it's picking the first
So, what is the actual reason of the bug if you verified it with 21.10
but you also checked that it's setting a correct value?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer
I finally got ubiquity running in a debugger and it looks like the
previous code I mentioned is working fine. Ubiquity is correctly setting
the grub-installer/bootdev debconf value. The bug may lie in the grub-
installer program.
--
You received this bug notification because you are a member of
I believe the bug is in this function
https://git.launchpad.net/ubuntu/+source/ubiquity/tree/ubiquity/plugins/ubi-
partman.py?h=applied/ubuntu/impish#n797 (I may have selected the wrong
branch here but the same code is present in the 21.10 live CD).
I reported #1591352 when I was in high school
Ever wondered why Ubuntu is middle of the pack distro on distrowatch
nowadays? This is why.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition
I just came across this bug after being forced to reinstall my main OS - I got
my grub altered despite making no mistake when installing parallel ubuntu on
different device.
I was using 20.04 LTS and I am extremely disappointed with the reason: old bug
that made installer not trusted.
This is still happening in Ubuntu 21.10, and the installer interface is
very confusing.
I wanted to create an Ubuntu installer on an external drive, so I
connected the Ubuntu 21.10 live USB to one port, and an USB SSD to
another port.
When installing, I made sure to choose /dev/sdc (the usb ssd
This was just brought to my attention so I took a look at the source-
code. Thanks to oldfred's comment #20 showing part of the installer log
that helps isolate the source-code responsible.
It looks like this is a result of this code - written in 206 - assuming
a debconf entry that is empty and
> It doesn't corrupt boots. It's inconvenient.
Yes, it does corrupt boot setups. I'm not sure how you can say it
doesn't.
I mean I guess TECHNICALLY it "only" overwrites working boot setups,
with non-working boot setups; it's not actually corrupting existing
files with garbage data.
My
It doesn't corrupt boots. It's inconvenient.
On Wed, 1 Sept 2021, 15:31 martin, <1396...@bugs.launchpad.net> wrote:
> This sounds like a massive, GIGANTIC bug which is corrupting people's
> boot setups. It's a wonder that it hasn't been fixed after SEVEN YEARS.
>
> --
> You received this bug
This sounds like a massive, GIGANTIC bug which is corrupting people's
boot setups. It's a wonder that it hasn't been fixed after SEVEN YEARS.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
I sufer with this issue dor years, and it still haunts the hell out of me.
I'm tired of installing on special prepared hardware with no drives.
Please fix this asap.
Please with sugar on top!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I made a joke that when I scrolled down this would still happen ages
later and here we are.
The single most important thing to a new user experience, heck, *any
experience at all*, is the installation ease.
I can only wonder if the neglect of this issue is arising from contempt
for those who use
Thanks to all you guys for the description of the problem and the
suggested fix by changing the boot flag of the preexisting efi
partition. I spent quite some timee trying to fix this, since I thought
i might have done something wrong.
If I understand the problem correctly, Ubuntu has a bug for
Just installed Hirsute as of April 18,2021.
hirsute-desktop-amd64.iso
Same issue.
I tried to use Ubiquity installer options to change where grub is
installed and they did not work.
Used grub2's loopmount to boot ISO. It mounts isodevice to NVMe drive but
installer, when it asks to remove
k8s blah blah blah, but such a critical thing has been around for more
than six years. I can imagine how it can undermine the credibility of
Linux for newcomers...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Tags added: groovy
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
To manage notifications about this
Note: you don't have to physically remove the internal drive. You simple
need to temporarily remove the boot flag from the EFI partition, do the
install and the turn on the boot flag again. Very easy. I document it here:
https://askubuntu.com/a/1056079/152287
On Sun, 7 Mar 2021 at 02:46, Andrew
** Tags added: focal
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
To manage notifications about this
This appears to be the problem I ran into with Ubuntu Desktop 20.10 as reported
here:
https://askubuntu.com/questions/1321431/ubuntu-desktop-20-10-on-usb-flash-drive-boots-only-on-original-computer
If it is the same problem (and not a limitation with the latest [but
old] ASUS N551VW BIOS) then
I ran into the same issue. And I also think this bug is critical, not
high. I would be very happy if this could be fixed as soon as possible.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Just happened to me as well. Bricked my Windows install.
I wanted to try out Linux again to see where it's at in 2021. I decided
to go with the most common distro thinking it wouldn't have bugs like
this. Silly me.
Fix this. Pretty please with sugar on top.
--
You received this bug
You don't have to unplug them. The minimal workaround, and what I always
use, is before the install, unflag the EFI partitions of drives you don't
want to target. Somewhere in this bug report I have my tips on this, and I
also wrote it up here https://askubuntu.com/a/1056079/152287
On Sat, 30 Jan
I have lost about a month of my time with this bug!!
I thought I was doing something wrong with UUID or GPT vs MBR or ZFS or ...
It creamed my live benchmark system that I had spent considerable time
installing and customizing.
Just today, I stumbled onto this archaic bug report, which remains
The same issue.
Ubuntu broke my Windows EFI system partition, installing Ubuntu EFI on
it, despìte I have told Ubuntu to use the external drive.
*To fix the Windows EFI system partition:*
* Boot on Windows CMD using a Recovery Partition/USB Drive
** Windows Bootloader Recovery -> System
@ket I agree that this is frustrating.
You shouldn't have to reformat your disk to fix it, however. You should
be able to plug in the device with your newly installed Ubuntu, boot up
until you see the grub prompt asking you what system you want to boot,
and then choose the old Ubuntu version on
Would like to add that I believe this bug's priority should be changed
from High to Critical.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition
This bug has just killed my dual boot machine and I have no idea how to fix it
without formatting and reinstalling everything from scratch! How this *critical
bug* which was assigned High priority is open since 2014 is beyond my
understanding.
The installation UI simply lies to the user - it
I have also fallen foul of this bug after trying to install Ubuntu 20.10 on a
second disk.
I agree with the sentiment in post 41 specifically:-
1) Fix the option to choose boot device correctly
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Now also applies to Groovy.
Tried to install test version of Groovy into HDD. Did not want defaults
in NVMe SSD changed, so during Something Else install changed combo box
to sda, told it not to use ESP on NVMe drive, use ESP on sda. Also told
it not to use swap and it did not use swap, but used
A workaround is not relevant because the users that are hit by this bug don't
know that they need a workaround until it is too late. I don't remember ever
installing Linux and knowing beforehand that I need to apply a workaround to
circumvent the installer.
I know I sound like a broken record
I find it unbelievable that this serious bug, which has been confirmed
and given *high* importance, has still not been fixed nearly 6 years
after it was reported. When it happens it really f***s up your system
and recovering can be very painful.
--
You received this bug notification because you
Easiest workaround is to use gparted or similar to remove the EFI/boot flag
on existing EFI partitions before the install.
On Sun, 10 May 2020 at 19:55, Christian Nassau <1396...@bugs.launchpad.net>
wrote:
> I think I have just been hit by that bug too: fresh install of (X)Ubuntu
> 20.04 on a
I think I have just been hit by that bug too: fresh install of (X)Ubuntu
20.04 on a new computer with a new SSD, which also happened to have an
old HDD with an existing EFI boot paritition. I chose the "expert"
option for the partitioning dialog in install and explicitly specified
the new SSD as
I've just run into this bug on my 20.04 install, and I literally just do
not know how to manually fix it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI
This really needs to be fixed for 20.04 LTS... It's such a major bug
that hasn't been receiving any attention...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first
On computers with HDA or SDA drives it is possible to disconnect all drives
except the installation drive to install grub on the wanted drive.
This is however not a practical solution with NVme drives.
As I want to use the development version of Ubuntu early this is normally the
last
This still affects me on ubuntu-mate 19.10 amd64 also while selecting
the option "erase disk" which only prompts you to select a "single disk"
on which ubuntu will be installed even false summarizing that no other
disks/partitions will be altered which is a lie! This happens in both
UEFI and
This happened to me and bricked my computer too. Also +1 to @yoniamir's comment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even
I'd like to try and attempt fixing this issue if no one else is
currently working on it.
Though this will be my first time contributing code to ubuntu so I might
need some help :)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This is to confirm that the procedure mentioned by response #12 from Tim
Richardson solve my problem of being able to install Ubuntu on an
external drive without having its boot on my internal drive. This is
perfect. Thank you Tim Richardson. and oldfred who mentioned this page.
--
You received
Confirming I just had this exact same issue in Disco Dingo (19.04)
installation. Attached to my Windows SSD instead of my Ubuntu SSD
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
** Tags removed: rls-ee-incoming
** Tags added: rls-ee-notfixing
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
** Changed in: ubiquity (Ubuntu)
Importance: Medium => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
** Tags added: disco eoan rls-ee-incoming xenial
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
To
Also applies to Cosmic, Disco & Eoan. Never been fixed.
Just installed Debian Buster to see how it handled grub. I did not
select an ESP and it told me to go back and choose a partition as
/efi/boot. I choose sdb's ESP and it installed without issue to ESP on
sda, and did not overwrite my Ubuntu
** Tags added: bionic
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
To manage notifications about this
+1 to @yoniamir's comment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
To manage notifications about
Looking at the recent comments, I think you are taking this to the wrong
direction. There is no point in discussing a workaround for this bug,
because even knowledgeable users who know how to apply those workarounds
won't know that they even need to look for a workaround before it is too
late.
Noted that target is not mounted until sometime after partitioning
screen in Something Else. I unmounted & remounted after adding user &
password, but before continuing after that screen.
Also install still used original ESP in fstab. I had to go back & change
fstab from sda's ESP to external
oldfred method is working.
So while the system is busy formatting your drive change the mount partitions.
But still I believe this needs to be addressed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This bug is dangerous. I just bricked my company laptop because of it
(and will have a very inconvenient talk with IT support)
As long as it is not fixed, there should at least be a warning in the
installer - or the option to choose bootloader location greyed out)
--
You received this bug
Finally found work around.
Once installer started, I checked mount and mount target mounted ESP on sda.
Unmounted that partition & mounted ESP on sdc.
ubuntu-mate@ubuntu-mate:~$ history
1 mount
2 sudo umount /target/boot/efi
3 sudo mount /dev/sdc1 /target/boot/efi
4 mount
--
Seems to be the same bug as described here:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1591352
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI
Still an issue in 19.04 Disco.
Just installed again to sdb and just like comment above, said it was installing
to sdb's ESP, but overwrote my main working install's ESP on sda.
I cannot find any reference to installing to sda.
Installer sees sda as an ESP, but also sees sdb as ESP.
** Changed
Just installed 18.04.1 to flash drive sdd.
Installer said this:
Dec 27 19:29:45 ubuntu grub-installer: info: Installing grub on '/dev/sdd'
Dec 27 19:29:45 ubuntu grub-installer: info: grub-install does not support
--no-floppy
Dec 27 19:29:45 ubuntu grub-installer: info: Running chroot /target
Installed 19.04 to sdb drive (internal, but also flash drive as sdc) and
it overwrote my /EFI/ubuntu folder on sda.
I changed combo box which never has done anything with UEFI installs, but it
does then say during install that it is installing grub to sdb/external.
I clicked on ESP on sda, and
Hi, I'm tim richardson, a different entity to Red.
I just tested my instructions twice and updated the notes to make sure they are
reliable. There was one error which may have been signficant: I previously said
to select the EFI partition as the location to install the boot loader during
the
This just happened to me. I was super careful to select the correct
drive as I had two USB drives plugged in (one with the installer, one
the target of the install) on my Mac. Ubuntu was installed on the
correct USB, but the boot loader went on the Mac. I can still boot into
macOS by holding down
Susi,
It appears you aren't reading the full threads. Your solution does not
work. This has been a bug for YEARS and needs to be fixed.
I posted a possible real solution or at least how to get started with a
real solution above and on the other bug report for this same issue.
Please read the
FYI, you can use manual partitioning and mount the ESP of your choice in
/efi.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when
This just happened to me. I tried to put root on the SSD, but the
bootloader on the HDD, so that GRUB isn't on the same drive as the
Windows bootloader. It completely ignored my choice and installed GRUB
on the SSD anyway.
--
You received this bug notification because you are a member of Ubuntu
To clarify:
I installed Ubuntu in the manual mode. Manually selected the bootloader
to be installed on sdb. Still installed it on sda.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
If you use gparted to disable your existing EFI partition prior to install, and
if you have followed the advice to create a gpt partition table and an EFI
partition, you can work around it.
After the install, use gparted to reflag your internal EFI partition.
This worked for me with Ubuntu
** Description changed:
(k)ubuntu 14.04.1
package version: 2.02~beta2-9ubuntu1
- i installed ubuntu on my external hard disk, where i also have a previously
installed fedora system. i also have a windows
+ i installed ubuntu on my external hard disk, where i also have a previously
Some more info. I never perform automatic installs/partitioning, it’s
always 100% manual. I selected the EFI system partition from the Windows
drive and marked it as “Do not use partition”, selected the new EFI
system partition I created for Ubuntu and marked it as “EFI system
partition” (which is
This also happens on 18.04. Ubuntu installs the bootloader to the first
EFI system partition it finds, even though I select a second disk with a
second EFI system partition.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This appears to be a duplicate of 1173457.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1396379
Title:
installer uses first EFI system partition found even when directed
otherwise
To manage
I had specifically selected the new efi partition on a removable drive
as the place to install the boot loader, yet ubiquity ignored that and
installed grub and a grub.cfg file on the computers non-removable hard
disk. The newly installed efi/ubuntu/grub.cfg file specifies that the
grub menu be
When using ubiquity to install a second Ubuntu on the same system, this
effectively wipes out the first installation's boot loader, since grub-
install will overwrite an existing bootloader in /EFI/ubuntu on the EFI
system partition.
--
You received this bug notification because you are a member
82 matches
Mail list logo
