Thank you Jordan. The drives appear to be some kind of a SCSI Raid5 hardware array (this is among the reasons I'm not just pulling the drives to glean their data via another machine), but I think the CDROM is still PATA and no other PATA devices should be important to the data recovery process (there's like a 12/24gb DAT drive, but that's not getting used ever again. :P).
So would the prefix variable be important if I'm trying to boot from media (CDROM) different from the drive Grub2 was loaded from? Or does it mean all or part of Grub2 cli will begin to malfunction until that prefix gets repaired? Or does it mean the CDROM rescue environment I boot into may not be able to see the SCSI drive object unless I do something with the prefix before booting? Once I get back to this machine this afternoon, I'm thinking along the lines of: grub> ls (confirm the CDROM isn't visible but hd is) grub> insmod pata grub> ls (confirm the CDROM is visible now) grub> ls (cd??) (explore around and find the linux image and initrd to set, and then set them and boot) I'll report back how that all goes. :) - - Jesse On Fri, Jun 7, 2013 at 1:55 AM, Jordan Uggla <[email protected]> wrote: > On Thu, Jun 6, 2013 at 3:06 PM, Jesse Thompson <[email protected]> wrote: > > Hello! > > > > I would like some help trying to boot from CD using Grub command line. > > Trying to recover data from an ancient Compaq Proliant server which > lacks a > > way to set boot order in bios. > > > > Only apparent thing I know how to access is Grub command line. > > > > "ls" does not display the CD as a device, and I'm not sure if that means > CD > > drive itself is borked or inaccessable, or if I should insmod something > to > > make it visible. > > For whatever reason, BIOSs only present the CDROM drive to bootloaders > if the machine was booted from CD, so there is probably no way to > access the CDROM drive through your BIOSs interfaces, but luckily grub > does have its own native drivers as well. > > To load grub's native drivers you need to insmod the appropriate > modules, which of course depends on what type of interface this drive > uses. The modules available are "pata", "ahci" (SATA), "uhci" (one of > the specifications for USB 1.0), "ohci" (the other), "ehci" (USB 2.0), > and "usbms" (For mass storage devices connected via ohci,uhci, or > ehci). > > Loading "ahci" or "pata" will disable grub's access to drives via BIOS > interfaces (having two sets of software trying to access the hardware, > grub and the BIOS, at the same time could be dangerous) and so you'll > have to change grub's $prefix variable to point to the new device name > so that grub can find its modules. There is a new command recently > added (or soon to be added) to grub trunk which automates this (fixing > $prefix when loading native drivers). And a final caveat, you cannot > use chainloading when using grub's native drivers, you must load the > kernel from the CDROM directly. > > -- > Jordan Uggla (Jordan_U on irc.freenode.net) >
_______________________________________________ Help-grub mailing list [email protected] https://lists.gnu.org/mailman/listinfo/help-grub
