Re: String functions

[Jordan Uggla]

On Tue, Apr 3, 2012 at 6:46 AM, Arbiel Perlacremaz
<address@hidden> wrote:
> Thank you very much for all this.

You're welcome.

> I'm using the loopback.cfg file when it exists. However, in that case, its
> location into the iso file has not been standardize, i.e. it isn't always
> into the /boot/grub directory. In that later case, I am writing a

The point of me writing that page was to create a standard, and that
standard states that the loopback.cfg should be contained in the exact
path '/boot/grub/loopback.cfg' within the iso file. If a distro is
using another path they're not following the standard. I am willing to
make a possible exception for some BSD systems where '/boot' is
already a regular file rather than a directory, and thus it's
impossible to have a path /boot/grub/loopback.cfg', but all isos
(even BSD based) which I have come across do not have '/boot' as a
file, even if the installed system will. If I find that an exception
is needed I will modify the standard to allow '/grub/loopback.cfg' as
well but right now only the one path is allowed. Please list any
distributions you have found which have a loopback.cfg at a different
path.

>
> The issue is the following : I don't know yet (I haven't tested yet) whether
> I can intertwine loopback statements into the menuentry statements, such as
> loopback loop file1.iso
> source file1.cfg (the menu entries)
> loopback loop file2.iso
> source file2.cfg

grub-script, grub's scripting language, is modeled off of bash. So as
far as order goes, any logical order should work. You can think of
menuentry commands as functions (grub-script also allows the creation
of normal functions) in that the environment needs to be right not
only when you create the function but also when you call the function
later (or select the menu entry). Imagine you're in a GNU/Linux OS and
you do something like this:

losetup /dev/loop0 /boot-isos/iso_one.iso
mount /dev/loop0 /mnt

function display_loopbackcfg_one {
  cat /mnt/boot/grub/loopback.cfg
}

umount /dev/loop0
losetup -d /dev/loop0

losetup /dev/loop0 /boot-isos/iso_two.iso
mount /dev/loop0 /mnt

function display_loopbackcfg_two {
  cat /mnt/boot/grub/loopback.cfg
}

display_loopbackcfg_one
display_loopbackcfg_two


As you can hopefully see, there is a bug in this code and both
functions will display the loopback.cfg from the second iso. Don't
make the same type of error in grub. That is why in the example menu
entry at 
http://www.supergrubdisk.org/wiki/Loopback.cfg#How_do_you_use_a_loopback.cfg_to_boot_an_iso.3F
the loopback command goes inside the menu entry itself.

> Let me tell you what. My aim in doing that is the following.
>
> I'm convinced we (GNU/Linux promotors) have a to complex approach for
> Microsoft-to-GNU/Linux potential migrators. To install their first
> distribution they have to learn how to partition their disk, the have to get
> accustomed to Grub, they have to burn a CD, or the generate a bootable USB
> key. That's a lot for people who have been kept in the dark for sometimes
> many years, and generally do not desire to become "geeks", as they name us.
> They get afraid, and too often, to my opinion, drop before entering the game
>
> To have a smoother approach, I believe you can play as follows:
> 1) from a "protected" web page (protected so as not to get modified into a
> malicious page) replace their Windows bootloader by Grub, create on their
> FAT or NTFS system partition a /boot/grub directory with all necessary
> files, generate a grub.cfg file with a single menuentry to boot into their
> Windows system (all this works, I have tested it)
> 2) let them see by themselves that they still have their system runnnig, and
> that nothing malicious has been made to their PC
> 3) from another "protected" web page, have them download one of several
> distributions to check, and record the appropriate loopback.cfg files, to be
> included in their Grub menu

I would personally simply keep the loopback.cfg files within the iso
and let grub read them at boot. It means that they shouldn't get out
of sync (unless someone modifies the iso file without updating the
loopback.cfg, but there should be release processes already in place
which prevent that type of thing. For instance Ubuntu generates their
loopback.cfg automatically as part of their normal automated iso
building process, as they do their syslinux config files, and grml
uses the same file for a regular grub.cfg and a loopback.cfg ensuring
that changes made apply equally to loop and non-loop booting). This
also means that if they wanted to, without using any external utility,
you could just tell the user "Copy any supported LiveCD iso file to
C:\boot-isos\ and an option for it will be automatically added at
boot".

> 4) boot into any one of these distributions, without having done anything
> else but download the iso files, no CD burning, no USB-key Unetbooting, no
> Wubi installing
>
> Then, when they are ready, they will be more comfortable in partitionning
> their hard disk and hard installing their first distribution
>

Sounds like a great goal.

-- 
Jordan Uggla (Jordan_U on irc.freenode.net)