i have checked the solution but it didnt helped me!
20200811 Groovy ISO - Xubuntu is still affected by https://pad.lv/1885414 .
I have a question to @xnox,
I have noticed that USB boot drives cloned from the current Groovy iso files do not boot in UEFI mode with secure boot (I tested standard Ubuntu desktop and Lubuntu). Is this the intended behaviour, or a bug?
Some of us think it is a bug, see
1 Like
That would certainly be a bug. But this is not reproducible for me with the current groovy daily image (http://cdimage.ubuntu.com/ubuntu/daily-live/20200826/) in a VM configured with SecureBoot using the Microsoft keys.
1 Like
Just for completenessā¦ re: issue with lp 1892754
- @vorlon has found the issue (#ubuntu-release); turns out it wasnāt grub but cd-boot-images
- fix has been committed, thanks
and in a day (or so) our daily ISOs will boot from thumb-drives again.
1 Like
Hello,
during the last days I tested installing Kubuntu (and Ubuntu) daily live images in VirtualBox, and on manual partitioning the installation fails when installing grub as described in lp:1885414 . During manual partitioning, I get the following warning regarding a āmissing EFI System Partitionā:
That warning irritates me because EFI isntā enabled in VirtualBox, and I also saw this warning when doing an installation on my bare hardware with a rather old mainboard that doesnāt have UEFI support at all. (In that non-virtualized case, installing and booting the installed system worked fine anyway, but maybe because I chose not to install the bootloader/used āubiquity -bā.)
The only way I got the installation to succeed in VirtualBox was to let the installer erase the entire disk and create all partitions automatically. After installation, I discovered it had created an extra EFI partition.
Could someone please clarify whether this message and the failing installation on non-UEFI systems is a bug, or if it is now somehow required to set up such an EFI System Partition even on non-UEFI-systems?
For me it would be a bit unfortunate if the latter one is the case and I would need to deal with EFI partitions without actually having the respective hardware - since that would require the hassle of repartitioning my disk and restoring all the data.
Iām not completely sure if this problem is related to the change to boot the installer with GRUB instead of syslinux, but I never saw this beforeā¦
Kind regards,
Jan
2 Likes
That bug does not appear to mention the warning message youāve screenshotted. You should probably file a separate bug detailing your exact issue.
The warning is possibly overbroad, but just because a system has booted under BIOS when booted from install media does not guarantee that it will boot from BIOS from the internal drive. Many older UEFI firmware versions specifically use CSM (BIOS) mode for booting external media which can lead to an unbootable install if we donāt include an ESP; this is the reason for the warning.
It is not ārequiredā, but it is certainly intentional that we install both BIOS and UEFI bootloaders under guided installation.
It is not.
1 Like
Hello Steve, thanks for your reply!
I just looked closer at that report and now I see the symptoms described there seem to be subtly different from mine indeed (the error message from GRUB failing has a very similar content but is not exactly the same as I get), so Iāll write a new report.
I found one mentioning of the warning message in Comment 41, that was why I thought this report might also cover the problems Iām observing.
Thanks for this explanation, I didnāt know that!
Ok, then sorry for hijacking this thread.
Anyway, I feel a bit relieved that I might not need to do repartitioning work when Iāll switch my main installation to 20.10 at some point in the future.
Just for the record - I test groovy-desktop-arm64.iso on Lenovo Yoga C630 WOS and it does not boot.
When I write iso by using usb-creator-gtk then laptop firmware does not detect flash drive as bootable device and just skip to GRUB2 from UFS.
When I write iso manually, by coping content of both partitions from iso to FAT32 partition of flash drive I getting following behavior:
- Flash drive led blink
- Black screen
- Noting happens, itās just sits here
Itās seems like GRUB2 from iso get started but then it freeze for some reason.
3 Likes
I think you are affected by
Your participation āaffects me tooā and with a comment in that bug report will help raising the heat and increase the chances to squash the bug.
2 Likes
@RussianNeuroMancer @nio-wiklund @leok
These changes have unfortunately not landed in time for the 20.10 beta, but will be included in the next daily builds following beta. Once the next daily is available, please re-test those systems that were failing to boot under UEFI - the new cd-boot-images-amd64 now provides the \EFI\BOOT tree on the iso9660 filesystem for compatibility.
Quoting from bug report, with thanks to @vorlon
3 Likes
Current image for arm64 not provide /efi/boot on the iso9660. So for arm64 images this issue remain unresolved.
2 Likes
This issue is fixed now, thanks to @xnox
Black screen issue remain, there is bugreport about it.
Hi,
has reported from different users in this thread of the Italian Ubuntu forum, installation or update to Ubuntu 20.10 fails on computers with old bios (or uefi set to ālegacy modeā) because of the missing EFI partition.
I tried myself and I could see that the creation of an EFI partition does the jobā¦
Well, I also saw that running an automatic installation of the system does create a gpt table, which is surelly an improvment compare to mbr(dos). Butā¦ also in this case an EFI partition will be createdā¦
I understand the effort to unify the installation experience, but such a big change should have been mentioned at least into Groovy Gorilla Release Notes.
Nowhere is written that you have to create an EFI partition even on a mbr partition table.
For everyone using old computers or uefi in legacy mode, this make the difference between running or not running Ubuntu.
Ciao
1 Like
I tested Ubuntu (though primarily flavors) in the groovy cycle (390 QA tests recorded), and yes problems did appear at times, they were resolved.
Most of the hardware I test on is legacy/BIOS, and whilst I donāt read Italian, and vaguely recall reference to a bug somewhat as you describe on launchpad (where bugs are tracked, not on support forums) I canāt find any.
I know you donāt need to create an EFI partition on MBR partition table, as in testing I never created that, outside of bugs reported (and subsequently fixed), I used only the standard installer options.
The more testers we have, especially with more varied equipment, the more issues will be detected & thus fixed before release. Of note, every issue I discovered (ignoring a minor i386 wonāt fix) was corrected during the development cycle.
If youāre talking about a reported bug, providing the bug ID would help me at least, better understand, I didnāt see any reference on that Italian forum to a bug report
3 Likes
Hi,
In groovy we made a few changes on how installer media are built and what they install in-target.
If users booted the installer fine and are attempting to install, the changes described at the top of this discussion all worked fine.
However, the changes of what bootloaders are installed in-target have also changed, and may trip things up.
Do you have a reliable reproducer? We are currently looking for a way to reproduce the problem the users are experiencing. Something like āinstall windows version BLAH in BIOS mode, then install Ubuntu 18.04, then try to reinstall Ubuntu 20.10 instead of 18.04 using the resize optionā or like replace option, or like some things are in EFI mode, etc.
We are really looking to steps on how to trigger and reproduce the issue at hand. If that Italian thread has something, it would be very useful to have the reproducer steps translated into english.
Sounds like this could be bug 1893964.
1 Like
Yes!
The only difference is I didnāt use a virtual machine but a standard installation on a pc with old BIOS.
@xnox and @guiverc
shall I open a new bug or is it fine if I add a comment to bug-1893964 ?
1 Like
@xnox is the person to really advise.
It will be okay to create your own bug, and if itās deemed a duplicate, it will be marked as such (this should never be taken as sign of a mistake; the duplicate adds additional information to the primary bug so is still extremely helpful!). New bugs (esp. when filed with ubuntu-bug ubiquity for example) will upload detail about your hardware will of course differ to the original report, thus new additional detail will be found, so I would expect that provide the most help, but clicking āaffects me tooā & comment still provides detail, but given a choice, Iād follow @xnoxās advice
1 Like
OK here we are: Bug #1902269 āUbuntu 20.10 on BIOS hardware - Installation with ...ā : Bugs : ubiquity package : Ubuntu
Just let me know if you need any additional info!
Sorry if Iāve been a bit slow but the computer Iāve used for the test is not mineā¦ I had also to change the hard diskā¦ not so handy 
I really hope there will be a solution as soon as possible. Iām looking after the Italian Ubuntu wiki, and put a warning near the 20.10 download links to let people know that computers with BIOS may have problems during the installationā¦ wellā¦ has been painful 
2 Likes