This information HAS errors and is made available WITHOUT ANY WARRANTY OF ANY KIND and without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. It is not permissible to be read by anyone who has ever met a lawyer or attorney. Use is confined to Engineers with more than 370 course hours of engineering.
If you see an error contact:
+1(785) 841 3089
inform@xtronics.com
You only need insmod lvm and jfs if you are using lvm and jfs ... your "set root=" will differ as well the directory paths. In /boot I put a ln -s /usr/lib/syslinux/memdisk ,but one could use the full path.
This is for grub2 - not grub. Located in /etc/grub.d/40_custom (you need to run update-grub after any changes )
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry "Memtest-Plus 4.2" {
echo `hello`
insmod part_msdos
insmod jfs
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set 0bc368ad-8889-4811-acb3-e1bf2f194602
linux16 /boot/memdisk iso
initrd16 /boot/memtest-plus/memtest86+-4.20.iso
}
menuentry "sysrescuecd nfs" {
echo `hello`
insmod part_msdos
insmod jfs
insmod memdisk
set root='(hd0,msdos2)'
search --no-floppy --fs-uuid --set 0bc368ad-8889-4811-acb3-e1bf2f194602
linux /boot/systemrescuecd/syslinux/rescuecd setkmap=us docache subdir=boot/systemrescuecd ar_source=nfs://192.168.1.1:/home/installs/sysrcd/
initrd /boot/systemrescuecd/syslinux/initram.igz
append scandelay=5
}
Credit to S.M. for the following gem:
GRUB2's 'core.img' is a file consisting of "blobs" that include: The GRUB2 "kernel," GRUB2 modules (.mod files) required to access the GRUB2 config-file (and possibly to access additional, non-'core.img' modules), and possibly other odd GRUB2 items, such as an embedded disk image.
Modules (.mod files) built into 'core.img' are loaded automatically by GRUB2 as it establishes its environment. One cannot delay the loading of a module based on any parameter... If one wishes to alter the modules that will be loaded automatically, one needs to build a new, different 'core.img'.
So suppose you have such a 'core.img' file written on a chip in your computer. Suppose the computer has an ATA disk, but the BIOS does not provide access functions (INT 0x13) to it. Suppose you can boot the chip with GRUB2 on it.
Now suppose that the GRUB2 'core.img' contains an embedded disk image as well as the 'memdisk.mod' module. When GRUB2 establishes its environment, it will load this module. It will find the embedded disk image and extract it to a nice place in memory. That RAM-backed, virtual disk will then be available as a device for GRUB2 to use.
Further suppose that the 'core.img' GRUB2 was set to read its config-file from the "memdisk" (whose name unfortunately conflicts with H. Peter Anvin's MEMDISK). So the module is loaded, then GRUB2 finds the virtual disk, then reads its config-file from whatever filesystem is on that virtual disk.
The config-file can contain a user's complicated strategy for deciding what to do next. It could load the 'ata.mod' module and scan for an ATA disk. It could boot that disk if it's found. OR! If it _doesn't_ find an ATA disk, it can _unload_ the 'ata.mod' module and load _a_different_ module which is _incompatible_ with 'ata.mod'. Perhaps a SATA disk driver, as a made-up example. Then it could attempt to find a SATA disk and boot it.
If the 'ata.mod' and the SATA module had not been within an embedded disk image, they would have to have been part of 'core.img' and would have been automatically loaded together, _but_they're_incompatible_! So that was similar to a use case for 'memdisk.mod' that Jordan Uggla suggested to me.
Essentially, a disk image embedded into 'core.img' is the only way to "carry around" files that are not modules to be automatically loaded. So people use it to carry modules, kernels, config-files, etc. where they will only load _some_ of these items, _some_ of the time, depending on whatever GRUB2 config-file scripting they choose.
GRUB2 does _not_ provide an INT 0x13 hook for 'memdisk.mod'-provided virtual disks, nor for its "loopback" virtual disks, so it doesn't allow for any booted OS to use those virtual disks; they disappear once the "hand-off" is complete. You can certainly boot files that are contained _within_ those disk images, but once those files are booted, the virtual disks are gone and the booted item had better be a completely self-contained OS or program that doesn't depend upon any additional files that are contained within the disk image; there's simply no way to access those disk images once GRUB2 has handed over control.
This is pretty different than MEMDISK, which has nothing to do with GRUB2!
| Top Page | wiki Index |