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
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.
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.
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…
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.
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.
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.
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.
Current image for arm64 not provide /efi/boot on the iso9660. So for arm64 images this issue remain unresolved.
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.
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
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.
The only difference is I didn’t use a virtual machine but a standard installation on a pc with old BIOS.
@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
OK here we are: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1902269
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
I have checked the arrangement yet it didnt encouraged me!