El 17/01/15 a las 02:21, jnqnfe escribió:
On 15/01/2015 14:52, adrian15 wrote:
I just write down here that I will have to review your mentioned: #1,
#2, #3, #4, #5, #6, #7, #8 and #9 in my (#757883) (support for
loopback.cfg file) so that it matches your improvements and fixes.
No problem, I will upload the first batch of work soon, just running a
test and need to find out why I'm getting an error trying to load
memtest86 first. I will also take your looback support into
consideration and try to help review it and mold it into a state ready
to merge.
Thank you very much!
Do you mean the normal entry and the single entry per one kernel? Or
do you actually mean repeated kernels?
Syslinux generates only a single pair (normal + failsafe) when there is
only one kernel, and if multiple kernels, one such pair each. With
grub/grub2, it's outputting this pair of entries as a "standard/default"
pair, then also one per kernel, so for one of the kernels you're getting
double entries, i.e. if you've only got only one kernel, you get two
"normal" entries and two "failsafe" entries that are identical except in
their labels, which is unecessary. I intend to bring grub2 inline with
syslinux.
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.
I had also thought on this problem. I think there should a way of just
reusing the current syslinux SVG file so that it generates a suitable
image that can be used by grub2 as a background image.
I disagree, why add such complexity to live-build when you can just
provide a ready made image file as we do now. Besides, this problem
wasn't about creation of the image, it was about grub2 not displaying
it. I have created a small set of commits which improve the grub2 config
file, solving several graphics configuration issues, including a getting
the splash background displayed.
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'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.
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.
You will understand why a bit later.
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.
3) Syslinux and grub hybrid iso
My grub2 improvements suggestions are given by me wanting Super Grub2
Disk to be included by default on Debian Live builds. The thing is that
I do not want it to be emulated as a RAM image but I want it to be native.
That would also add the benefit of supporting EFI by default very easily.
So, first of all I need a grub2 based Debian Live which its grub2
package matches minimum requirements for Super Grub2 Disk (not in Jessie
currently). Then I just need to make the Super Grub2 Disk scripts (they
are just cfg files) get into that disk.
So what does happen when you have a grub2 Debian Live iso? How do the
multi distro usb tools handle them? Well, most of these tools cannot
handle them. However these tools are very good at handling isolinux
based isos.
So... a nice new option for Debian Live which I think I would only use
myself for Rescatux would be the following one:
Build a grub2 based Debian Live while at the same time you add to it the
files that isolinux build would have added. Just to be clear in the end
the ISO would be booted by grub2 but not by isolinux.
This new kind of syslinux and grub hybrid iso will have the advantage of
having a native grub2 (thus a native Super Grub2 Disk would be easy) and
at the same time the Multi USB tools will detect it as an isolinux iso
so that you can put them into a usb more easily and with many other
distros if needed.
Once again I would like to see that boot menu theme in both the default
grub2 menu and in the syslinux menu added by the multi usb tool. This
syslinux menu added by the multi usb tool I'm not quite sure that it
would reuse the ISO syslinux theme but if the ISO syslinux theme is not
there the tool won't be able to reuse it at all.
Also to be considered, particularly in respect to #18 and #19 are bug
#757697 (support arch autodetection) and the best way to allow
derivatives (e.g. Kali) to replace menu components such as labels and
splash.
Yes, I also think that somehow a DerivativeName setting is missing so
that we can easily replace Debian to e.g. Kali from a config file
without too much effort.
Kali is doing more than just using a different title; some of their
changes, e.g. adding an install with speech synthesizer option for
accessibility purposes, are covered in the work I am doing here, but
they also make other changes like adding new "usb persistence" menu
entries. I think, rather than adding to live-build to provide the
capability of outputting such extra menus for derivatives needing it, I
want to explore how best we can provide a means for such distributions
to provide alternate config templates, in which placeholders are filled
in by live-build. I am thinking along the lines of live-build providing
a default set of files, then derivatives like Kali providing a modified
copy of only the files they change (splash background being the most
obvious); so live-build takes a copy of the default set, copies over
that the derivative specific set (provided in the user's config
perhaps), then replaces the placeholders in this set with any details
that need writing to them.
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.
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.
What I just wanted to make clear is that having a DerivativeName setting
which by default would be set to "Debian" is a must so that, in the most
simple cases you can get a renamed Debian Live build by just defining a
variable or a setting.
adrian15
--
Support free software. Donate to Super Grub Disk. Apoya el software
libre. Dona a Super Grub Disk. http://www.supergrubdisk.org/donate/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
