Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 18/01/16 a las 07:31, Michal Suchanek escribió:
Hello,
thanks for working on this.
On 18 January 2016 at 05:24, adrian15 <adrian15sgd@gmail.com> wrote:
In my last message I forgot to CC many people who are involved in this bug
so I'm going to refer to my former message, CC some people and finally point
you to my repo/branches where you might find interesting commits.
1) My original message with attached patches (which you can download to your
email program and reply from there) can be found at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#153
2) Repo / Branches:
* efi_support_based_on_debian_cd (
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd )
: Original dirty branch where I worked in both syslinux-efi and grub-efi
bootloaders at the same time
* efi_support_based_on_debian_cd_rebased (
https://github.com/adrian15/live-build/tree/efi_support_based_on_debian_cd_rebased
) : The same branch rebased to have minimal useful commits. syslinux-efi was
removed from it because it did not boot.
I have checked what EFI platforms I have and it seems neither would be
bootable with this.
1) a Windows tablet that needs signed bootloader - signed grub is
available as non-free package (because it cannot be modified to not
break the signature) and presumably allows booting on such systems
without going through the unlocking stuff which may break your windows
installation.
Yeah, that's the Microsoft Secure Boot. debian-cd people are working on
bringing it into official Debian CDs. There is not a fixed date for that
but everything points that it will be finished within 2016. Once they
manage to do so I'll see how easy it is to port into this work.
You can always try virtual systems. This is how I currently test this:
kdesudo "kvm -bios /usr/share/ovmf/OVMF.fd -cdrom rescatux-0.40b3.iso
-boot d -m 512"
.
2) a mac mini which probably needs a GPT and the bootloader stored on
a HFS+ volume or something. Also the bootloader needs to be 'blessed'.
Command for that exists in grub and crashes. Never got this working on
an USB stick.
Well, I have not mentioned that this implementation (based on debian-cd
team work) also would support intel based mac systems because it has an
additional HFS+ volume.
I also have a mac book pro myself and the 'hybrid' version of Super
Grub2 Disk 2.02s3 works for me (when using ALT key at boot). I don't
remember having blessed it so... I'm unsure about the need (or not) to
bless it.
So, the 'hybrid' Super Grub2 Disk 2.02s3 also has an additional HFS+
partition (as our current implementation here in these patches) put in
place for mac book compatibility so I guess that this build will also
boot in my system but I still need to test it.
As to the primary and secondary bootloader - how is the efi bootloader
secondary? It boots the same as the legacy bootloader. You probably
want a concept of compatible bootloaders - that is pairs of
bootloaders that can be installed alongside on the same medium.
* What is it a secondary bootloader?
It's what happens when you request mkisofs that your bootloader to be
boot in second place or as a second partition. I don't know how it
actually works.
So in grub-efi we just add to the xorriso options:
-eltorito-alt-boot \
-e boot/grub/efi.img \
-no-emul-boot \
-isohybrid-gpt-basdat \
-isohybrid-apm-hfsplus
And in syslinux-efi (currently) we add:
-eltorito-alt-boot \
--efi-boot boot/efi.img \
-append_partition 2 0x01 \
binary/boot/efi.img
.
So, I guess the -eltorito-alt-boot does the magic but I'm not sure.
Maybe someone else can explain it better than me.
* About current compatible bootloaders.
The technology is there. I mean. This is what it's currently available:
binary_grub-efi : Secondary bootloader
binary_grub-legacy : Primary bootloader
binary_grub-pc : Primary bootloader
binary_syslinux : Primary bootloader
binary_syslinux-efi : Secondary bootloader
so that means, in theory you can request one of these 9 combinations:
grub-legacy
grub-pc
syslinux
grub-legacy,grub-efi
grub-pc,grub-efi
syslinux,grub-efi
grub-legacy,syslinux-efi
grub-pc,syslinux-efi
syslinux,syslinux-efi
Why can't you request:
grub-efi
or
grub-efi,syslinux-efi
?
Because nobody has coded grub-efi installed as a primary bootloader yet.
But the 'framework' is there.
You either need to improve binary_grub-efi or create another script file
that does its job when ' Is_Primary_Bootloader "grub-efi" ' is true.
Unless
the user requests two bootloaders that are incompatible the medium can
be created.
Ignoring bootloaders is not a good idea. If the user requested
something that is not possible the build should report an error and
stop.
Yeah, that it's hard to implement from the perspective of a single
bootloader script. So I decided not to implement it.
You could add an additional script or function named:
check_compatible_bootable_pairs (as you propose) but then you need to
maintain that fictional database each time a new bootloader gets in.
That's why I decide to avoid it using it.
What it's straight-forward to implement is one of the only-secondary
bootloaders finding themselves as a primary bootloader and outputting a
warning message. But, I'm not sure what to put there as a warning. Any
suggestion?
Then, if the only-secondary bootloader script also implemented
boot-as-primary functionality you would have to remove the warning.
Finally it seems that some of the patches reference grub-efi before
the patch that adds support for it. Support for grub-efi should
probably be added before it's referenced in other code (eg set as
default).
I have taken that into account with patch numeration. If you think I
have missed something specifically please point it out.
Thanks
Thanks for your feedback.
Michal
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
Reply to: