Groovy to use GRUB2 for booting installer media in any modes on all architectures

Foundations
,
#27

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
#28

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. :slight_smile:

#29

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:

  1. Flash drive led blink
  2. Black screen
  3. 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
#30

@RussianNeuroMancer,

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
#31

@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
#32

Current image for arm64 not provide /efi/boot on the iso9660. So for arm64 images this issue remain unresolved.

2 Likes
#33

This issue is fixed now, thanks to @xnox
Black screen issue remain, there is bugreport about it.

#34

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
#35

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
#36

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.

#37

Sounds like this could be bug 1893964.

1 Like
#38

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
#39

@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
#40

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 :stuck_out_tongue:

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 :sleepy:

2 Likes
#41

I have checked the arrangement yet it didnt encouraged me!

#43

Sorry to bother again,

Unless a last minute bugfix (Bug on Launchpad), I think that the trouble with the installer that doesn’t recognize old BIOS system (or Legacy mode in modern Uefi) should be mentioned in the Hirsute Hippo Draft Release Notes

I’m writing here because that thread doesn’t accept replies. If someone could write in the draft releases note, it would be great.

Anyway, this bug is really serious.
The installer acts like if it were performing a standard installation on computers with Uefi, expecting to find an existing EFI (ESR) partition or, in case of automatic installation modality, trying to create an EFI partition.

In many cases installation fails especially with disks using MBR(msdos) partition table.

Just think about users that manually select a partition for installation. Installer doesn’t find EFI partition => installation fails.
Or users that select the automatic installation modality “Install next to other system…” and there isn’t any available primary partition for EFI => installation fails.

Those situations are quite common, just think about old computers with an existing Windows installation on a disk with MBR, where 3 primary partition are already taken.
That’s a bad situation and also workarounds may not be user friendly.

Thanks!

#44

That is a bug, which is understood and recognized, but unrelated to the topic of this discourse post.

#45

I can explain.

This is actually my bug report: 1902269
I’ve been asked in this discussion to file it and here it looked like it could be related to the topic.
I didn’t post that link because the bug is marked as duplicated of this other 1901137… “grub-install fails due to no space left on ESP”.
But ‘no space left on ESP’ is not the problem I’m talking about. What I’m talking about is that there should NOT be any ESP at all on a old bios system.
If there is an ESP partition, then you make Ubuntu incompatible in many use cases with non-uefi systems.

That’s why I have posted that link to a still open bug, which basically describes the same thing that I and other users have experienced.
(I haven’t see anyone having no problems in those use cases).

Is that off topic? Maybe.
I’m sorry and apologize for that.

I didn’t want to post here. I tried to find a way to rise the problem so that some of the staff could at least mention this (big) problem on the 21.04 release notes.

If there had been a way to do it directly I would have done it, giving all the possible information. I’ve spent hours and hours testing all the use cases and writing down a wiki page (on ubuntu-it wiki) with every combination to make life easier especially to newcomers. So they can easily see if their case is one of the possible case that leads to an unbootable computer.

And thanks godness this is not happened with an LTS version. It could have been a carnage…

#46

Yes.

If there is a FAT-formatted partition or not is totally irrelevant.

That is not true.

Nevertheless, it makes sense to mention it as an “Known Issue” in the release notes, that the installer Ubiquity always expects an ESP.

#47

@apt-ghetto
Yes, what I wrote is inaccurate/wrong. Perhaps because of my frustration and poor English combined :wink:
Sorry.

What I intended was:

  • ESP partition shoudn’t be required at all with old bios system
  • if the installer expects an ESP partition, Ubuntu will not be fully compatible with non-uefi systems.
    (Only installing erasing the whole disk always succeeds)

P.S. I stop here with off-topic