On Apr 19, 2008, at 23:05, Ben Scott wrote: > I'm a little confused about what you mean here.
I am as well. :P > The GRUB shell (the > GRUB work-a-like that runs under Linux) probes to figure out which > Linux kernel devices correspond to which BIOS devices, so that you can > type "root (hd0)" while running Linux and still have the GRUB shell > actually scribble on the correct /dev/sd* node. Is that what you > mean? I don't *think* so. Specifically, both machines (we were swapping systems between two machines) were libata, SATA II drives, booting / boot of of /dev/sda1 without block translation, both using grub. One was using an Intel controller, the other nVidia (teh crap). I thought those were similar enough that grub would be copacetic, but I got the dreaded 'GRUB' (hang) instead of the bootloader on drive swap. I thought maybe I had A and B mixed up, but that wasn't it either. So, I'm not even sure why that didn't work at this point. > If so, it's supposedly possible to manually map host OS devices to > GRUB devices for the GRUB shell. I've never done it, but the syntax > is apparently very simple (cat /boot/grub/device.map to see what I > mean). On both these machines, that looks like: (hd0) /dev/sda (hd1) /dev/sdb should be compatible, right? No. > That said, boot loader portability and robustness has long been the > bane of Linux. Yeah, as a function of outwards complexity this is a simple thing that's hard and the hard things were simple, relatively. > drive. It was confusing as hell, trying to keep track of when the SDD > card will be "(hd0)" and when it will be "(hd1)", and also remembering > that it will always be sdb (because Linux doesn't use the BIOS (which > is, of course, why we need initrd -- look kids, Big Ben, Parliament)). I think there's a hole in my knowledge here about the boot order... at some point the BIOS picks a boot medium, and it loads the bootloader off of disk and puts it in memory and sets the instruction pointer to its address and JMP's to it, right? So then grub is running and it uses the BIOS to find its operating system(s) to boot and does the same for the kernel as the BIOS did for it. So, why doesn't grub just ignore the BIOS like linux? Oh, is this a segment size problem where there's not enough room for a good boot loader (I'll happily give a bootloader 100MB on a server if it'll make life easy)? > To tell the truth, I'm still not sure why one thing worked, but who > am I to argue with success? Yeah, at some point one feels like, "I know pushing these knobs will make it work, but why?" > Ultimately, I think the root cause to this particular mess is "the > IBM-PC BIOS sucks", but I expect we all knew that already. Gar! It looks like EFI borrowed a lot from OpenFirmware too. Hmm, I wonder if anybody besides Apple is making EFI x86 boards. I *think* the linux I have on an Apple/EFI machine uses BIOS emulation though, so maybe linux is not ready... > Hardware profiles get you... to tell you the truth, I'm not really > sure *what* they get you. Sure, you can prevent selected drivers from > loading in selected profiles. Who cares? > You still have to play BIOS drive ordering games in the BOOT.INI > file Windows uses, in order to create a fault-tolerant boot config > with Windows's software RAID. Windows won't boot if the BIOS ordering > doesn't match what BOOT.INI thinks is going on. Sound familiar? Ah, yeah. I think I've only done this with single-disk setups on Windows. Reading some more on this, Windows seems to lean more on BIOS than the unices do, which probably changes the equation. I recall setting up different hardware profiles with different disk drivers in the past and booting disparate hardware with the same disk (c. Windows 2000) but with the BIOS involved this is probably a different booting scenario. However, beyond that, it is possible, once booted, to then use your different sound, graphics, etc. drivers with hardware profiles. AFAIK, Linux (-based distros) doesn't offer such a facility. > Still, I've long maintained that "We don't suck more than Windows > does" is a pretty piss-poor goal for Linux to aim for. Indeed, I just think we're a bit behind here. I think the current xorg tree at least does autodetection reliably for video, or so I've heard. This has the potential to shorten LUG meetings by 15 minutes or more. :) > That doesn't impress me so much. Linux could do the same if it only > had to run on a few dozen different hardware models. I haven't counted, but does Linux support more than a hundred-ish types of disk controllers these days? If not, I'd rather see them all available all the time, which is how Apple's solved this problem, though on a smaller scale, but again, disk cost isn't my concern. Putting on my naive hat: GRUB can read ext2, so why can't it read a map of PCI ID's and drivers off of disk and do the right thing without initrd? I'm clearly missing something. > If all you're worried about is migrating an installed system from > one machine to another, you might consider doing a minimal install > onto a spare disk on the new hardware, attaching the old disks as > secondary disks in the new hardware, fixing up the config and stuff on > the old disks to match the new hardware (using that sophisticated > migration tool, "cp"), and then removing the spare disk and turning > the old disks into the primary disks for the new hardware. It's rude > and crude, but it's also quick and effective. If I'm understanding, that's roughly what I did with the LiveCD, but I think introducing a new disk into the mix (booted from) would affect grub's maps. Though it's probably possible to do it like you describe using RAID-1 and pulling the old disks' content in with a couple reboots. Or a USB hard drive. That might be a good strategy to start with. -Bill ----- Bill McGonigle, Owner Work: 603.448.4440 BFC Computing, LLC Home: 603.448.1668 [EMAIL PROTECTED] Cell: 603.252.2606 http://www.bfccomputing.com/ Page: 603.442.1833 Blog: http://blog.bfccomputing.com/ VCard: http://bfccomputing.com/vcard/bill.vcf _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
