Bug#731709: grub-efi UEFI support based on debian-cd work complete (repos)
El 26/01/16 a las 10:18, Michal Suchanek escribió:
If you set bootloaders like
LB_BOOTLOADERS="syslinux grub-efi"
then you can just do
for bootloader in $LB_BOOTLOADERS ; do some $bootloader foo
Mostly what current path does but with commas instead.
IIRC multivalue options use mostly spaces for separator in l-b so far.
dba requested it like this. I agree on that criteria for doing so. You
are not obliged to use quotes when defining bootloaders on the command
line or scripts.
What are these multivalue options so that I take a look at them? Having
to deal with IFS it's not ideal but I think using commas it's the way to
go... although I'm not 100% convinced.
after you check that you have at most two bootloaders and if you have
more than one then only the latter one ends with -efi.
This is not a good approach. You are requesting the bootloaders to end in
"-efi". The current approach is to name them based on the Debian package
name. These packages do not need to end in "-efi".
It so happens that bootloaders that support efi are packaged as
packages with -efi suffix (well, except elilo). Maybe there is some
intent there?
However, grub-pc is now split in grub-pc scripts that are meant to
install the bootloader in the system which you probably don't want and
grub-pc-bin which just includes the binaries. The situation is even
more complicated with the 32bit and 64bit efi packages. Also expect
that at some point the maintainers figure out some new completely
awesome way to split the bootloader into packages and then the package
sets will be different in stable/testing/oldstable.
So naming the l-b option *exactly* like the package is not that good idea.
dba commited a change (
https://anonscm.debian.org/cgit/debian-live/live-build.git/commit/?id=f93fa286d5e7348150aab4874794f7d96dac0894
) for that behaviour. I think the reasoning of that was avoid file
naming collisions in the future because package names are not repeated.
My use case is the following one. The final user requests:
--bootloaders=grub-efi,syslinux
so I show him:
"Warning. You are using: syslinux as a non first bootloader. This might work
but it is not advised."
How do I know that I have to output this message?
for bootloader in $BOOTLOADERS ; do
# some bootloader foo
if echo $BIOS_BOOTLOADERS | grep "${bootloader}" >/dev/null; then
# a fixed list of bootloaders that load through legacy BIOS -
currently should be "syslinux grub-pc" although grub is not well
supported
case $MEDIA_TYPE in # or whatever the variable
iso*)
case "${BOOTLOADERS}" in
"${bootloader}"*);;
*) echo "Warning: it is recommended to specify
$bootloader first in bootloader list so it gets installed as first
el-torito boot entry."
;;
esac ;;
esac
fi
done
Here you are creating a new variable: $BIOS_BOOTLOADERS which will have
to be updated manually each time a new bios bootloader binary_ file is
added.
The grep part should be improved to avoid problems (e.g. syslinux is
inside syslinux-efi).
Because I compare the internal variable:
LB_FIRST_BOOTLOADER="grub-efi"
with the bootloader name "syslinux" and I see they are not the same one.
So, as you see I need to use:
"non first bootloader" term
Why that has to be a term? Just say it should come first in the list
of bootloaders if specified at all.
"It should come first". "It should not come first". Ok. I can do that
and ditch the "non first bootloader" or "first bootloader" from my messages.
and
LB_FIRST_BOOTLOADER variable.
what for?
For two reasons:
1) Being able to use current live-build code which used LB_BOOTLOADER in
the past.
Check what it's in current alioth git (Seach for LB_PRIMARY_BOOTLOADER
on there):
https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_hdd?id=1ccb41623046f2a8f823d62a5f417cdae724c22b
https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/scripts/build/binary_iso?id=1ccb41623046f2a8f823d62a5f417cdae724c22b
https://anonscm.debian.org/cgit/debian-live/live-build.git/tree/functions/defaults.sh?id=1ccb41623046f2a8f823d62a5f417cdae724c22b
2) Not having to use awk each time I need to compare a first / default
bootloader... when I can just use a variable with previous (once only)
calculated value.
So...
1) I don't mind renaming "non first bootloader" or LB_FIRST_BOOTLOADER to
another terminology which makes more technical sense.
2) I prefer this approach over yours (Michal) because it's the own
bootloader which decides if it is more suited for "first bootloader" or not.
How does it decide that? It can install equally well in 1st, 2nd or
10th el-torito record. The only reason we want BIOS record first is
Inside the binary_bootloader file by running a function that shows that
warning. The author of the binary_bootloader it's who decides where it's
advised to go.
The final place where it goes depends on the order here:
--bootloaders="syslinux,grub-efi"
I mean, the final user can decide the order but if it's not optimal he
gets a warning.
1) some tools for butchering bootable CDs expect it to be first.
2) it's the traditional place for it (since it was the only record for
a long time) and some ancient BIOSes might potentially break if it's
not first because somebody missed there *can* be multiple entries when
coding them.
So it only has to do with the fact that syslinux is our only well
supported BIOS loader that syslinux should go first. If grub-pc was
installed as BIOS loader it should go first instead. And then you
would have to duplicate that check in grub-pc.
I don't see a problem here. I can do that thanks to the magic of
functions that let me repeat code with only one line. I already did that
in the last version of the patch.
( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=731709#233 - In that
version I thought I had to enforce boot order because not doing so it
was going to produce non bootable isos. Now I'm convinced that using non
standard boot order do not produce non bootable isos thus a warning
instead of stopping live build is ok. )
Let's not repeat the current binary_iso design which has many references to
the different available binary_bootloaders available.
What's wrong with referencing variables we have so that we know
what's going on in l-b?
Thanks
Michal
Well, basically, my design rationale behind this is that with the
current way of doing things you need to update binary_iso file each time
a new bootloader is added.
With what I'm proposing you you wouldn't have to update it. And if a new
bootloader might ever need binary_iso to be modified then every
bootloader might benefit from that architecture enhancement.
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: