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
address@hidden 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
address@hidden 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
address@hidden 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
address@hidden isoumount debian-7.4.0-amd64-DVD-1.iso
---
/boot/grml
address@hidden isomount dynebolic-3.0.0-beta.iso
mount: block device /boot/grml/dynebolic-3.0.0-beta.iso is write-protected, mounting read-only
address@hidden df | grep dynebolic-3.0.0-beta.iso
/dev/loop1 1729180 1729180 0 100% /media/odoncaoa/dynebolic-3.0.0-beta.iso
address@hidden 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