Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
On 26 August 2016 at 13:34, Raphael Hertzog <hertzog@debian.org> wrote:
> On Fri, 26 Aug 2016, adrian15 wrote:
>> > Well, it sucks compared to the default visual appearance of
>> > isolinux/syslinux in live-build.
>> I know, but the purpose of my patch is to add UEFI support. Not to improve
>> visual appearance of grub2 so that it matches the isolinux/syslinux one.
>
> Well, my initial patch added EFI support on top of syslinux-efi and it
> thus had a nice visual appearance by default. So for me it's a
> regression...
>
> But I assume it's not a regression in terms of computers supported because
> I believe that syslinux-efi works for less cases than grub-efi and hence
> why I did not commit my own patch in the first place. Also I expect that
> secure boot will be easier to add on top of grub than on top of syslinux.
It works for Ubuntu so you can just pull the packages from there either through
apt pinning or by building a personal repo with them.
It seems some parts of the stuff are landing in experimental/sid but it would
be nice to have support for this in debian-live when it's complete.
I am probably not going to look into this any time soon, though.
>
> So I agree to apply your patch but I hope that you will stick around to
> help improve the visual appearance.
This bug is totally not about look of grub menus in debian-live.
If you are concerned about that file a separate bug about it.
>
>> These: /install/vmlinuz and /install/initrd.gz strings seem to be hardcoded.
>> That explains why I did not see them in binary_syslinux .
>> What does happen if you request both x86 and amd64 in your Debian Live? The
>> first kernel gets into the /install/vmlinuz and the second kernel gets
>> discarded?
>
> I don't know, I never tried to build images for multiple architectures.
> It's not a need for me.
It depends on the grub live scripts/templates, obviously.
Presumably fixing the installer support is needed to get full UEFI live support
but just filing it as an additional bug after this one is resolved may
be also fine.
It will be easier to fix once live media with *some* UEFI support are available.
Also I am fine with debootstrapping my system so that's not complete
installation blocker.
Unfortunately, most systems that need UEFI support also need secure boot
so solving that is probably most urgent UEFI problem.
The few I have access to right now do require it.
Thanks
Michal
Reply to: