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
