Last year 20.10 failed to install with “No EFI partition”. I got round that by quitting and going back to my previous OS then doing “do release upgrade”, see Ubuntu Budgie 20.10 Released! - #3 by ChrisOfBristol
Now 21.04 Beta has failed and has messed things up so Grub fails, so I can’t go back to the 20.10 that is currently installed. I can’t even re-install that from DVD because of the problem outlined above.
I am now completely &8(^%$#(! I believe this is a bug in Ubiquity which has been around for a while without being fixed. This makes me cross because problems with installation are really bad.
I can’t download an earlier version of UB and write it to a DVD to install from that, as I’m running off the disk drive.
The only way I can see out of this, is to install from a Fedora disk I have, and hope it doesn’t use Ubiquity. Am I right or is there another way?
That bug in Ubiquity is very annoying, and is present for years ( still buggy in 20.04 too ).
If you target an UEFI bios in legacy mode, or an old classic bios, it’s safer to manually prepare your discs partitioning then at installation time, chose « something else » to explicitly tell which partition to use and for what.
Actually Ubiquity in automatic mode works nicely ONLY in 100% UEFI context.
I don’t understand “If you target an UEFI bios in legacy mode , or an old classic bios”. I have already partitioned the disk into ‘/’, ‘swap’ and ‘/home’. My data is already in home so I don’t want to mess that up.
I don’t use it in ‘automatic’, see above.
I’ve installed many OSs on this computer without these problems. I’m not sure what changed in UB 20.10 that caused these problems.
I can’t cope with an installer that doesn’t work - if it doesn’t install I can’t even get into the system to fix it. I’ve installed Fedora in 20 minutes, it looks to be a different installer.
Why so ? You should be able to chose « how » to boot from your bios settings.
Depending on bios type, you’ll have to act differently with Ubuntu installer ( ubiquity ).
A modern UEFI can be set to run in « legacy » mode. Older bios are not UEFI.
100% UEFI implies GPT partition table + a different partitioning compared to non-UEFI ( legacy mode or older bios ).
If Ubiquity sees an UEFI compliant bios it will imediatly do the UEFI compliant partitioning - even if you already have other OS installed in non-UEFI partitioning… Even if the disc has an mbr/msdos partition table… and here starts the glorious mess.
To avoid that, you must chose to do « something else » at installation time, in Ubiquity ( not « install beside existing OS » I don’t know how it’s worded in English ) and there do your partitioning the way you like or targeting previously prepared partitions.
tl;dr
First things to check before installation are
⋅ the settings of your bios ( is it UEFI ? is it UEfi-in-legacy-mode ? is SecureBoot disabled ? )
⋅ the partition table of the target disc ( mbr/msdos or GPT ? ) because GPT also implies a specific partitioning even in non-UEFI mode ( who said simple ? )
Then…
For installing ×buntu in non-UEFI mode, you have to chose « something else » where you’ll be able to manually set your partitioning. Any other option may fail.
Whereas in 100% UEFI mode, Ubiquity will do the task flawlessly ( or if any previously installed OS was already in 100% UEFI mode ).
I do, but it doesn’t work, either from the socket on the rear, the front panel or an adaptor.
That’s what I do.
I can’t see anything relevant in setup.
That’s what I do.
That’s what I do.
A bit, but not well enough for anything technical. I’ve had a look using the Google Translate extension to Firefox and it seems to involve more complication. I really don’t want to mess with that as errors at that stage could damage my data.
I’m going to stick with Fedora as it uses a more sophisticated installer. It works straight away without complaining about any problems with my computer.
I do like the Budgie desktop, so will probably switch to that if it becomes available on Fedora or switch back to Ubuntu Budgie if Ubuntu ever fixes its installer. I won’t hold my breath
The amount of workarounds in Ubiquity that has been used to workaround manufacturers poor implementations of UEFI is substantial.
I wouldnt classify them as bugs in ubiquity. It’s the users setup causing the issue.
I know it causes frustration when it appears an install goes wrong but put focus where is needs to be … the manufacturer.
Whilst the new installer is most welcome … it going to take some considerable amount of time to import all the current workarounds into the installer… never mind creating new workarounds.
Similarly, it’s great that Fedora installs on the OP setup … but remember the same installer will be falling flat on its face on other users setups where there isnt a workaround.
No one installer resolves every setup. Believe it or not, in my day job, even Windows installs crash and burn. We spend substantial amount of time unpicking the mess for various machines, usually by swapping out hardware, slipstreaming drivers etc.
I’m not interested in apportioning blame, just using something that works - which is why I stopped using Windows years ago.
I should have started using something else last time this happened because it is worse this time round. A stitch in time and all that. If I were to carry on with it something worse might happen.
I maintain 2 HP Probook laptops (G6), a brand new Lenovo laptop and my server (Fujitsu C246 Intel chipset). The USB stick that works on the Probook laptops, does not work on the other 2 systems.
Also, it matters whether I use Unetbootin or other tools to create the USB stick.
The Fujitsu system is extremely picky. Only a very old USB stick seems to work, or one of the 3 microSD card readers I have, and only with a specific boot disk creation tool.
I would prefer to only work via a stick prepared with Ventoy, but on every computer/laptop I tried, Ubuntu Budgie 20.10 did not finish installation (some EFI error at the end). While it did work with another USB stick prepped via a different tool.
What I am trying to say: there are multiple unknown factors that could cause your system to not boot from USB. Whatever it is, your main issue should be to figure out which USB stick combo* works.
Because a system that cannot be booted from USB, can never be recovered. This is an essential basic feature that should work, just like connecting a keyboard and pressing a F button to get into the BIOS should always work.
The issue with failing install would be second to that in my opinion.
*created with which tool and on which USB port (with USB legacy support turned on/off and high speed support turned on/off in BIOS).
I don’t doubt The amount of workarounds in Ubiquity that has been used to workaround manufacturers poor implementations of UEFI is substantial.
And indeed in 100% UEFI mode, the Ubiquity installer is smart.
In UEFI-but-legacy-mode or on old « classic » bios, it easily fails ( unless doing « something else » and manual partitioning ).
On a mbr/msdos partition table disc, it will build partitions as if it was a GPT disc. Even if other OS are already installed in old fashioned mbr/msdos way. Hence losing GRUB.
So it’s not only a problem of user’s setup : just a missing warning somewhere if you target classic bios or UEFI-in-legacy-mode, please select « something else ».
That would not solve all situations / users’ cases but point towards a safer method.
Oh, i had this issue, too. Went 2 weeks straight to find out what problem it was that i couldn’t boot from my sd card (even have a sd to usb adapter too).
My conclusion is, keep windows as a “main formatter”. What i used is Win+R and “diskmgmt.msc” and there i deleted or formatted my sd card. When this worked, i used Rufus & (mainly) Universal USB Installer as my main installer. Others didn’t work out well.
Eventually one time it will boot. Now i even got 1 SD Card formatted with 2 Partitions, which is pretty cool. I got 1 big partition for my stuff (first things to do list after installing ubuntu, wallpapers, .deb-files, … ) and the other partition is the boot partition for Budgie LTS.
Oh btw, if you encounter some errors in windows while deleting/formatting your usb stick, don’t search too much on the internet to fix the problem. Try using a formatting software (windows or linux, doesn’t matter) instead - delete/format - and afterwards try again doing it on windows.
Good luck!
To those that are affected the workaround here is to install without ubiquity installing grub, then to install grub manually
This is described here in comment 8 and 9
This problem makes this OS unusable for me (and possibly other ordinary users) as I won’t take the risk of using commands (as suggested in the Launchpad bug report above) that I don’t understand perfectly. I have often found a typo or other error in such commands which cause the commands to fail and the consequences at this stage could be dire. See post #9 in the Launchpad bug report for an example of that.
This is very wise and careful : I won’t take the risk of using commands (…) that I don’t understand perfectly.
What’s proposed there is to manually install grub, from the live-session.
In order to do that you have to tell the « live-session » to target the / root partition of the system installed on hard disk in the computer ( and not its current actual root which is the one from installation media )
Hence the chroot command ( change root ) and the others mount command that tie together the needed folders on hard disk.
Once « chrooted » what you install from the « live-session » actually ends on the hard-disk of the installed system.
[ hope my english is clear enough - and my explanation accurate - welcome anyone for correcting it ]
Anyway you are right : all that should not be needed. Let’s hope it will get fixed in due time.
Well that’s good news. UB is a great distribution with excellent support, so I may come back to it in the future. I’ve discovered I like Fedora, so will be sticking with it now.
