Salute odoncaoa,
I'm not sure what do you want to achieve.
I am not a pro, so please correct me if I'm wrong.
The idea of the loopback configuration file is that the media vendor provides
the configuration file as part of the medium.
So if you take a look inside the grml iso you will find a loopback.cfg there.
IMHO iso_path is also vendor specific. GRML passes it as a parameter to the
kernel. It is specified in GRML's grub.cfg.
If I understand you right you might try the autoiso.cfg (from GNU or
supergrubdisk) or specify your entries manually making a loopback mount. There
are quite good threads relating the latter on the Ubuntu forums. The
autoiso.cfg would be the easiest way.
Hope I could help you somehow.
Regards,
sashab
On March 31, 2014 9:40:17 PM CEST, Firstname Lastname <[email protected]>
wrote:
>
>Greetings,
>
>I've been using Grub for years, and Grub2 since it has been available.
>Grub2 has it's own disk sector (sda1). Windoze7 lives in (sda2)
>Windoze8 lives in (sda3), but is hidden; and I'll play with it one of
>these days. sda4 has been configured as an extended partion, where I've
>got Ubuntu 12.? on sda5, MintUx 16 on sda7, and swap on sda6.
>Everything has, and does work well. And, any system can be booted into
>at runtime.
>
>Not too long ago, I revisited the FSF site, and was enthralled by disto
>recommendations. And, wanted to try out some of those latest ux's.
>Also, I'm trying to get the Zbedic open source Mandarin Chinese <-->
>English dictionary (http://bedic.sourceforge.net/) compiled, and
>working from Mint. However, their development was done via Debian,
>which requires inclusion of QT/KDE UI libraries. Anyway, it should be
>easiest to boot into a Debian runtime; via iso, only. Making SD card
>distro runtime generation superfluous, in order to attempt building
>with the same source development environment.
>
>Thus, I was enthralled after another revisit to the Grub2 Manual, to
>find a 'new' working means to help facilitate this: grml-rescueboot
>(https://help.ubuntu.com/community/Grub2/ISOBoot). All kinds of admin
>dilligence has been done to get this working via MintUx. The
>debian-7.4.0-amd64-DVD-1.iso, dynebolic-3.0.0-beta.iso, have been
>downloaded and placed into /boot/grml, and grml-rescueboot, and
>update-grub run successfully. However, it is still NOT possible to run
>either debian, or dynebolic, upon selection of their iso's from Grub2's
>boot menu.
>
>The iso's are each good. They mount'able, and perusable; and
>permissions appear functional:
>
> /boot/grml
> odoncaoa@killincoole$ ll
> total 5594548
> drwxr-xr-x 2 root root 4096 Mar 30 17:47 .
> drwxr-xr-x 8 root root 4096 Mar 30 17:00 ..
> -rwxr-xr-x 1 root root 3951689728 Mar 30 15:26
>debian-7.4.0-amd64-DVD-1.iso
> -rwxr-xr-x 1 root root 1771513856 Mar 31 11:13
>dynebolic-3.0.0-beta.iso
>
> odoncaoa@killincoole$ isomount debian-7.4.0-amd64-DVD-1.iso
> [sudo] password for odoncaoa:
> mount: block device /boot/grml/debian-7.4.0-amd64-DVD-1.iso is
>write-protected, mounting read-only
>
> odoncaoa@killincoole$ df | grep debian-7.4.0-amd64-DVD-1.iso
> /dev/loop1 3859072 3859072 0 100%
>/media/odoncaoa/debian-7.4.0-amd64-DVD-1.iso
> odoncaoa@killincoole$ isoumount debian-7.4.0-amd64-DVD-1.iso
>
> ---
> /boot/grml
> odoncaoa@killincoole$ isomount dynebolic-3.0.0-beta.iso
> mount: block device /boot/grml/dynebolic-3.0.0-beta.iso is
>write-protected, mounting read-only
>
> odoncaoa@killincoole$ df | grep dynebolic-3.0.0-beta.iso
> /dev/loop1 1729180 1729180 0 100%
>/media/odoncaoa/dynebolic-3.0.0-beta.iso
> odoncaoa@killincoole$ isoumount dynebolic-3.0.0-beta.iso
>
>The /etc/grub.d/42_grml and /boot/grub/grub.cfg menuentry's for the new
>non-functional iso's vs. the working MintUx16, are rather different in
>the amount of information included regarding their type, however:
>
> menuentry "Grml Rescue System (debian-7.4.0-amd64-DVD-1.iso)"
> menuentry 'Linux Mint 16 Cinnamon 64-bit, 3.11.0-12-generic
>(/dev/sda7)' --class ubuntu --class gnu-linux --class gnu --class os
>
>Also, the menuentry's for both non-working iso's appear to be lacking
>(after auto generation), as well:
>
> ### BEGIN /etc/grub.d/42_grml ###
> menuentry "Grml Rescue System (debian-7.4.0-amd64-DVD-1.iso)" {
> insmod part_msdos
> insmod ext2
> set root='hd0,msdos7'
> if [ x$feature_platform_search_hint = xy ]; then
> search --no-floppy --fs-uuid --set=root
>--hint-bios=hd0,msdos7 --hint-efi=hd0,msdos7
>--hint-baremetal=ahci0,msdos7 e5b40a40-61d4-450c-89ec-a24b711c9b17
> else
> search --no-floppy --fs-uuid --set=root
>e5b40a40-61d4-450c-89ec-a24b711c9b17
> fi
> iso_path="/boot/grml/debian-7.4.0-amd64-DVD-1.iso"
> export iso_path
> kernelopts=" "
> export kernelopts
> loopback loop "/boot/grml/debian-7.4.0-amd64-DVD-1.iso"
> set root=(loop)
> configfile /boot/grub/loopback.cfg
> }
>
>First, there hasn't been a 'configfile' (/boot/grub/loopback.cfg) file
>created throughout this entire process, but one is identified in each
>of these new iso menuentry's in both /etc/grub.d/42_grml, and
>/boot/grub/grub.cfg.
>
>Fundamentally, the 'iso_path' does not include the '(disk,part)'
>designation, which has actually been assigned to 'root'
>[root='hd0,msdos7']; but is not being used. So, give me some feedback.
>Why has the '(disk,part)' not been included into the 'iso_path', and
>thus the 'loop' statement identifier? Is the current value of
>'iso_path' a robust enough source identifier, otherwise? (i.e. can they
>be found at boot time)? If so, then what else can be wrestled with to
>get this feature working with newly downloaded iso's, and Grub2 tools?
>
>Sláinte,
>
>odoncaoa
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Help-grub mailing list
>[email protected]
>https://lists.gnu.org/mailman/listinfo/help-grub
--
Sent from my Android device with K-9 Mail. Please excuse my brevity._______________________________________________
Help-grub mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-grub
