Bug#775322: Bootloader code issues and improvements
El 18/01/15 a las 07:27, jnqnfe escribió:
(forgot to cc the bug, here's a copy)
I did not find that problem in my tests. But that can be explained by
saying that my initial tests were done with live-build-4.0.
The problem also exists in 4.x. For my text amd64 sid build using grub2,
I have the following grub2 menu entries:
- Debian GNU/Linux - live
- Debian GNU/Linux - live (fail-safe mode)
- Debian GNU/Linux - live, kernel 3.16.0-4-amd64
- Debian GNU/Linux - live, kernel 3.16.0-4amd64 (fail-safe mode)
- <installer entries>
If you ignore the labels and look at the kernel, initrd and append
(kernel param) details behind them (by looking at the grub config file,
or using edit mode when grub is running), you'll see that the 1st entry
is identical to the 3rd and the 2nd is identical to the 4th. (In actual
fact all four will be identical building from the current 4.x/5.x
codebases due to a mistake in the code, which I have fixed in the set of
patches provided earlier).
The current code always outputs the first two "default" entries (if you
specify multiple kernel flavours then it uses the first specified here),
then it outputs a pair for each and every kernel flavour specified, even
though that creates duplicate entries for the first. This is not the
case in syslinux. I intend to rework grub2 to remove this redundancy,
matching syslinux.
Now I understand what you mean. Thank you.
As I was about to improve grub2 support on Live Build (changed my mind
because Debian's Grub2 package does not match the minimum for Super
Grub2 Disk) I'll explain a bit about what I had in mind.
Hopefully you can share some of these ideas and, who knows, implement
some of them.
1) SVG and bootloaders directory
1.1) If you check the current default Debian Live, at least in Debian
Wheezy, you will see that its boot background image for
syslinux/isolinux family is based on a: svg.in file which gets
converted into a svg. Finally the svg file is converted into something
that svg can understand.
I had no idea what you were talking about, then I went and took a brief
look at the live-build v3.x code and I see it. I haven't used 3.x, and I
haven't looked in any detail at the code you're referring to, but 4.x
changed this behaviour; it replaces a few text placeholders in the svg
it uses, but then just uses that svg, it does not convert it to a png.
That is, with a config that defaults to using the
/usr/share/live/build/bootloaders files, and thus the splash with the
black background and yellow construction workers helmet, which contains
those placeholders. If using a config from the live-images package,
these contain a local config copy of the bootloader files, with a
different, Debian themed svg, without the text placeholders, so the svg
is used as is.
This is from debian-old-4.0:
http://live.debian.net/gitweb/?p=live-build.git;a=blob;f=scripts/build/binary_syslinux;h=568b3f75729cf309d29524156b65cde28b1bb17e;hb=refs/heads/debian-old-4.0#l345
where you can see that svg gets converted into a png.
And this is from debian-next:
http://live.debian.net/gitweb/?p=live-build.git;a=blob;f=scripts/build/binary_syslinux;h=5c9ce04bb89652e9dbfe0349ecd2af65c982da08;hb=refs/heads/debian-next#l295
Syslinux or isolinux is not using SVG directly but a png.
Take a look here too:
http://live.debian.net/gitweb/?p=live-build.git;a=blob;f=share/bootloaders/syslinux/stdmenu.cfg;h=671b16f786ffcdf61e6629b88d763591cf8d2bfe;hb=refs/heads/debian-next#l1
I'm just saying to clone and reuse this code but to produce an image
that grub2 can understand and use in one of its themes.
For grub2, the "template" files in /usr/share/live/build/templates/grub2
are used, including a tga splash image which is identical to the default
syslinux one, except being a tga, the text placeholder thing can't be
done. So unless you really want that text, the splash is otherwise the
same, and I see no point in generating a tga/png from the svg.
Well, I want the image to be exactly the same, so yes, there's a point
to me.
On the issue of the text displayed in the svg, I actually really dislike
it. I was considering the possibility of alternate solutions for
providing that info in the bootloader. I haven't explored that much yet
though since I've got much more important things to work on.
Yes, I might agree on the default text not being the best one. But I
like the idea, as a derivative distro, to be able to edit the svg.in
file (even if you say that now it's svg without the .in) and add some
variables or text of my own.
1.2) Rework the theme to match the default syslinux one.
Rework the current grub2 theme (if there is one) to match the current
syslinux one. Why? I would like to see the same boot menu by default
either by using syslinux as a bootloaer or by using grub2.
I am not completely sure what you're talking about here, there are three
possibilities that come to mind (perhaps you mean more than one of these):
1) Menu label consistency between grub2 and syslinux, and menu
hierarchy. I would like to see consistency here and that's something I'm
working towards in these patches.
Yes, that's one of them.
2) Splash "theme" consistency. The splash, with the exception of the
text mentioned above, is already identical.
The splash might be identical because someone converted it to tga
manually. What I want is it to be converted it from a SVG file so that I
can reuse my syslinux SVG file as the grub2 SVG file.
3) Trying to manipulate grub2 into displaying things similarly to
syslinux, e.g. changing the size and location of the menu "box", etc. I
have no idea whether this can be done, though I have noticed that the
EFI grub2 bootloader menu displayed from an official Debian Wheezy
install disc looks completely different to how I expect grub menus to
look. Perhaps you can theme things much more than I realise (more than
just splash and a few text/background/highlight colours). If we can, and
a brief google image search suggests it may very well be possible, then
I am totally on board with doing that, and by all means go ahead and get
started on this if you like;
Yes, grub2 themes are powerful. I think there was a difference on theme
syntax between grub2 1.99 and 2.00 versions. Not sure what happens in 2.02.
You can take a look at the old (It's old because now we are Isolinux
based not grub2 based) Rescatux grub2 theme.
http://sourceforge.net/p/rescatux/git/ci/5f842d7c485950b846fa72b3643c7fe7865acdae/tree/rescatux-theme.txt
and its associated boot entry:
http://www.supergrubdisk.org/wp-content/uploads/2012/07/rescatux_boot_screen.png
I expect the derivative to change grub2's theme if they change default
syslinux theme. But if I'm using default Debian Live syslinux theme I
expect it to look the same as the default Debian Live grub2 theme.
Notice: I haven't checked it myself so that might be already the case.
I would suggest you start by taking the new
Jessie svg splash I supplied in bug #775527, make a png from that, use
live-build v5.x from debian next, plus my supplied set of patches, and
take a look at the grub config in an official Wheezy disc (beware that
in EFI it displays in a larger resolution than in BIOS mode though).
As I said above SVG is actually converted into PNG already.
2) Syslinux and loopback
If you check my bug about loopback cfg support you will see that I'm
using as much as I can the default grub2 code. Let's suppose you build
a Debian Live which has loopack cfg support. If you boot it normally
isolinux will show the default syslinux theme and it will be pretty.
If you boot it from Super Grub2 Disk thanks to its option to load
loopback cfg you will find another no-so-pretty menu.
If the loopback cfg support code in Live Build takes that into
consideration it will take the syslinux svg.in, convert it into svg,
then into a grub2-theme-suitable-image. Then you can have a great menu
even if booting from Super Grub2 Disk or other loopback cfg system.
See above; I'm all for themeing grub2 to look more like syslinux.
However, I still don't get it with the background, unless it's the text
in the default syslinux svg splash you're interested in having in grub2,
because otherwise they are already the same...
Well, that's because I do really want the text. But it's not about the
linux kernel version and such which I suspect is the text you do not like.
It's about the DerivativeName and its version.
Take a look at these Rescatux scripts which do nothing but replacing
Rescatux version on the SVG (or SVG.in) file so that I just have to
change version in one file and not having to edit background svg manually.
As I maintain the original SVG.in filename the Debian Build scripts
replace for me the kernel version and many other partitions but they are
found where I want them to be.
* Logo directory:
http://sourceforge.net/p/rescatux/git/ci/master/tree/logo/ (Please
ignore: generate_logo.sh file which does not matter for this subject).
* http://sourceforge.net/p/rescatux/git/ci/master/tree/make_common
(Search for "splash.svg.in")
*
http://sourceforge.net/p/rescatux/git/ci/master/tree/live-config/bootloaders/isolinux/splash.svg.in
The final result is:
http://youtu.be/dGA8e_A2PeA?t=4m9s
which I reuse as a desktop background:
http://i1-news.softpedia-static.com/images/news2/Rescatux-Is-a-Useful-Tool-to-Fix-Grub-and-Promote-Windows-Users-to-Admin-465868-2.jpg
I am hardcoding Rescatux text in my SVG but if there was a
DebianDerivativeName variable it could also be a variable.
3) Syslinux and grub hybrid iso
...
I'm not really following here. I am actually relatively new to Linux and
some of the areas I am dealing with in the live-build code. I need to
reread what you said here, perhaps do a little research and get back to
you after I've completed some other bits of work.
Maybe taking a look at Unetbootin, YUMI or SARDU as multi distro usb
tools might help you. Otherwise I'm in #rescatux channel at freenode if
you need further help.
I think what you are describing is what's currently done with
bootloaders directory, at least, for the isolinux family. You can check:
http://live.debian.net/manual/stable/html/live-manual.en.html#563
to see what I mean. It's not perfect (it does not have heritage) but
it usually works.
Yes, I'm aware of that, but the lack of "heritage" as you put it forces
derivatives (and even Debian's live-images package) to duplicate files
that are not being changed from the defaults, making the burden of
maintaining those copies greater (needing to watch out for and merge
changes across a greater number of files), for instance, so I want to
investigate improving things here. In fact I'm not totally thrilled by
the duplication of files across the syslinux family of bootloader
directories.
I suppose that the syslinux family duplication is just in case you want
to have a different image (cdrom image, usb image, rj45 image) depending
on the media you boot from.
If grub2 was the default and syslinux was removed (not to happen in the
next five years :) ) you could script it like ... If this file exists
read it else ignore it. Syslinux is more limited in that regard.
Actually I'm not so concerned as you for duplication because I just
write the four directory with a script. What I really would like to have
special is an special directory that once its use it overwrites (or its
used instead of the other ones).
I mean, if bootloaders/syslinuxforced/ is found use those files instead
of the bootloaders/{syslinux,extlinux,...} files. That would be a nice
adding for those of us that are not concerned about having different
boot configurations depending on the boot media.
I wanted myself to improve it so that grub2 does the same thing as I
have explained before. As far as I know bootloaders/grub2/ folder is
not checked by binary_grub2.
Actually that functionality is already there for grub/grub2, it's just a
different directory, because the grub/grub2 files are for whatever
reason considered "template" files rather than "bootloader" files, so
it's config/templates/grub2 not config/bootloaders/grub2, unlike with
syslinux.
Note (in live-build v4.x/5.x at least) the 'Check_templates grub2'
function execution in the binary_grub2 script, and the Check_templates
function in functions/templates.sh, this looks for a local config
template directory and sets the location in the TEMPLATE variable, which
is used later in binary_grub2.
I don't really see the point in grub/grub2 stuff being treated
differently in this way though...
I did not know about this templates directory. Thank you very much. I
guess the difference is that the grub2 package has some template files
by default while the syslinux has not these templates by default so the
bootloaders directory needed to be used. But, well, I'm just wild guessing.
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: