Reviewing the bootloader menu creation code, I have drawn up the
following list of fixes and improvements needed. Some of these I have
already reported and supplied patches for separately, but I'm listing
them here again to provide a comprehensive set of issues.

Where applicable, I'll specify the bug number of the separate bug report
either specifically for the issue, or where a patch has been previously
supplied already as part of addressing something else. I intend to wrap
this bug report up with one or more sets of commits to address them all.

Broken boot capability issues:
-----------------------------------
#1) grub2 broken, with missing file error on boot due to files being
placed in the wrong directory (#775316).

Kernel parameter issues:
-----------------------------------
#2) [install entries] user supplied kernel params added in wrong
position in grub/grub2 (#775143).
#3) [install entries] 'quiet' (d-i?) param excluded from rescue entries
instead of expert entries in grub2 (#775143).
#4) [install entries] the '--' delimiter prior to the (d-i?) quiet
kernel parameter is not output for grub/grub2 (#775143).
#5) [install entries] the '--' delimiter needs to be replaced now with
'---' (#775128).
#6) [live entries] user supplied kernel params added in wrong position
in grub/grub2 (less important than for installer entries) (#775143).
#7) [live entries] normal user supplied params being added to fail-safe
entry instead of fail-safe user params in grub/grub2.
#8) [live entries] unnecessary replacement of fail-safe-installer user
params placeholder in syslinux
#9) depreciated video/graphics kernel parameters are being used.

Menu entry set issues:
-----------------------------------
#10) [install entries] speech synthesis option missing, affecting
accessibility
#11) [install entries] lots of install options not provided by syslinux
menus
#12) [live entries] too many entries added in grub/grub2 (redundant
entries with kernel version specified)
#13) memtest entry included in syslinux menus even if no memtest included
#14) install entries included in syslinux menus even if no installer
included

Other issues:
-----------------------------------
#15) [live entries] undocumented user failsafe params option
#16) grub2 splash not being displayed
#17) grub splash displayed, but horribly (can this be fixed?)
#18) grub/grub2 do not rename kernel files unlike syslinux. syslinux
does this for a technical reason, but it might be desirable to do across
the board anyway. This needs further consideration.
#19) consider switching grub/grub2 code to work more like syslinux, with
pre-constructed pieces of the menus in files, from which the full menu
can be constructed by including chunks from those files, and replacing
placeholders.

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.

As of this moment I have written patches for 11 of these issues, some of
which have already been posted separately. More to follow soon.

Additional issue:
#20) grub2 looks in wrong location (binary/live instead of binary/boot)
when LB_INITRAMFS is not live-boot or casper.

I have built patches for 14/20 issues now, will upload soon.

El 14/01/15 a las 04:54, jnqnfe escribió:
Thank you for your recent hard work.
loopback.cfg file) so that it matches your improvements and fixes.

Unless somehow your #18 is fixed so that the kernel is always renamed.
That would probably mean that I could just do as the grml implementation
[1] which would be as simple as always generating grub2 file and
symlinking /boot/grub/loopback.cfg to /boot/grub/grub.cfg .
Do you mean the normal entry and the single entry per one kernel? Or do
you actually mean repeated kernels?
What I had found out myself is that there were installer entries in
grub2 but not in syslinux but that was when I checked it in Wheezy's
Debian Live so that might explain it. In GIT it should be as you explain
then.
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.
If it's grub1 I don't think it's worth maintaining it. But, I don't know
what's the Debian's grub vs grub2 policy in Jessie actually.
Please check (#757883) (support for loopback.cfg file) where you can see
how I re-use syslinux code to avoid syslinux being stubborn on renaming
the kernel filenames. Don't get me wrong, I also prefer the kernel files
to be renamed always so that the code is consistent accross all the
bootloaders.
Well, yes, we could do that with grub2 variables. My dream is defining
these variables or settings once (in a xml file? in a ini file?) and
then being translated into a syslinux file or to a grub2 file.
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.

Thank you again for your hard work.

adrian15

[1]:
http://git.grml.org/?p=grml-live.git;a=blobdiff;f=templates/boot/grub/grub.cfg;h=31545bd0042dd1e62ed9f83ae81b85565881969b;hp=7e115d6044f0ff86e1944f3bf8121289ef67955b;hb=641c1ace68b52313653478ba4699ca46a1e84184;hpb=2fb103a7c7d8cc2aed11c42e1d29c273c7848049

@Daniel, In regards to issue #17 (of bug #775322) I had a brief
discussion with Steve McIntyre [1] who feels that support for
grub-legacy should be ditched. Would you be happy with that? If so, I
can add a commit to the set of bootloader improvements I am composing
under this bug report to implement that.

[1] https://lists.debian.org/debian-boot/2015/01/msg00233.html

Additional issue:
#21) syslinux looks in wrong location (binary/live instead of
binary/boot) when LB_INITRAMFS is not live-boot or casper.

Same issue as #20, but affecting syslinux here and resulting from a
related mistake with a different case structure and variable, which is
out of line with other scripts.

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.
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 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.
Agreed. I made an attempt to fix this, but failed and posted a request
for help in the Debian boot mailing list. This led to a very brief
discussion with Steve McIntyre who feels the same. I just need
maintainer's support and I'll add a commit into the set I'm providing
here to rip grub-legacy out of live-build.
Will do.
Same feeling here. Perhaps this could be achieved in the planned python
rewrite/transition.
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.

pleace don't ditch grub-legacy if not necessary
regards
emil

Am 16.01.2015, 21:03 Uhr, schrieb jnqnfe <jnqnfe@gmail.com>:

Additional issue:
#22) broken path preventing use of memtest86(+) from grub2

Ok, here is the first set of patches. Attached is an archive with a set
of commits that cover issues #1-8, 10-11, 13-16, and 20-22.

These have been built on top of the debian-next (5.x) branch.

#17 is being ignored, I'm not going to spend any further time on
grub-legacy, and hopefully if Daniel (maintainer) agrees, we can rip out
support for it in a further commit.

So that leaves #9, 12, 18 and 19.

For #9 I need to know exactly what new alternative kernel parameters to
switch to. I did try playing with it a little, but didn't have any
success - tests resulted in a black screen after selecting the
bootloader menu item. Anyone want to help on this?

I will get to work on the rest shortly.

Additional issue:
#23) The syslinux/menu.cfg file has a caret character at the beginning
of the Advanced options title; this character can be used to create
hotkeys with labels, but does not work with titles and so should not be
there. This lead me to incorrectly add this caret to three other files
in commit-13 and introduce the use of it in further titles in commit-14.

The attached additional commit (commit-26) corrects this.

I'll see if it is possible to add labels as well as titles for submenu
entries later (hotkeys might help people with accessibility needs
navigate the new menu structure to 'installer options' > 'install with
speech synthesis' easier (pressing 'i' then 's')).

El 17/01/15 a las 02:21, jnqnfe escribió:

Thank you very much!

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.

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.

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

(forgot to cc the bug, here's a copy)
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.

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.

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.

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.

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.
2) Splash "theme" consistency. The splash, with the exception of the
text mentioned above, is already identical.
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; 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).

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...

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.

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.

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 managed to completely overlook your message somehow. Please state a
(good) reason.

Additional issue:
#23) d syslinux does not apply kernel version filtering to multi-flavour
scenarios

Additional issue:
#23) syslinux does not apply kernel version filtering to multi-flavour
scenarios

El 18/01/15 a las 07:27, jnqnfe escribió:

Now I understand what you mean. Thank you.

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
Well, I want the image to be exactly the same, so yes, there's a point
to me.

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.
Yes, that's one of them.
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.
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.

As I said above SVG is actually converted into PNG already.

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.

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 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 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

I stand corrected, it is indeed converting that svg into a png as you
said; I completely forgot that was there.
Okay, well since syslinux is already doing it, I suppose it isn't a big
deal to have grub2 do it too for consistency. I will add it to the todo
list.
Noted, I will switch grub2 to use an svg and replace the placeholder
text, matching syslinux.
I have just generated two test builds, one with syslinux and one with
grub2, using my latest code, and using an updated splash from the
live-images package (or rather the Jessie copy I have provided in
#775527). I have then taken screenshots of these and attached them here,
so you can see what the grub2 menu looks like in comparison to syslinux.

The configs from the Debian live-images package and the defaults
included in live build only really differ for syslinux in the splash
used, and for grub2 no config is provided in live-images so only the
live-build default is used (I will push for grub2 inclusion in live-images).

As you can see, the grub2 menu theme is essentially a default one
(excluding splash and text color/highlight). I would like to see this
changed to match syslinux. (Note, I may change the background colour of
the syslinux menu item highlight to better match the new splash).

If you could help produce that theme for me to reduce my workload here a
little, that would be appreciated. I have attached a png of the splash
to help with that.

You'll notice that the menu entries are flat in grub2 rather than the
heirarchy used in syslinux, I do still intend to change this to match.
No I get that, I mean that under /usr/share/live/build/bootloaders,
we've got four identical duplicates of the splash, config files and
symlinks. Making changes to the config files, as I have been doing in
this work requires having to replace all four copies, and if you take
the Debian live-images pack, you've currently got 7 desktop config
variations times 8 copies of the config files (four standard, four
wheezy specific) so another 56 copies.

Sure you could script the replacement, but why don't we have a
'syslinux-common' directory under bootloaders containing the common
files, and have only the files specific to a variant (e.g. the
'isolinux.bin' symlink only applies to isolinux) under a variant
specific directory. This removes the need for a script to replace all
copies with new files when one otherwise isn't needed. I get that you
personally might be using a script for this anyway, but for me, if I am
modifying the config files (as I have been doing in this work) to
implement some improvements, I shouldn't be required to have and use a
script to push those change over all of these duplicate copies.
Both could be considered to have 'template files', as both have files
with placeholders that are replaced by the syslinux/grub2 scripts. No
need to ponder it further though, I just noticed on the live-build
roadmap page [1] that the intention is actually to move the template
directory contents into the bootloaders directory, so I'll add that to
the todo list for this set of work to accomplish.

[1] http://live-systems.org/project/roadmap/

Update + additional issue!

Additional issue:
#24) grub/grub2 template files need moving to bootloaders directory, for
consistency and per live-build project roadmap checklist

Updated archive:
Attached is an updated archive containing all patches/commits supplied
so far (set v1 + commit #26), plus a bunch of new ones.

Along with some misc. improvements this update addresses issues #12, #18
and #24.

This now leaves the following issues:
 - #9 : could do with help on this
 - #19 : been working on this, but ran into some difficulties, will keep
pushing ahead

And the following additional todo's:
 - Need to create a simple grub2 theme to get grub2 matching syslinux
layout and thus actually making things properly readable over the splashes.
 - Need to then have grub2 create a png splash from an svg, as with
syslinux, allowing the info that is written into the default svg splash
under syslinux to also be output when using grub2 (at least one
user/derivative wants this).
 - Possibly reduce redundant duplication of syslinux files
 - Implement partial config replacement capability
 - Add a commit to remove grub-legacy support

Update + additional issues!

Additional issues:
#25) Old LB_UNION_FILESYSTEM code needs removing
#26) Use of the syslinux HDT tool is broken, with missing file errors.
I'm not certain whether this was already broken before I started this
work, or whether I broke it somehow, possibly only in my test
environment. I will investigate...
#27) I believe syslinux is checking for the existence of a wrong
directory when LB_BUILD_WITH_CHROOT=false, specifically
/usr/share/{bootloader} instead of /usr/lib/{bootloader}. I sent an
email to Daniel for confirmation, but I am fairly certain this is a
genuine mistake.
#28) Grub2 is not designed to work with LB_BUILD_WITH_CHROOT=false.

This update, building on top of the previous work:
 - Addresses issues #9, #19 and #25
 - Introduces a grub2 theme
 - Adds additional misc. improvements

This now leaves the following outstanding issues: #25, #26 and #27.
And the following additional todo's:
 - Switch grub2 to use svg like syslinux
 - Possibly reduce redundant duplication of syslinux files
 - Implement partial config replacement capability
 - Possibly add ability to execute a 'customise' script from within the
set of bootloader files, enhancing user/derivative bootloader
customisation capabilities (one benefit of this is that doing so in
include/hook stages won't be sufficient when EFI bootloaders are
introduced).
 - Add a commit to remove grub-legacy support
 - Add a commit to change new uses of 'false' installer option with
'none' (introduced earlier in this patch archive), to sync with #774652
improvements.

Sorry, that should read #26-28, I added a new #25 in and forgot to bump
the numbers up here.

Update + additional issues!

First a correction - Issue #28 described grub2 as not being designed to
work with LB_BUILD_WITH_CHROOT=false. This is not entirely true, it is,
but needed some improvement in that area.

Additional issues:
#29) old "video=vesa:ywrap,mtrr" kernel param needs removing, as done in
d-i (see: #395040)
#30) old LB_GRUB_SPLASH and LB_TEMPLATES code needs removing

Issue #29 was actually fixed in the previous update, but deserved being
officially listed.

This update, building on top of the previous work:
 - Addresses issues #26, #27, #28 and #30 (note, #29 already done last
time as just mentioned).
 - Implements partial config replacement capability
 - Addresses the unnecessary duplication of files amongst the syslinux
family bootloader configs
 - Adds additional misc. improvements

This now just leaves the following outstanding todo's:
 - Switch grub2 to use svg like syslinux
 - Possibly add ability to execute a 'customise' script from within the
set of bootloader files, enhancing user/derivative bootloader
customisation capabilities (one benefit of this is that doing so in
include/hook stages won't be sufficient when EFI bootloaders are
introduced).
 - Add a commit to remove grub-legacy support
 - Add a commit to change new uses of 'false' installer option with
'none' (introduced earlier in this patch archive), to sync with #774652
improvements.

Almost there! :)

DONE!!!

The updated archive addresses all remaining items (with one small
exception that actually must be done separately, as noted below).

@Daniel, I prepared an updated changelog for you in the final commit!

Next:
 - I need to create the small patch to change new uses of 'false'
installer option with 'none' (introduced earlier in this patch archive),
to sync with #774652 improvements. But I'm a little stuck as to which
set of patches to build it on top of, since I don't know which will be
accepted first, or whether to create a separate bug report for it...
 - I promised to help Adrian a bit with his loopback patch.
 - I want to work on getting EFI support added as my next priority.

Update: I had to re-work commit #61, some incorrect file permissions
snuck past me.

Update: Added a few additional improvements.

 My gift to you,reply to this email: pc19706@gmail.com for claims

Dear submitter,

as the package open-infrastructure-system-tools has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1137258

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)