Ok, just confirming, it is: set root=[drivemapping to entire USB drive] chainloader +1 boot
to boot a USB drive from Grub2 command line - I tried it to make sure. Understand that that executes the program located in the first 440 bytes of the thumb drive. If you would rather boot a partition (i.e., run code from the partition's first sector, called a "VBR" for "Volume Boot Record" as opposed to the "Master Boot Record", which is the first 512 bytes of the entire drive and is outside any partition), set the root to the drivemapping of just that partition instead. Note that a lot of MBRs just pass control to a VBR anyways, in which case you can skip the middle man and just chainload the VBR from Grub. This is the case with Windows. Also, if you're already in Grub, and you want to boot something that's compliant to the multiboot standard off the USB drive, you can just load the kernel and possibly an accompanying initial ramdisk right from the Grub you're at, rather than having to load the USB drive's bootloader and then have that bootloader load the kernel and possibly its initrd. You say you're curious about the boot process in general. I have a few questions myself. Primarily, how does an operating system or bootloader make a BIOS call if the BIOS has ceased running, and only the operating sytem or bootloader is running? My understanding is that when the BIOS starts the computer up, the BIOS is the only program running on the processor. Then when it passes control to the bootloader, the BIOS is goes way and the bootloader is the only program running on the processor. Then likewise when the bootloader passes control the operating system. This is in opposition to a baremetal hypervisor (a baremetal hypervisor is like "VirtualBox OS"), which continues to run under the operating system. What I have gathered/hypothesised so far is that the BIOS does in fact go away, but before it does, it writes a bunch of little programs into memory and attaches an interrupt of the processor to each one. These little programs accomplish basic tasks when ran. Then the BIOS passes control to a bootloader, and the BIOS is no longer, but those little programs remain in memory and their attachment to a given interrupt remains. The bootloader can then ask the processor to execute a program attached to a given interrupt, which pauses execution of the bootloader until the program attached to the interrupt has completed, and then execution of the bootloader resumes. And "making a BIOS call" is actually asking the processor to execute, via an interrupt, a program left behind by the BIOS, as opposed to communicating to software that is running underneath the bootloader or operating system as is the case in paravirtualization (a special form of virtualization (hypervisory magic) where the hypervisor and supervisor (operating sytem) actually knowingly communicate to each other and make life easy on one another). Is that how it works? Cheers, Jake
_______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
