Done. thank you very much
Good day.
Could you please make sure that the new installer allows and provides the use of explicitly selected EFI partition (meaning non-default one which could be occupied by some foreign OS)? Ubiquity now ignores user settings on that: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1822464
Also, it would be a nice if you add support for encrypting user’s home directory with fscrypt as a modern and more secure replacement for long ago deprecated eCryptfs. For those who still prefer ext4 and f2fs. If working on it, this should be taken into consideration as well: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1889416
As long as this feature of Ubiquity remains https://wiki.ubuntu.com/UbiquityPreserveHome, so I can still do this procedure to rescue borked installs, I’m fine with the change.
1 Like
Where is the problem when other operating systems are using the same EFI-System-Partition?
I think many people don’t want any operating system to silently overwrite some other OS’ boot files. Using separate $ESPs is an easy solution to that, but it’s not possible (using Ubiquity installer means), so that’s the problem you asked about. Also, it is “allowed” by Ubiquity atm, at least GUI option is present. What I’m taking about is that that option actually doesn’t work.
There were cases when Windows overwrote Ubuntu’s loader in BOOT/BOOTX64.EFI. Also, out of all major Linux distros, Ubuntu is the only one which has such bug in the installer. All others have no problem with following user’s preferences during the install procedure.
I am not aware of any operating system, which is overwriting the primary boot files of Ubuntu. And I am not aware, that Ubiquity is overwriting the primary boot files of other operating systems.
Are you sure, that all UEFI implementations are handling several ESPs correctly? If a firmware detects an ESP on the first disk (excluded removable disks), why should it search on all the other disks for existing ESPs?
And what is with the boot entries in the NVRAM? Some firmware implementations are updating boot entries, some do not.
\EFI\BOOT\bootx64.efi is a default file name and used for removable boot devices (UEFI spec 2.8B chapter 3.5.1.1). You cannot expect, that \EFI\BOOT\bootx64.efi is not overwritten.
Ubuntu is using \EFI\ubuntu\shimx64.efi and \EFI\ubuntu\grubx64.efi and other operating systems are not overwriting these files (if they are not official Ubuntu flavours).
I don’t see this as a bug. Using an existing ESP is normal, less confusing and I would say also the expected behaviour.
1 Like
Another thing to consider is that Google is stuck on their material design and Flutter is fixed to it.
No, it’s not. You can easily do any layout/design you want with Flutter.
But that’s completely another concern. My post was focused on one exact problem: “Ubiquity has means to specify user-preferred EFI partition, but that doesn’t work due to some bug(s). Pls make sure the next generation installer completes such task perfectly. TIA”
No more, no less.
Again, I am not suggesting to drop the default way of how it works and what you prefer. You don’t see it as a big. Okay, you’re not affected then, see you later, enjoy your life 
1 Like
It sounds great, but please take the time to fix the glaring bugs with the subiquity installer as well. In particular I mean that Subiquity currently (20.04 LTS) can’t re-use existing encrypted/LVM partitions, even ones that it itself previously created! This means either wiping the whole system including /home partition (hope your backups are good!) and starting from scratch if you ever need to re-install, or doing a complicated workaround.
Refer this bug: https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1904270
On regular Ubuntu, using a US International keyboard config I can press ' and press c to produce a ç or ~ and press a and then get a ã, but at install time on the old installer this doesn’t work. It’s really minor, and what matters is day to day usage but whenever I am installing Ubuntu I need to remind myself that if the keyboard doesn’t work properly it’s fine since it doesn’t represent the behavior post install - which works fine.
Anyway, it will be good having a new installer.
That sounds as bug #1875062. While it may be a minor issue for some users, that’s not true for everyone. A user who selects their keyboard layout, and does not notice that when entering their password the English (US) layout is effective, may then not be able to log in after the installation has completed.
1 Like
I had not considered the unable to login situation, yes that is a problem.
Hello all and @Wimpress,
One of the challenge the Ubuntu team should add to their TODO list is taking into account accessibility. It should be taken into account when choosing the technology used and testing the new installer.
Many blind or visual-impaired people are using Ubuntu so they need the installer to be accessible to be able to install it without a sighted assistance (who is honestly often difficult to find because all sighted people don’t have tech skills).
Thanks in advance.
1 Like
Hello! I’ve asked this question on askubuntu, however I was redirected to pose this question here, as it is a more appropriate place for it:
Following the announcement of the new Ubuntu installer application based on Google’s Flutter, a few of our sight-challenged members (in our Ubuntu CZ/SK community) has raised an important question. Will the new install wizard support (or be supported by) Orca? Right now, Ubuntu is among the most disability-friendly Linux distribution, lagging just slightly behind the likes of macOS. Our vision-impaired friends are proud to be able to install and maintain their Linux boxes without the need of sighted-person’s assistance and they would really like it to stay so.
Unfortunatelly, according to them, Orca doesn’t really work with anything but GTK+ applications. Is there any contiguency plan for sightless or otherwise disabled users? Possibly an alternative image with Ubiquiti or added support for screen reading with Flutter?
4 Likes
i believe this is:
1 Like
We contributed a11y support to the Flutter Linux shell. This shell is actually GTK and I’m pretty sure that it would still utilize Orca. @robert.ancell did the work and could confirm.
Full a11y support is a requirement for the new installer, we would appreciate testing when the time comes. Thanks!
6 Likes
The Flutter linux shell recently added support for accessibility. This is implemeted using ATK, so should expose much the same as any other GTK app. I tested it with Orca and accerciser and had elements being read out and could see and interact with the Flutter elements. This should work automatically when using the Flutter from the beta channel.
I’m however not an expert in a11y, and look forward to some real-world feedback on this feature. The installer will be a great test case to make sure that a11y support is rock-solid. Please file any issues you find and we’ll do our best to fix them quickly!
4 Likes
Thank you very much for the quick response. I will relay the information to our sightless friend in the czechoslovakian community and come back to you with any issues that might surface.
2 Likes
I’m a bit scared 
It reminds me a similar attempt (of which I appreciate the intent ) that is having a bed side effect on Ubuntu 20.10 and at the moment also 21.04:
The installer expects to find an EFI partition on a computer with BIOS…
This issue doesn’t affect system-upgrade or installation erasing the entire hard drive (in this case EFI partition is automatically created).
But in any other case installation fails, unless you are aware of this problem… and most people don’t really expect this.
And even expecting this, workarounds can be difficult.
I’m afraid that if all the efforts are going on a new installer, there will not be a fix for the upcoming 21.04. And if things go long, even 21.10 could be affected by this bad bug.
If I’m wrong, I’ll be the happiest person on the planet
The prototype screenshots seem broken. Where or who I should report to?